 | | | | | | |
| |
|
Awhile back there was a thread about seams, subparts, and relations between
them with respect to L3P and L3Lab. After a great deal of confusion on my
part about what was causing the problem, I had an e-mail conversation with
Lars Hassing which finally got things settled for me about what was going
on.
The thing to realize here is that I could not reproduce the problems people
were experiencing in either L3Lab or my own program, LDView. The reasons
for this turned out to be related. As it turns out, L3Lab only produces
seams between subparts in a part if you do the following:
1. View the actual part which contains subparts, and not some model which
contains that part. This was fairly obvious from the posts.
2. Specify the filename on the command line. This was not obvious to me
from the posts. However, they were talking about L3P, and files are always
specified on the command line there. So, while L3Lab uses the same loading
code, the results turn out to be different when a file is loaded via L3Lab's
UI.
The reason turns out to be the search order that L3Lab uses when looking for
submodels. The first place it checks is the current directory. The last
place it checks is the main model's directory. (In between it checks the
LDraw P, Parts, and Models directories.) When you open a file in L3Lab
using the UI, it changes to the directory containing that file, although
there is know way for the user to know this. This means that if you open a
part, subparts will be found in step 1. If, however, you specify the
filename on the command line, it doesn't change to the file's directory,
meaning that subparts get found when it searches the LDraw parts directory,
thus qualifying as a part, and producing seams.
LDView doesn't ever get into this situation because I always change to the
directory containing the main file, whether it is specified on the command
line, via a dropped file, or via the standard Open Panel UI. I noted to
Lars that checking the model's directory immediately following the current
directory would resolve the seams problem. He thought perhaps people in
this group might have some comments.
So, I'm posting this for two reasons. First, I'd like to know what people
think with regards to L3Lab and LDView. Since both of these are Windows
viewers, their behavior should ideally be the same for consistency's sake.
It is my belief that, given that Windows programs don't normally have much
concept of a current directory from the user's point of view, having the
"current" directory always be the model's directory makes sense. This is
the current behavior of LDView, and also of L3Lab when a file is opened
using the Open Panel UI.
However, given that L3P is a command line tool, the current directory has
more meaning. I still lean toward the belief that the model's directory
should be searched before any of the standard LDraw directories, but this
means that custom part files in the model's directory would override the
same part files subsequently installed in the LDraw parts library.
Currently if you run L3P from the model's directory, you already get this
behavior. It's my opinion that it is more consistent, but others may
disagree.
Any comments?
--Travis Cobbs (tcobbs@san.REMOVE.rr.com)
| | | | | | | | | | | | | | | |
In lugnet.cad.dev, Travis Cobbs wrote:
> Any comments?
Sounds like the only way out of your dilemma is for the programs to be
smart enough to recognize that the current directory *is* the ldraw\parts\
directory, and proceed accordingly.
Steve
| | | | | | | | | | | | | | | | | |
| |
|
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
| | | | | | |
