Activity

1. dagunliyu

   changed the title [-]Prob：The graphics program developed using Coin3D as the engine and the rendering frame rate becomes lower on newer graphics cards.[/-] [+]Prob：The graphics program developed using Coin3D as the engine and the rendering frame rate becomes lower on newer NVIDIA graphics cards.[/+] on Feb 27, 2025
2. veelo commented on Feb 28, 2025

   

   veelo

   on Feb 28, 2025

   Member

   More actions

   This information may be outdated, but we know of a problem with the Quadro drivers. Basically their "Threaded optimization" feature collides with Coin's own thread locking. Try to turn that off and see if that makes a difference. Otherwise, maybe you can find some other tips regarding Quadro in our trouble shooting matrix here: https://www.sarc.nl/images/manuals/pias/htmlEN/fwy_troubleshooting.html

   I am curious though at the size of this data set and the decision to dump all of it in one node. This takes away any and all optimization opportunities that Coin may have. Given there are only 8 million pixels on a 4K display, rendering 18 million lines zoomed-all will likely just produce a solid blob. So I suspect that most of the time you would view this heavily zoomed in, with most of the geometry outside of the viewport. If the data were partitioned in suitably segregated line sets, Coin would be able to cull most of that geometry away based on bounding boxes, giving you workable FPS.
3. veelo commented on Feb 28, 2025

   

   veelo

   on Feb 28, 2025

   Member

   More actions

   You may be interested in what Grok comes up with to the query "In the Coin3D graphics framework, what are the optimization opportunities for displaying massive datasets?":

   Optimization Opportunities for Displaying Massive Datasets in Coin3D

   The Coin3D graphics framework, an open-source implementation of the Open Inventor API, is designed for high-level 3D graphics programming with a scene graph-based architecture. When displaying massive datasets—such as those in scientific visualization, geospatial modeling, or volumetric rendering (e.g., via SIM Voleon)—several optimization opportunities can enhance performance while managing memory and computational constraints. Below are key strategies based on Coin3D’s capabilities and general principles for large-scale 3D data:

   1. Leverage Scene Graph Efficiency

   • Hierarchical Culling: Coin3D’s scene graph structure supports hierarchical data organization. Use SoSeparator nodes to group objects spatially, enabling view-frustum and occlusion culling to skip rendering geometry outside the viewer’s perspective, reducing processed nodes per frame.
   • Level of Detail (LOD): Implement SoLOD nodes to switch between high- and low-resolution models based on viewer distance. Precompute multiple LODs for massive datasets to cut rendering costs without losing visual fidelity where it matters.
   • Switch Nodes: Use SoSwitch nodes to enable or disable scene graph sections dynamically, unloading irrelevant dataset portions based on user interaction or application state.

   2. Optimize Rendering with OpenGL Features

   • 3D Texture Hardware Acceleration: For volumetric data (e.g., SIM Voleon), Coin3D can use hardware-accelerated 3D texture mapping if supported. This is more memory-efficient than 2D textures (which use three times more memory) and improves rendering quality. Check for 3D texture support at startup, falling back to 2D if needed.
   • Shader Support: With GLSL shader support, offload tasks like lighting or color mapping to the GPU. Custom shaders can optimize per-pixel operations for massive datasets, reducing CPU-GPU data transfer bottlenecks.
   • Vertex Buffer Objects (VBOs): Store geometry in VBOs to minimize redundant GPU data transfers. Tune Coin3D’s pipeline to batch vertex data efficiently, especially for static or semi-static dataset portions.

   3. Memory Management for Large Datasets

   • Subcube Division and Paging: For volumetric or large mesh data, Coin3D (via SIM Voleon) splits datasets into subcubes (default 128x128x128). Increase this (e.g., to 256x256x256) on modern GPUs for better performance, using SoVolumeData::setPageSize to adjust dynamically based on hardware.
   • Progressive Loading: Implement paging to load only visible or near-visible dataset portions into memory, unloading distant sections. Pair with asynchronous I/O to avoid frame rate hitches.
   • Texture Compression: Without extensions like EXT_paletted_texture or ARB_fragment_program, Coin3D converts data to RGBA textures, quadrupling memory use. Pre-compress textures or use paletted rendering where supported.

   4. Parallel Processing and Threading

   • Threaded Optimization: Coin3D can be thread-safe, but beware of issues with NVIDIA’s "threaded optimization" (e.g., freezing on startup). Disable it if needed, or use multi-threaded traversal/data prep on compatible systems to offload the rendering thread.
   • Asynchronous Data Processing: Preprocess or stream data in background threads (e.g., producer-consumer model) to keep the rendering thread unblocked, especially for real-time updates.

   5. Profiling and Bottleneck Identification

   • Built-in Profiler: Use COIN_PROFILER and COIN_PROFILER_OVERLAY to monitor traversal times and pinpoint slow nodes (e.g., SoLineSet, SoPointSet). Simplify geometry or reduce state changes based on this data.
   • Hardware Assessment: Coin3D tests hardware at startup (e.g., 3D texture support). Adapt rendering strategies dynamically—e.g., increase subcube sizes or enable features only on capable systems.

   6. Data-Specific Optimizations

   • Simplify Geometry: For polygonal datasets, reduce vertex counts via mesh decimation or use SoIndexedFaceSet to minimize redundant data.
   • Volumetric Rendering: In SIM Voleon, use Maximum Intensity Projection (MIP) or Sum Intensity Projection if hardware-supported, as these render complex volumetric data efficiently.
   • File Format Efficiency: Extend SoVolumeReader to support compressed or streaming-friendly formats beyond VOL files, reducing I/O bottlenecks.

   Practical Considerations

   • Hardware Constraints: GPU memory is often the bottleneck. Modern cards (128+ MB) handle larger subcubes, but older systems may need conservative settings or CPU preprocessing.
   • Trade-offs: Larger subcubes boost performance but risk swapping out textures, so balance with the dataset’s memory footprint.
   • Scalability: Coin3D’s portability (Windows, Linux, macOS) ensures broad applicability, but test on target hardware to avoid capability assumptions.

   By combining these strategies—scene graph management, GPU acceleration, memory optimization, and profiling—Coin3D can handle massive datasets with interactive performance. Tailor them to the dataset (e.g., polygonal vs. volumetric) and hardware for optimal results.
4. VolkerEnderlein commented on Feb 8, 2026

   

   VolkerEnderlein

   on Feb 8, 2026

   Member

   More actions

   @dagunliyu Catching up on this, did you have success to identify the reasons for this issue?
5. dagunliyu commented on Feb 8, 2026

   

   dagunliyu

   on Feb 8, 2026

   Author

   More actions

   @dagunliyu Catching up on this, did you have success to identify the reasons for this issue?

   My colleague used a version of Coin3D built with PDB symbols to debug on the problematic GPU, pinpointed a rendering function in Coin3D that was taking a long time, and eventually resolved the issue by modifying the Coin3D source code to process the rendering data in smaller chunks. I’ll need to look into the exact details again.
6. VolkerEnderlein commented on Feb 8, 2026

   

   VolkerEnderlein

   on Feb 8, 2026

   Member

   More actions

   Glad you sorted it out. The details would be interesting to know as other users could benefit from them and we could improve rendering speed.