 | | | | | | |
| |
|
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.
L3P/L3Lab search in the above order, with the addition:
5. The catalog of the model [1]
(See also "File search also in directory of model" in
http://home16.inet.tele.dk/hassing/l3p.html#version11)
IIRC LDraw/LEdit MUST be started from the LDraw directory to work.
So for LDraw/LEdit step 1 is always the LDraw directory!
Maybe "the current catalog" actually means the Ldraw directory?
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.
And this is why LDRAWDIR is needed for L3P!
So, should I change step 1 to be the LDraw directory?
I agree with Travis Cobbs that step 5 should be the first step.
Will this have any side effects?
/Lars
[1] Actually, to ease BFC development L3Lab also searches:
0a.The BFC\P catalog.
0b.The BFC\PARTS catalog.
| | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev, Lars C. Hassing writes:
> 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.
> L3P/L3Lab search in the above order, with the addition:
> 5. The catalog of the model [1]
> (See also "File search also in directory of model" in
> http://home16.inet.tele.dk/hassing/l3p.html#version11)
>
> IIRC LDraw/LEdit MUST be started from the LDraw directory to work.
> So for LDraw/LEdit step 1 is always the LDraw directory!
>
> Maybe "the current catalog" actually means the Ldraw directory?
>
> 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.
> And this is why LDRAWDIR is needed for L3P!
>
> So, should I change step 1 to be the LDraw directory?
I don't think you misunderstood the way LDRAW works so I wouldn't
change step 1 to the LDRAW directory.
> I agree with Travis Cobbs that step 5 should be the first step.
> Will this have any side effects?
> /Lars
> [1] Actually, to ease BFC development L3Lab also searches:
> 0a.The BFC\P catalog.
> 0b.The BFC\PARTS catalog.
Although it's not exactly compatible with LDRAW, I think searching 5
first is the most versatile. After all, for a command line user it's
fairly easy to make 1 and 5 be the same. Just CD to the directory
containing the model, then start the program. I suspect LDRAW users
do this anyways since there is a limited amount of characters
available for the path/filename passed on the command line to ldraw.
(I think you get 12 chars which is just enough for an 8.3 filename.)
Thus FWIW my recommendation is to search 5,2,3,4 in that order and don't
bother with 1 because it's most likely to be the same as 5. And if it's
not, it makes more sense to search 5 than 1 because subparts will probably
be in the same directory as the model itself.
Don
Hey, what about the times when you don't want to search either 1 or 5, like
when the program is launched from IE or Netscape and the file is in some
temp directory with who knows what other garbage? Would a command line
option to only search directories 2,3, and 4 be useful?
| | | | | | | | | | | | | | | | | |
| |
|
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>
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. :(
> 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.
> 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'?
> 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.
Steve
| | | | | | | | | | | | | | | | | |
| |
|
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
| | | | | | |
