coin3d
Multiple texture rendering problem with Coin 4
Hi folks,
We've encountered an issue with rendering multiple textures that was working fine previously on Coin 3.1.3. As shown below:
Rendered with Version 3.1.3
However, with version 4, it doesn’t get rendered as expected, please see snapshot
below:
Another interesting observation is, if we switch on the “Light Model node” in the scene, the scene will get rendered better apparently.
Scene file diff - with and without Light Model switched on
Rendered with Version 4.0.0 with Light Model switched on
I've included a small application example that highlights the problem when loading in the scene.iv from within the doc folder.
coinv4Issue.zip
In our full application we also see problems with the Z depth when rotating the model whether lighting is on or off. As we rotate, some of the distant faces pop in front of the nearer faces and vice versa.
Would you be able to take a look into this and see if it's a problem that requires a fix or if there's changes/settings we can make on our side to achieve the same behaviour we were seeing previously with Coin 3.1.3?
Thanks
Steve
Unfortunately, I am not able to look into this over the next two weeks. Maybe @WizzerWorks or @veelo can you have a look onto this issue?
I don't really have the expertise to look into this, but have started to try and compare side by side runs in the debugger between 3.1.3 and 4.0.3. There's been a significant change in how the first unit texture is handled with everything now being managed my MultiTexture classes in v4 rather than plain Texture classes for unit zero and then MultiTexture classes in v3. My suspicion is something to do with that but I don't have the expertise to know if settings are correct or not. I'm hoping to be able to find an indicator to where the key difference may lie and then offer up here for discussion.
I think I've possibly traced it down to the removal of code from SoGLLazyElement where all of the glimage references have been removed. I'm certainly no expert on this so I could be wrong, but whilst debugging v3.1.3, I jumped over the sendGLImage method to see what the impact was and I ended up with a very similar output image to what we're seeing in v4. I'm not sure if that holds water as a reason as I don't know enough about OpenInventer or Coin to be confident in my reasoning, but I now thing the general switch to MultiTexture looks to be behaving very similar to the previous individual Texture2 implementation. When I've debugged both side by side and followed the logic through , I can see the MultiTexture has nicely generalised usage whereas before in v3 it had special cases for unit == 0 and then MultiTexture implementation subsequently.
I've put hooks in to check if SoGLLazyElement::send still receives a GLIMAGE_CASE, which it does, but is currently ignored/unhandled in v4.x. Whether or not it's meant to be handled otherwise I don't know, I'm just the lucky one that has ventured to take a look!
I'm not so sure now, I see the old SoGLLazyElement::sendGLImage has now migrated to SoGLMultiTextureImageElement::updateGL and that's already getting called during the render stage so although I got v3 to show similar images by bypassing this step, I'm now not sure I'm close to finding the cause.
@VolkerEnderlein I'm curious to run something by you, not a fix, more of a query. I've been going round the houses trying a few things but nothing has made a positive change. I was doing some idle research last night to try and get a bit more understanding of the OpenInventor multi texture handling to get some background theory and in my travels rediscovered FreeCAD, which has now reached release 1.0. I saw it supported .iv files so downloaded it and imported our .iv file that shows the above problem.
Interestingly the scene was rendered correctly with the arrows shown as expected and checked which Coin version was in use, which was 4.0.3, same as the version I'm playing with at present. So, with it seemingly working correctly, I thought I'd take the Coin4.dll provided with the FreeCAD install and use it in place of the one I built to see if it was a problem with the way I had built Coin but the problem persisted which makes me think is there some prerequisite setting that we're missing in our application and provided example that FreeCAD might be setting/enabling/disabling that is allowing the scene to be rendered correctly within that? It could well be that there's a dependency/setting that's (now?) required that we don't have which is causing Coin to exhibit this behaviour meaning the problem doesn't lie necessarily within Coin per se, but in our implementation that's using it. Our example is pretty simplistic but does that sound feasible that there could be a missing setting that's now needed and wasn't previously that could be the cause of this behaviour?
Edited to add, I've just checked the converse and dropped my Coin4.dll build into FreeCAD (along with relevant compiler version libraries) and the scene is still rendering fine in FreeCAD which makes me believe more that the Coin library itself is fine and that it may be more that we're missing initialisation of something or at least now don't have a fully specified configuration that would allow it to render correctly.
I think I've traced it down to a single noticeable difference, one that certainly fixes the application example provided. In our main application code, we're calling
setTransparencyType(SoGLRenderAction::SORTED_OBJECT_BLEND);
Looking into the FreeCAD code, that calls
setTransparencyType(SoGLRenderAction::SORTED_OBJECT_SORTED_TRIANGLE_BLEND);
If I add offscreenRenderer->getGLRenderAction()->setTransparencyType(SoGLRenderAction::SORTED_OBJECT_SORTED_TRIANGLE_BLEND); to the provided application example just before the render call, the scene looks to be rendering correctly. I need to check more thoroughly but this looks like it could be the key part to having the scene rendered correctly. I don't know if that ties in nicely with the migration from the previous Texture2 + multi texture implementation that was present in 3.1.3 to the newer pure multi texture implementation, but if it does, it looks like it's this environment configuration that needed to be done and nothing at all overtly incorrect within the Coin library itself.
I'll do some more checks and report back but hopefully we can look to close this off and leave this information for others that may run into similar problems.
Everything looks good from my side now with the SORTED_OBJECT_SORTED_TRIANGLE_BLEND so I'm happy for this to be closed off as the problem looked to be firmly on my side for this one.
