Subject:
|
Re: MPD file loading search order
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Wed, 26 Jul 2006 04:48:39 GMT
|
Viewed:
|
2334 times
|
| |
|
|
In lugnet.cad.dev, Roland Melkert wrote:
> Snip, very thourho explanation, thanks!
You're welcome.
> I was thinking of doing the local scope approach mentioned by Steve. But
> maybe I keep it optional realizing I always end up disappointing some
> people with ether approach.
I think local scope is the "correct" thing to do as long as local scope means
that only files inside an MPD file can access other files inside the MDP file.
Files stored external to the MPD shouldn't, in theory, be able to see the files
inside the MPD. As I said, LDView doesn't work this way, but it's arguably the
"correct" way to do things.
> I was planning to create an LDraw class which handles a single .dat/.ldr
> content. a Model class whom will keep the toplevel information (all
> recursive OpenGL ready rendering primitives etc) for the directly
> requested file.
> and a Library class which will manage all currently loaded LDraw and
> model instances.
You're welcome to do that, but unless you just want to do it "for fun", or
you're not using C++, you might want to take a look at LDView's LDLoader
library. This is a separate library in the LDView source tree whose sole
purpose in life is to load an LDraw file into an object-oriented class tree.
The library (LDLoader) makes use of my own base library (TCFoundation), but both
of these already compile on Windows, Linux, and probably other OSes. The
LDLoader library is designed to be generic, and not in any way tied to LDView
(although it is in the LDView source tree).
I've used it to write a real quick program to go through a model and "un-mirror"
all the mirrored studs. (In case you're not aware, when you run a model through
L3P and then render, the stud logos will end up mirrored if the stud primitives
in the file have been mirrored. LDView auto-corrects for this at run-time when
drawing stud logos.) In any event, the entire un-mirror program is less than
600 lines of code, and that includes command line processing, loading of
settings from the registry, error handling, and 40 lines of code just to print
usage information. It also generates new filenames for the un-mirrored files,
updates the data, and writes the files to disk.
> MPD's will be separated in multiple ldraw objects and a single model
> object, much like you are describing.
>
> The ldraw objects will determine a absolute filename for type 1 lines
> and ask the library to load that file into a new Ldraw object (the
> recursion). The library can then determine if it's already loaded or
> needs a reload (e.g. file's date changed).
>
> This way every file on disk will be at most once loaded, but different
> rendering information can be calculated for it by the higher model classes.
>
> I need this kind of approach because there will be lots of models loaded
> at once. In theory it could go in the hundreds of models, because I'm
> writing this for the succeeder of my LD4DModeler software.
>
> Any serious animation will have an explosion of used models. I realize
> rendering all of them is quite insane :) but I'm not planning of doing
> that anyway.
>
> I am only hoping memory usage and loading time won't go insane too. If
> this is the case I consider caching all ldraw and model objects to disk
> for next sessions.
I can certainly understand the desire to do it yourself. After all, that gives
you the exact features that you're looking for, and when it's all done you're an
expert at using the library classes. On the other hand, if you want to use the
LDLoader code in LDView, you're welcome to do so. As it stands currently, it
doesn't 100% meet your criteria, but it could be made to with very few changes.
If you do want to use it, I could probably even make the changes myself. You
can download the LDView source from the LDView sourceforge project page here:
http://sourceforge.net/projects/ldview
There's a zip of the 3.0 source tree in the releases section, but if you do
decide to use the libraries, you're probably better off going with the latest
code in CVS. I'm really close to a 3.1 beta, so there have definitely been
updates since the 3.0 release. As I mentioned above, the LDLoader lib in the
the LDView project relies on the TCFoundation lib, also in the LDView project.
Both are currently configured to be static libraries in both Windows and Linux.
> Thanks for you're insight.
You're welcome. And once again, don't feel like I'm trying to pressure you into
using my library. I'm presenting it to you as an option that you can use if
you're more interested in doing the higher-level work on your project. If you
like doing file parsing and loading, by all means implement your own.
It's not really documented, but if you are interested in using it, I'd
definitely give you a crash course in how to do so. It's actually pretty
straightforward from the outside point of view. And all my "glue" between the
object tree and my OpenGL rendering engine is currently in a single separate
class, so there's good example code to look at. The "glue" class is about 1300
lines of code, but it also contains all the logic to detect the presence of
primitives that LDView knows how to perform substitutions for, as well as quite
a bit of the actual substitution logic.
--Travis
|
|
Message has 1 Reply:
 | | Re: MPD file loading search order
|
| (...) Thanks for the pointers, I'm working with Delphi 2005 Pro win32 at the moment (LD4DModeler was written in Delphi 6 Pro). So I can't use you're library. But I will certainly take a look at it. I sometimes write stuff in C++, but for a living (...) (18 years ago, 26-Jul-06, to lugnet.cad.dev)
|
Message is in Reply To:
| | Re: MPD file loading search order
|
| (...) Snip, very thourho explanation, thanks! (...) I was thinking of doing the local scope approach mentioned by Steve. But maybe I keep it optional realizing I always end up disappointing some people with ether approach. I was planning to create (...) (18 years ago, 25-Jul-06, to lugnet.cad.dev)
|
29 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
