Subject:
|
Re: MPD file loading search order
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Tue, 25 Jul 2006 19:10:00 GMT
|
Viewed:
|
2192 times
|
| |
|
|
As you have pointed out, the spec is indeed ambiguous. Consequently, there’s
probably no correct answer as to how things should work. However, I can tell
you what I do in LDView, so that you have an idea of how at least one
MPD-compatible program does work.
In LDView, when you load a model, the top-level model loading object maintains a
cache of all loaded LDraw files used by that model. This cache is global to the
top-level model, and keyed off the filename used in the linetype 1 line that
references the file. (By global, I mean that all files loaded as a result of
loading the top-level model, no matter how many levels of indirection down the
tree, check the cache first.)
So, when LDView parses a linetype 1 line in a file, it first checks to see if
there is an existing entry in the cache, based purely on the filename specified
by that line. (This lookup is case-insensitive.) If it finds an entry in the
cache, it uses that entry. If it doesn’t find an entry, it starts searching for
files via its internal search path.
LDView doesn’t actually have any special MPD-recognition routines. So LDView
doesn’t care at all what the file extension is. If the 0 FILE meta-command
shows up in a file in an accepted way, the file is treated as an MPD file. If
not, it isn’t.
LDView does its file parsing in two passes. The first pass simply loads all the
text from the file into memory, and does some processing of comment lines. No
other lines are processed at all. The key is that if a 0 FILE line is
encountered at this stage, the wrapped file is added to LDView’s cache, and
loading continues in the context of the wrapped file. (Actually, if the cache
already contains an entry for the new file, the wrapped file will simply be
skipped over; the first instance is always used.) So each time a 0 FILE is
found, a new cache entry is created, and its list of lines filled with all the
lines in the current file up to the end or the next 0 FILE entry. So at the end
of the file loading, all the MPD wrapped files exist in the cache, but none of
them has been parsed.
In the second pass, parsing happens, and when a linetype 1 line is parsed, the
cache is checked first. So if there are any entries in the cache from anywhere
in the MPD, they will be used. If a sub-model references a file that’s in the
cache from the original MPD, the entry from the MPD will be used. If a
sub-model is an MPD, and it includes a wrapped file of the same name, the local
copy will be ignored, and the original cached copy will be used instead.
Obviously, the above behavior isn’t “correct” in the logical sense. But as it
turns out, it works fine, because the MPD format was designed to create a
wrapper file for a model that doesn’t reference any external files except parts.
So in practice, you really shouldn’t find MPD files that reference external
files that aren’t part of the part library. I would argue that if you encounter
such files, whoever created them didn’t understand the whole concept of the MPD
format.
Having said that, LDView could fairly easily be updated to limit the scope of
wrapped files in an MPD to the MPD file itself. Then, if a file external to the
MPD tried to reference a file in the MPD, it would fail. And if an MPD
referenced another MPD, and both contained sub-files of the same name, the
sub-files would be properly scoped. To me, this sounds like the logically
“correct” behavior, but I don’t really see a need to implement such behavior. I
certainly haven’t had anyone complain to me that they had problems loading a
file, and the problems were a result of LDView’s global scope for files
contained inside MPDs.
Note that while LDView doesn’t currently support loading multiple models at
once, the cache is local to the top-level model loaded by LDView, so LDView
could in the future support loading multiple top-level models, and each would
have its own separate cache. Original versions of LDView had a truly global
application-level cache.
One final thing. As I mentioned, LDView doesn’t have any special recognition of
MPD files based on their extension. I really feel that this is the correct
thing to do. Forcing MPD files to have an MPD extension is unnecessary. And
since the creation of the .ldr extension, it seems to me that users shouldn’t be
forced to understand the difference between an MPD file and any other LDraw
file. But that’s just my personal opinion.
--Travis
|
|
Message has 2 Replies:
 | | 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)
| | | Re: MPD file loading search order
|
| (...) Well, if you read all postings on MPD through the last seven years you should be able to piece the correct answer together :-) I believe the L3 parser (used in L3P, L3Lab and "ldglite -l3") reflects that information. > However, I can tell (...) (18 years ago, 25-Jul-06, to lugnet.cad.dev)
|
Message is in Reply To:
| | MPD file loading search order
|
| Hello All, I'm implementing a LDraw file loader and was wondering about some details concerning mpd. I could not found enough info about this elsewhere, or I may overlooked it. [1] When loading a MPD file should I keep checking the first level of (...) (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
|
|
|
|
