Re: [osg-users] Calling setUseVertexAttributeAliasing(true) after a viewer is being "run" causes a crasch

[Robert Osfield]

Hi Andres,

You've posted to the mailman list, which I'm about to close, could you subscribe/post to the osg-users googlegroup.  I'll answer the question there.

Cheers,

Robert.

On Wed, 7 Apr 2021 at 13:33, Anders Backman <and...@cs.umu.se> wrote:

Hi all.

Just noticed that it is not possible to toggle the setUseVertexAttributeAliasing after a viewer has been realized and frame/run has been called and any text is involved in the scene. The attached code is a modified osgViewer. If 's' (statistics) is shown after the call to  setUseVertexAttributeAliasing, I get a callstack, meaning it is not possible to toggle this feature while an application is being run. Is that intentional?

I am running OSG 3.6.4 on Windows 10

> osg160-osg.dll!osg::VertexArrayState::applyDisablingOfVertexAttributes(osg::State & state) Line 294 C++
  osg160-osg.dll!osg::Geometry::drawVertexArraysImplementation(osg::RenderInfo & renderInfo) Line 989 C++
  osg160-osg.dll!osg::Geometry::drawImplementation(osg::RenderInfo & renderInfo) Line 899 C++
  osg160-osg.dll!osg::Drawable::drawInner(osg::RenderInfo & renderInfo) Line 277 C++
  osg160-osg.dll!osg::Drawable::draw(osg::RenderInfo & renderInfo) Line 619 C++
  osg160-osgUtil.dll!osgUtil::RenderLeaf::render(osg::RenderInfo & renderInfo, osgUtil::RenderLeaf * previous) Line 84 C++
  osg160-osgUtil.dll!osgUtil::RenderBin::drawImplementation(osg::RenderInfo & renderInfo, osgUtil::RenderLeaf * & previous) Line 488 C++
  osg160-osgUtil.dll!osgUtil::RenderStage::drawImplementation(osg::RenderInfo & renderInfo, osgUtil::RenderLeaf * & previous) Line 1408 C++
  osg160-osgUtil.dll!osgUtil::RenderBin::draw(osg::RenderInfo & renderInfo, osgUtil::RenderLeaf * & previous) Line 432 C++
  osg160-osgUtil.dll!osgUtil::RenderStage::drawInner(osg::RenderInfo & renderInfo, osgUtil::RenderLeaf * & previous, bool & doCopyTexture) Line 934 C++

--

__________________________________________
Anders Backman, HPC2N
90187 Umeå University, Sweden
and...@cs.umu.se http://www.hpc2n.umu.se
Cell: +46-70-392 64 67

_______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[Anders Backman]

Hi all.

Just noticed that it is not possible to toggle the setUseVertexAttributeAliasing after a viewer has been realized and frame/run has been called and any text is involved in the scene. The attached code is a modified osgViewer that will reproduce the issue. If 's' (statistics) is shown after the call to  setUseVertexAttributeAliasing (start the application and press 's'), I get a call stack, meaning it is not possible to toggle this feature while an application is being run. Is that intentional?

Actually, when to call this method during initialization of an OSG application seems to be a delicate choice. 

Also, this design where you switch this via the context, means that you cannot have any Fixed pipeline path in your application. 

So if I would like to have one part of the graph being rendered "shader-free" and another with shaders, applying these properties will effectively break the "shader-free" part.

[Robert Osfield]

Hi Andrers,

On Thu, 8 Apr 2021 at 07:08, Anders Backman <backm...@gmail.com> wrote:

Just noticed that it is not possible to toggle the setUseVertexAttributeAliasing after a viewer has been realized and frame/run has been called and any text is involved in the scene. The attached code is a modified osgViewer that will reproduce the issue. If 's' (statistics) is shown after the call to  setUseVertexAttributeAliasing (start the application and press 's'), I get a call stack, meaning it is not possible to toggle this feature while an application is being run. Is that intentional?

Actually, when to call this method during initialization of an OSG application seems to be a delicate choice. 

The OSG tries to bridge the modern shaders and the deprecated fixed function realms on OpenGL usage, it's not an easy trick to manage, especially once you start getting into GL core profile builds and GLES2 onwards.  The OSG grew up from a fixed function only scene graph and "evolved" into way it today attempts to straddle the requirements of GL core profile and fixed function pipeline.  The way it's ended up straddling the two is a bit adhoc in places, largely as it's an near impossible trick to pull off seamlessly.

So what you are seeing is a limit of design and implement decisions associated with trying to bridge this gap, having the OSG toggle between different ways of handling the state it can assume to be in during flight is not something is designed to do.

 

Also, this design where you switch this via the context, means that you cannot have any Fixed pipeline path in your application. 

This is a limit impossible by OpenGL itself, you simply can't mix and match if you build the OSG and/or create a GL core profile context then you have to use shaders for everything.

The only way way to mix in this case would be to have to graphics contexts and copy depth/colour buffer data between the two to composite a final result.

 

So if I would like to have one part of the graph being rendered "shader-free" and another with shaders, applying these properties will effectively break the "shader-free" part.

I am running OSG 3.6.4 on Windows 10

The OSG can handle scene graphs with fixed function and shaders but you should build the OSG with standard fixed function enabled and just have the subgraphs you want shaders on, don't attempt to toggle high level settings. 

I would recommend using OSG-3.6.5 or the 3.6 branch as there are various fixes in 3.6.5.

Robert.