| |
In lugnet.cad.dev, Steve Bliss wrote:
> In lugnet.cad.dev, Lars C. Hassing wrote:
>
> > According to FAQ question 26, LDraw searches for files in the following order:
> > 1.The current catalog.
> > 2.The P catalog.
> > 3.The PARTS catalog.
> > 4.The MODELS catalog.
>
> The FAQ is not quite correct. Step #1 should be last, not first.
>
> Strictly speaking, LDraw 'searches' by trying to access files, named as
> follows. (This is taken directly from the LDraw code).
>
> 'p/' + <filename>
> 'parts/' + <filename>
> 'models/' + <filename>
> <filename>
Really!
> Where <filename> is the file specified either on the LDraw command line, or
> in a subfile command (linetype 1).
>
> Notice that *all* references are relative to the current directory. The
> only way to get out of the current-directory tree is to put an absolute
> path in the <filename>.
>
> > L3P/L3Lab search in the above order, with the addition:
> > 5. The catalog of the model [1]
>
> This is a good thing.
>
> I'm noticing a difference between the way L3Lab renders and the way LDLite
> renders. I've got a multi-file model in a subdirectory, but there are some
> files with the same name in the ldraw/models/ directory. L3Lab renders the
> way I want it to :) , but LDLite doesn't. :(
The very first place to look is inside the model-MPD...
> > IIRC LDraw/LEdit MUST be started from the LDraw directory to work.
> > So for LDraw/LEdit step 1 is always the LDraw directory!
>
> True. Besides the issue with finding the part directories, LDraw needs to
> load its graphic drivers, and it looks in the current directory for them.
Indeed, but we've just learned that P, PARTS and MODELS come first.
So step 1 is not the first step, but comes after step 4.
> > Maybe "the current catalog" actually means the Ldraw directory?
>
> It might actually be more accurate to say "Request <filename> from the file
> system, without specifying any extra path information". Whether the file
> is in the current directory depends on the contents of the <filename>
> reference.
>
> > If so, I have misunderstood "the current catalog" because I have
> > programmed L3P (and L3Lab) to actually use the current working
> > directory from where L3P is started.
>
> Are you specifically looking in a specific directory, or are you allowing
> the OS to track the 'current directory'?
It happens automatically, I simply use "fopen(<filename>)".
> > And this is why LDRAWDIR is needed for L3P!
> >
> > So, should I change step 1 to be the LDraw directory?
>
> No, I don't see any point to that. Long-term, LDraw rendering programs
> should (generally) be searching:
>
> 1. The document's directory
> 2. %LDRAWDIR%\p
> 3. %LDRAWDIR%\parts
>
> ldraw\models should become much less important, over time. Users should be
> able to store their model files whereever they like.
>
> Having ldraw\models is convenient, because you can put unofficial parts
> there (and not disturb the 'official' files in \parts and \p), or use it as
> a temporary location for other people's models, or even put standard
> submodels in it.
>
> > I agree with Travis Cobbs that step 5 should be the first step.
> > Will this have any side effects?
>
> Yes, any same-name files will be taken from the document's directory,
> instead of one of the standard directories. This is generally a good
> thing.
I aggre totally with all you've said.
The Open File dialog in L3Lab does a CD to the model's directory,
so step 1 becomes in effect the same directory as step 5
- exactly like your long-term suggestion is correct.
The FAQ could be updated to:
LDraw/LEdit MUST be started in the LDraw directory. They search for files in:
1. P
2. PARTS
3. MODELS
4. .
Modern programs should search in:
1. Inside the document if it is an MPD
2. The document's directory
3. %LDRAWDIR%\P
4. %LDRAWDIR%\PARTS
5. %LDRAWDIR%\MODELS
where LDRAWDIR is the LDraw directory.
/Lars
|
|
| |
In lugnet.cad.dev, Lars C. Hassing wrote:
> > I'm noticing a difference between the way L3Lab renders and the way LDLite
> > renders. I've got a multi-file model in a subdirectory, but there are some
> > files with the same name in the ldraw/models/ directory. L3Lab renders the
> > way I want it to :) , but LDLite doesn't. :(
>
> The very first place to look is inside the model-MPD...
Yeah, I realized (after posting my message), that it was a problem with
LDLite handling a subfile which was an MPD. I changed to the equivalent
DAT, and everything's fine now.
> The FAQ could be updated to:
>
> LDraw/LEdit MUST be started in the LDraw directory. They search for files in:
> 1. P
> 2. PARTS
> 3. MODELS
> 4. .
>
> Modern programs should search in:
> 1. Inside the document if it is an MPD
> 2. The document's directory
> 3. %LDRAWDIR%\P
> 4. %LDRAWDIR%\PARTS
> 5. %LDRAWDIR%\MODELS
> where LDRAWDIR is the LDraw directory.
Good point.
Your "1. Inside the document if it is an MPD" reminds me: how do renderers
handle caching of submodels inside an MPD? Are these files visible outside
of the MPD, or do they lose scope?
With the following files, how will C.DAT render? Will 'some stuff' be
drawn twice, or will we see 'some stuff' and 'some other stuff'?
A.MPD:
0 FILE A.DAT
1 16 0 0 0 1 0 0 0 1 0 0 0 1 B.DAT
0
0 FILE B.DAT
some stuff
0
B.DAT:
some other stuff
0
C.DAT:
1 16 0 0 0 1 0 0 0 1 0 0 0 1 A.MPD
1 16 0 48 0 1 0 0 0 1 0 0 0 1 B.DAT
0
Steve
|
|
| |
In lugnet.cad.dev, Steve Bliss wrote:
> In lugnet.cad.dev, Lars C. Hassing wrote:
>
> > The FAQ could be updated to:
> >
> > LDraw/LEdit MUST be started in the LDraw directory. They search for files in:
> > 1. P
> > 2. PARTS
> > 3. MODELS
> > 4. .
> >
> > Modern programs should search in:
> > 1. Inside the document if it is an MPD
> > 2. The document's directory
> > 3. %LDRAWDIR%\P
> > 4. %LDRAWDIR%\PARTS
> > 5. %LDRAWDIR%\MODELS
> > where LDRAWDIR is the LDraw directory.
>
> Good point.
I'm glad you agree.
> Your "1. Inside the document if it is an MPD" reminds me: how do renderers
> handle caching of submodels inside an MPD? Are these files visible outside
> of the MPD, or do they lose scope?
>
> With the following files, how will C.DAT render? Will 'some stuff' be
> drawn twice, or will we see 'some stuff' and 'some other stuff'?
>
> A.MPD:
> 0 FILE A.DAT
> 1 16 0 0 0 1 0 0 0 1 0 0 0 1 B.DAT
> 0
> 0 FILE B.DAT
> some stuff
> 0
>
> B.DAT:
> some other stuff
> 0
>
> C.DAT:
> 1 16 0 0 0 1 0 0 0 1 0 0 0 1 A.MPD
> 1 16 0 48 0 1 0 0 0 1 0 0 0 1 B.DAT
> 0
L3P/L3Lab will draw 'some stuff' twice.
The file B.DAT is never loaded, as the subfile B.DAT was loaded
during reading A.MPD.
It doesn't matter whether subfile A.DAT references B.DAT or not.
An MPD should be regarded as a collection of files which is automatically
unpacked before loading, so the scope is public.
I would have preferred the scope to be private...
See also http://news.lugnet.com/cad/dev/?n=4188 (L3P/L3Lab will give
you a warning about roof.dat) and http://news.lugnet.com/cad/mlcad/?n=325
/Lars
|
|
| |
In lugnet.cad.dev, Lars C. Hassing wrote:
> In lugnet.cad.dev, Steve Bliss wrote:
>
> > [stuff about scoping of files contained within MPD files]
>
> L3P/L3Lab will draw 'some stuff' twice.
> The file B.DAT is never loaded, as the subfile B.DAT was loaded
> during reading A.MPD.
That's what I assumed.
> It doesn't matter whether subfile A.DAT references B.DAT or not.
Does it matter if C.DAT references B.DAT *before* referencing A.MPD? This
would change the example to:
> > A.MPD:
> > 0 FILE A.DAT
> > 1 16 0 0 0 1 0 0 0 1 0 0 0 1 B.DAT
> > 0
> > 0 FILE B.DAT
> > some stuff
> > 0
> >
> > B.DAT:
> > some other stuff
> > 0
> >
> > C.DAT:
> > 1 16 0 48 0 1 0 0 0 1 0 0 0 1 B.DAT
> > 1 16 0 0 0 1 0 0 0 1 0 0 0 1 A.MPD
> > 0
> An MPD should be regarded as a collection of files which is automatically
> unpacked before loading, so the scope is public.
That makes sense, and is simpler to implement. And could even be useful,
under certain circumstances.
> I would have preferred the scope to be private...
For MPD, I don't agree. But I feel there needs to be a follow-on to MPD,
designed specifically to support submodels within a single model file. It
should give consideration to issues of scoping and visibility.
Steve
|
|
| |
In lugnet.cad.dev, Steve Bliss wrote:
> In lugnet.cad.dev, Lars C. Hassing wrote:
> > It doesn't matter whether subfile A.DAT references B.DAT or not.
>
> Does it matter if C.DAT references B.DAT *before* referencing A.MPD? This
> would change the example to:
>
> > > A.MPD:
> > > 0 FILE A.DAT
> > > 1 16 0 0 0 1 0 0 0 1 0 0 0 1 B.DAT
> > > 0
> > > 0 FILE B.DAT
> > > some stuff
> > > 0
> > >
> > > B.DAT:
> > > some other stuff
> > > 0
> > >
> > > C.DAT:
> > > 1 16 0 48 0 1 0 0 0 1 0 0 0 1 B.DAT
> > > 1 16 0 0 0 1 0 0 0 1 0 0 0 1 A.MPD
> > > 0
Yes, it does matter. L3P/L3Lab give you a warning
SKIPPING "a.mpd" Line 4: FILE b.dat already read: 0 FILE B.DAT
and 'some stuff' gets treated as part of file A.DAT.
So here 'some other stuff' and 'some stuff' get drawn.
> > An MPD should be regarded as a collection of files which is automatically
> > unpacked before loading, so the scope is public.
>
> That makes sense, and is simpler to implement. And could even be useful,
> under certain circumstances.
>
> > I would have preferred the scope to be private...
>
> For MPD, I don't agree. But I feel there needs to be a follow-on to MPD,
> designed specifically to support submodels within a single model file. It
> should give consideration to issues of scoping and visibility.
Right, my concern was the ability to compose a Datsville DAT file with
references to many MPD files submitted by contributors.
It should be OK for two authors to use the same subfile name,
e.g. "roof" in my example: http://news.lugnet.com/cad/dev/?n=4188
/Lars
|
|
|
