osgDB::readNodeFile and rendering memory leak ?

[EliottA28]

Hi everyone,

I've been using osgDB::readNodeFile to load .obj files in OpenSceneGraph with the option osgDB::Options("noTriStripPolygons") to speed up the loading process. Initially, everything worked fine. However, I recently encountered an issue where the application crashes due to a memory leak during repeated calls to glDrawArrays(_mode,_first,_count) at rendering time, but only when using the "noTriStripPolygons" option. When I remove this option, the application works fine, but the loading process becomes significantly slower.

Details of the Issue :

• The issue occurs only on certain laptops and only when the "noTriStripPolygons" option is used.
• Specifically, on Intel(R) Iris(R) Xe Graphics (OpenGL 4.6), everything runs smoothly with the option enabled, but on AMD Radeon(TM) Graphics (OpenGL 4.6), the system crashes.
• The crash involves a memory leak that seems related to glDrawArrays during rendering, leading to system instability and eventual crashes.
• Graphics drivers are up-to-date on both systems, but the issue persists.

Things I've Tried :

• Identifying Hardware and Drivers: I have confirmed that both laptops have OpenGL 4.6, but the issue only happens on the AMD Radeon system.
• Disabling the "noTriStripPolygons" option: When I disable the option, everything works, but the loading speed is very slow (up to 4 minutes to load an .obj file, whereas it's near-instantaneous in Blender or MeshLab).
• Profiling and Debugging: I haven’t been able to precisely identify the cause of the memory leak. I suspect it could be due to driver implementations or hardware-specific limitations related to polygon rendering and OpenGL state handling.

Questions/Next Steps :

• Is this issue related to specific GPU drivers or OpenGL versions ? I’m particularly concerned about how different hardware platforms might handle this option. Could this be a driver bug or limitation in AMD’s OpenGL implementation ?
• Could switching to Vulkan (OSVulkan) help? Would using Vulkan potentially bypass the OpenGL-specific issues I’m encountering ? Are there any known improvements or drawbacks for my use case ?
• Are there other ways to speed up .obj file loading ? While the "noTriStripPolygons" option speeds up loading, I’m looking for alternative solutions or optimizations to achieve faster loading times (similar to Blender and MeshLab).

Any insight on the issue would be greatly appreciated.

Thanks in advance for any help !

[robertosfield]

The OSG's .obj loader is slow at parsing and then even slower at optimizing the data. One could start from scratch and implement your own .obj loader that resolves these issues, but won't fix the OpenGL ones. The .obj format is ancient and really low fidelity so it might able best to use a more modern format.

Vulkan driver tends to be more uniformly supported across platforms than OpenGL which can be a bit sporadic as it's got a lot more history and workarounds in drivers that have built up over the decades. Basically OpenGL is end of life so this situation won't likely suddenly become better.

As quick test try the combination of VulkanSceneGraph, vsgXchange (built against Assimp) and vsgExamples then simple try loading your .obj models in vsgviewer i.e.

vsgviewer mymodel.obj

The VulkanSceneGraph is under continual development, while the OpenSceneGraph it's pre-deccessor is like OpenGL just in maintenance mode. I wouldn't recommend using OpenSceneGraph for new applications, it's really just suitable for folks that already have written their applications on top of OpenSceneGraph/OpenGL and need to maintain them.