Re: [openvrml-develop] Tracking down wrong value of d_relativeUrl

[Thomas F. <tf...@us...>]

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