|
From: Thomas F. <tf...@us...> - 2001-12-03 04:26:43
|
Patch #488262 has been submitted for this problem. This patch fixes bug
#225694 as well.
I've done some regression testing using the NIST conformance tests of
the different grouping nodes and no new problems have appeared. I'd
appreciate it though if others could take a look at the patch to verify
the sanity of the change.
Later,
Tom
Thomas Flynn wrote:
> Damian McGuckin wrote:
>
>> With 'GTKLOOKAT', I am reading a ( boring but small sample ) file
>>
>> a.wrl
>>
>> which 'inlines' a URL file
>>
>> model/c.wrl
>>
>> which in turn reads a URL (image) files
>>
>> image/asp.jpg
>>
>> The file a.wrl resides in the current directory, as does the
>> directory 'model'. Directory 'image' resides within 'model'.
>>
>> In the first pass through the VRML nodes, done with readWwl ( which is
>> associated with a Doc ), the part of each included file, i.e. the
>> d_relativeUrl, is correct. It uses
>>
>> VrmlNodeInline::addToScene
>> which (calls) VrmlNodeInline::load
>> which (calls) VrmlScene::readWrl
>>
>>
>> However, on a second pass through, the 2nd level nested file, sky.jpg,
>> thinks its parent is a.wrl, not model/c.wrl. As a result, the nested
>> image
>> cannot be found. I do not know where these nodes are being
>> processed. It
>> is definitely not readWrl. If I ensure that the directory image is
>> in the
>> same directory as 'a.wrl', this solves the problem but that isn't the
>> point. I don't have control like this all the time. VRML is
>> supposed to
>> take care of nesting.
>>
>> I can't even figure out which routine is used to make the second pass
>> but it isn't the same as the first pass. There seem like there are
>> many routines that do fundamentally the same thing and I am lost.
>>
> The second pass is being made in NodeInline::addToScene() on the call
> to NodeGroup::addToScene() ... the relative URL passed into both
> methods is null (which makes sense as the inline is at the root) The
> problem is that NodeGroup::addToScene resets the current relative URL
> (the correct one determined in the first pass!) with the null URL that
> has just been passed in.
>
> Commenting out the following lines will allow the image to be correctly.
>
> if (currentRel.length() == 0 || relativeUrl.length() == 0
> || currentRel != relativeUrl) {
> this->d_relative.set(relativeUrl);
> }
>
> This probably isn't a good fix as it likely breaks something somewhere
> else, I'll look into this a little more and see what I come up with.
>
> Later,
> Tom
>
|