Design rules for greatly improved performance on large assemblies.

jason_29

This isn't a request for support, this is intended to be a discussion on performance improvement techniques for large assemblies.  I worked with @lougallo substantially over the past few days to get to the bottom of some performance issues of an electric vehicle I am designing.  There are two major takeaways, which will likely be irrelevant in a year as OS continues to improve its rendering engine, but I'll offer them to the community here, since they are essential for large assemblies today.

1) Imported fasteners that are fully threaded increase rendering effort by two orders of magnitude.  Ex. An M3 12mm length socket cap head screw might be 400K triangles.  A simplified version with a cylinder representing the threaded area will result in 4K triangles.  This has profound impact on rendering performance.

Improvement: Build simplified models for all threaded fasteners and this will decrease the triangle count for fasteners by two orders of magnitude.  In my model, it reduced the total triangle count by a factor of 2-3.


2) Completely occluded parts are still rendered.  This seems unintuitive, and perhaps an inappropriate use of resources, but for whatever reason, this is the case today.  OS might have a very good reason for this that I am not aware of.  In an assembly, if one deliberately "hides" parts or sub-assemblies that are completed occluded, you will see a performance increase.  In my model, I saw a 1.5x improvement in the render frame rates.

Improvement: Hide models which are completely occluded.


Overall, I was able to see 2-3x frame rate increase in my large assembly implementing these two tricks above.

I'll update this post as others offer insight, or if these suggestions are made irrelevant by continued OS improvement.

Warmest, 

Jason

pete_yodis

Thanks for posting @jason_29. I noticed some performance degradation on one of my documents. I wonder how far along wegl is with handling things more automatically for us? Is this a webgl thing, or am I off base. I have seen modelers implement efficiency tricks over the years as they got more advanced. My curiosity is peaked.

3dcad

If I'm zoomed in to see just 10% model so that 90% is out of screen, does Onshape render whole model or just the part I'm looking at? ( @lougallo )

jakeramsley

3dcad said:

If I'm zoomed in to see just 10% model so that 90% is out of screen, does Onshape render whole model or just the part I'm looking at? ( @lougallo )

Onshape renders the entire thing.

jason_29

pete_yodis said:

Thanks for posting @jason_29. I noticed some performance degradation on one of my documents. I wonder how far along wegl is with handling things more automatically for us? Is this a webgl thing, or am I off base. I have seen modelers implement efficiency tricks over the years as they got more advanced. My curiosity is peaked.

I'm not an expert in webgl, nor am I familiar with the OS webgl implementation.  I can only only comment on empirical evidence like that which I mentioned above.

pete_yodis

@jason_29 My comment was directed to anyone with knowledge here, particularly the Onshape folks.  They have said and shown they want to be transparent with their users, so I thought I would try to learn something.  I did some reading over the weekend.... https://en.wikipedia.org/wiki/Hidden_surface_determination

I think these types of methods are more an evolution of the application and not necessarily the underlying graphics language - although I am a complete hack in this realm... so don't trust me.  Just trying to understand.

3dcad

jakeramsley said:

.. Onshape renders the entire thing.

Don't remember the details exactly but it was the best update to alibre's performance when they limited fine rendering to cover only what user is currently seeing (don't see any reason to do it otherwise). If there is very large model it can look a bit coarse from a distance but when you zoom in everything is perfect.

Evan

I’m one of the engineers that works on the Onshape’s WebGL functionality.  Performance is and will continue to be a high priority for us.   Up until now, most of work in this area has focused on packaging our display data so that the GPU can render it as efficiently as it can.  However, as @jason_29  astutely observed, we are not dynamically changing the rendered content.  This is something we are pursuing on two fronts:

  1) Avoid rendering parts that will not be visible (i.e., are outside the frustum, too small, or are occluded)

  2) Dynamically reducing detail to maintain a decent representation of the assembly while maintaining good interactivity.

Skipping occluded parts, or occlusion culling, is an interesting problem.  WebGL 2 will be exposing functionality to make this possible, though one has to be careful about how the functionality is used - otherwise more time can be spent determining what is occluded than is saved with that information!  If you’re curious, nvidia has a good overview here:
http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter06.html

pete_yodis

Wow.  Thanks @evan_1 So there is some waiting for WebGL to mature as well, besides what you can do within the Onshape platform?

Evan

Yep.  WebGL 1 is a pretty capable platform, though it is missing some functionality that desktop OpenGL exposes.  WebGL 2 will expose a lot more functionality.  That said, we're not waiting for WebGL 2 to continue the work on performance 

pete_yodis

@evan_1 Thanks for the explanation for a curious cat.   Sounds like you're having fun.