| |
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
|
|
|
