<div dir="ltr">Hi Alessandro,<br><div class="gmail_extra"><br><div class="gmail_quote">On 14 August 2015 at 08:43, Alessandro Terenzi <span dir="ltr"><<a href="mailto:a.terenzi@gmail.com" target="_blank">a.terenzi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Robert,<br>
so far I can say that if I do not apply the ColorMask then the object is rendered correctly.<br>
<br>
Also, there is one specific geometry that actually gets hidden by the object the ColorMask is applied to, whereas all other geometries appear on top of that object. Apparently the only difference among those geometries is that the first has an opacity map applied while the others do not.</blockquote><div><br></div><div>Unfortunately, without an example that illustrates the problem first hand there really isn't much I and other members in the community can help with.  In principle there should be no reason why doing what you are doing shouldn't work with OSG-3.4.0, ColorMask is identical, so there is something else in you apllication/scenegraph/OSG that is introducing the problem, but there isn't any way for us to know what it might be.<br><br></div><div>I would recommend trying out your application on a desktop system with the GLES1 profile enabled, and just vanilla OpenGL (default CMAke build), this will give you at least a sanity test to see broadly where the problem might lie.<br><br></div><div>The only other thing that springs to mind is that in the previous release transition we fixed a bug in SceneView that meant that global state was applied correctly rather than discarding it and replacing it with defaults.  This change didn't affect most users applications that use the OSG in standard ways, addressed a bug that prevent proper working behaviours for others and for some who used the OSG in a slightly different way than standard found that their applications were relying upon this overriding of state but when it was removed the application behaved different.  <br><br>The different usage was down to users creating their own osg::Camera and appyling this to be the View(er)'s master Camera, replacing the original one that had been set up with the appropriate global defaults.  The fix for these users was to either just reuse the Camera attached to the View(er) or call osg::Camera::getOrCreateStateSet()->setGlobalDefaults();<br><br></div><div>This was an example where a fix to the OSG broke end users applications that were relying upon a bug to work correctly.<br><br></div><div>In your case I would have thought this particular issue isn't the problem, but you never know.<br><br></div><div>Robert.<br></div><div><br> <br></div><div><br> </div></div></div></div>