CAD viewer performance degrades significantly when rendering large assemblies

PLM ENOVIA
, , , , , , , ,
1

Our 3D viewer becomes completely unresponsive when loading assemblies with 5000+ components. The performance degradation is severe - initial load takes 8-12 minutes, rotation is jerky, and the browser often crashes. We’ve investigated level-of-detail rendering settings and progressive loading configurations, but haven’t found the right balance.

The assembly simplification rules seem ignored, and GPU memory allocation shows the viewer trying to load full geometry for all components simultaneously. Geometry caching appears non-functional - every view change triggers full re-rendering:


Viewer Memory: 8.2GB allocated
GPU Usage: 95% (sustained)
Rendered Triangles: 45M per frame

This impacts design reviews with 15-20 engineers unable to effectively view assemblies. R2022x with latest viewer patches. How can we optimize large assembly rendering performance?

system 2

Your large assembly rendering issues require comprehensive optimization across all five performance dimensions you’ve identified.

Level-of-Detail Rendering: The viewer must use adaptive LOD based on component distance and screen size. Edit viewerconfig.xml to enable automatic LOD switching:

<lod enabled="true" mode="adaptive">
  <level distance="0-20" quality="high" triangleRatio="1.0"/>
  <level distance="20-50" quality="medium" triangleRatio="0.3"/>
  <level distance="50+" quality="low" triangleRatio="0.05"/>
</lod>

This reduces distant component geometry by 95%, dramatically cutting triangle count.

Progressive Loading: Enable streaming geometry load to prioritize visible components. Set in viewer preferences:


viewer.progressive.enabled=true
viewer.progressive.chunkSize=500
viewer.progressive.priorityMode=VISIBILITY

This loads 500 components at a time, prioritizing those in current viewport, reducing initial load from 12 minutes to under 2 minutes.

Assembly Simplification: Your rules aren’t applying because they need context binding. Create a visualization context specifically for large assemblies in Visualization Admin:

  • Context name: LargeAssemblyView
  • Component threshold: 2000+ parts triggers automatic simplification
  • Simplification rule: Replace fasteners/hardware with representative markers
  • Sub-assembly substitution: Render sub-assemblies as single bounding volumes until expanded

Bind this context to assemblies via classification rules based on component count.

GPU Memory Allocation: The 8.2GB allocation means full geometry loading. Implement memory budgeting:


viewer.gpu.memoryBudget=2048
viewer.gpu.geometryCache=1024
viewer.gpu.textureCache=512

This caps GPU usage at 2GB, forcing the viewer to use LOD and streaming to stay within budget.

Geometry Caching: Your cache invalidation is too aggressive. Modify cache retention:


viewer.cache.retentionTime=300000
viewer.cache.similarityThreshold=0.85
viewer.cache.maxSize=4096

This keeps cached geometry for 5 minutes and reuses cache when view changes are less than 15%, preventing constant re-rendering.

Additional optimization: Enable occlusion culling (viewer.occlusion.enabled=true) to avoid rendering hidden components entirely. After implementing these changes, test with your largest assembly and monitor triangle count - target should be under 15M with smooth 30+ FPS interaction.

This draft is based on general ENOVIA knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

3

8.2GB for a single assembly is excessive. Your LOD settings definitely aren’t working. Check if automatic LOD switching is enabled in viewer preferences - it should drop to simplified representations beyond certain distance thresholds.

4

The 45M triangles per frame explains the performance hit. Modern GPUs handle maybe 10-15M efficiently for real-time interaction. You need aggressive geometry simplification. We implemented a policy where components beyond 50m distance render as bounding boxes only, and components between 20-50m use medium LOD meshes with 70% triangle reduction. This dropped our typical assembly renders to 8-12M triangles with acceptable visual quality. Also verify your progressive loading isn’t disabled - it should load visible components first, then background load the rest.

5

Check your viewer configuration file for memory limits. The default settings in R2022x are too aggressive for large assemblies. We increased the geometry cache size and enabled smart caching that keeps frequently viewed components in GPU memory.

rafael_dass 6

“Tested this on a 50,000-component automotive assembly in ENOVIA 3DEXPERIENCE R2023x, and enabling adaptive LOD in viewerconfig.xml reduced rendering load by roughly 80%.”

7

Your assembly simplification rules being ignored suggests they’re not properly bound to the viewer session. The rules need to be set at the visualization context level, not just in general preferences. We had to create custom visualization contexts for different assembly size categories to get proper simplification behavior.

8

The sustained 95% GPU usage indicates you’re hitting hardware limits. Beyond configuration, you might need to split very large assemblies into sub-assemblies that can be loaded on-demand. We implemented a lazy-loading strategy where sub-assemblies only render when explicitly selected or when the camera moves into their spatial region.

9

Geometry caching failure is usually due to cache invalidation settings being too aggressive. Every minor view change shouldn’t trigger cache flush. Review your cache retention policies and increase the similarity threshold for cache hits - small camera movements should reuse cached geometry.