-
Hello, I need an advice. I am developing a desktop application for simulation of CNC machines using OSG 3.1.3. I need to support different material per face, face highlighting (using material), transparency, clipping planes, therefore this was my base decision to define the scene in this way, but now I came to the limits. I decided to make geometry optimization so, that I group the geometries together by color, so that the geometries with same color share the same list of vertices, normals, colors and the triangles are defined with lists of DrawElementUInt(GL_TRIANGLES) per face. Additionally I am storing the face information in UserData of osg::Geometry in an own datastructure. I wanted to derive from DrawElementUInt and store there but my additional data were not serialized, but this is a different topic. This optimization brought me significant performance boost, I get about 15-25 FPS by the same scene, and that is fine. Do you have an other idea to make this optimization in a better way? Best regards |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
The graphics hardware/OepnGL just supports changing colour per primitive set or per vertex, so per face material changes you'll need to either ease separate PrimitiveSet per face or duplicate vertices in order to use per vertex colours. Potentially you could subclass from osg::Drawable and implement the GL calls tuned for your usage case and for the subclass to have the public variables/member variables you need. Perhaps if you have hardware that supports it you could try out RTX mesh shaders. For this you'd need to the MeshShaders branch of the OSG. Longer term you might also want to consider the VulkanSceneGraph, both Vulkan and the VSG itself handle scenes where meshes are broken into small chunks far better than OpenGL & OSG as the CPU overhead is far far lower. They also have support for cross vendor mesh shaders. |
Beta Was this translation helpful? Give feedback.
The graphics hardware/OepnGL just supports changing colour per primitive set or per vertex, so per face material changes you'll need to either ease separate PrimitiveSet per face or duplicate vertices in order to use per vertex colours.
Potentially you could subclass from osg::Drawable and implement the GL calls tuned for your usage case and for the subclass to have the public variables/member variables you need.
Perhaps if you have hardware that supports it you could try out RTX mesh shaders. For this you'd need to the MeshShaders branch of the OSG.
Longer term you might also want to consider the VulkanSceneGraph, both Vulkan and the VSG itself handle scenes where meshes are broken into …