SoTextureCoordinatePlane Rendering Bug

Issue #75 resolved
Roy Sorrel created an issue

Texture coordinates are not being generated correctly if multiple SoTextureCoordinatePlane nodes are used and not under their own SoSeparator. Only the first set of coordinates are used.

See the Inventor Mentor code sample 07.3.TextureFunction.cpp to reproduce the bug:

[https://bitbucket.org/Coin3D/ivexamples/src/8742841445996ed885dc53ed0d25c494bdfec7a6/Mentor/07.3.TextureFunction.cpp.in]

Instead of getting this:

texture_fixed.png

running the program produces this:

texture_broken.png

Putting each SoTextureCoordinatePlane, SoSphere pair under their own SoSeparator works around the bug (see attachment).

Traced the issue to the SoGLMultiTextureCoordinateElement.cpp file. This code is only performing the first texgen callback (SoTextureCoordinatePlane::handleTexgen) it encounters at a given stack level:

https://bitbucket.org/Coin3D/coin/src/1dd16504da2f39eda56d9a6d3925b068c3eb89a8/src/elements/GL/SoGLMultiTextureCoordinateElement.cpp#cl-316

in the setElt function.

This could affect other nodes which use the SoGLMultiTextureElement code. I'm not too familiar with multitexturing in OpenGL, so maybe the alternative is that the Mentor example is out of date.

My OpenGL Info: OpenGL version: 3.0 Mesa 10.1.3

Comments (11)

  1. Roy Walmsley

    All,

    I have verified this issue and all the comments above. Roy raises a valid question above about the validity of the inventor example. I am inclined to think that we should be reproducing the results of the Inventor Mentor. Comments would be appreciated.

    I have a simple fix for the above. It involves simply changing line 320 of file SoGLMultiTextureCoordinateElement.cpp as shown below:

    • else if (func && func != ud.texgenCB) docallback = TRUE;
    • else if (func ) docallback = TRUE;

    This will have some impact on execution efficiency because the callback will be run every time.

    The alternative would be to examine the caching process in more detail, so that the cache recognises that the data has changed. I could, for now, go for the simple fix and add comments in the code that the caching process should be investigated. Again, comments would be welcome.

    Roy

  2. Roy Sorrel reporter

    Roy,

    Thank you for looking into this issue.

    Regarding your fix, would you also have to modify the SoGLMultiTextureCoordinateElement::pop function at line 173 from

    else if (thisud.texgenCB != prevud.texgenCB) docallback = TRUE;
    

    to

    else if (thisud.texgenCB) docallback = TRUE;
    

    ?

    --Roy S.

  3. Roy Walmsley

    Roy,

    Thanks for your further response. I hadn't spotted your other point. With respect to documentation see issue #44. I am currently working on that - I just haven't got to this class yet. When I run doxygen I get thousands of warnings that I am gradually working through!

    When I tested your observations I didn't create a separate program (as in the ivexample code). Instead I translated it into a simple Inventor model that I saved and loaded, as I already have a full working viewer for both Inventor and VRML files. These might be more preferred by some users and could be added into the existing ivexamples repository.

    A regression test suite is something I haven't really looked at so far, but is a good idea.

    Roy

  4. Roy Sorrel reporter

    Roy,

    As you mentioned earlier, a comment like:

    // FIXME: do we need to cache identical texgen callbacks here?
    else if (func) docallback = TRUE;
    

    might be useful. I think the changes we have identified will fix my original issue, but the question remains: will it affect anyone else?

    --Roy S.

  5. Roy Walmsley

    Roy

    I didn't read your remarks as criticism. I apologise if it sounded like I did.

    With respect to the Toolmaker examples I agree that they are unlikely to be translatable. After all, this is about extending the code base, rather than how to use the existing one as in the Inventor Mentor.

    I look forward to your ideas on regression testing. You might like to raise a new issue on that when you are ready.

    With respect to the code changes to fix this issue I will give people a couple more days to see if we get any further comments and then, if there are no contraindications, I will update the code base.

    Roy

  6. Roy Walmsley

    Fixed multiple SoTextureCoordinatePlane nodes failing to update internal texture details on second and subsequent nodes.

  7. Thomas Moeller

    I could also reproduce the issue and agree with both of you that it needed to be fixed. It would be very strange if during the traversal of the scene newly encountered instances of TextureCoordinatePlane don't have any effect. Your solution of always calling texgenCB (if set) seems correct to me. Thank you for finding and incorporating a fix!

    Thomas

  8. Log in to comment