Please have a better day. I did not say anything like what you are acting like I said. I said that we have 2 existing methods that are performant at scale, and that I did not understand the way in which you were using terminology.
In your subsequent example, you have an imported part with no history that you've converted to a surface. Check Part doesn't show complexity, but Check Surface will. For native parts, adding a convert to Surface feature at the end of the tree will not positively impact recompute. There may be some sneaky way to achieve a lightweight approach, possibly, but they all have drawbacks - most notably in your example the mass properties of all the fasteners would be ignored. It is likely any such solution would be new and custom, not just the application of features we have today out of the box. It is also possible, though I do not actually know, that having surfaces of equivalent geometry at scale is equally unperformant as having bodies at scale. No idea. Not something we've tested. It's more likely I think that having "a 3D representation" that is also performant at scale will require simplification (e.g. a schematic revolve-cut representation), not just changing entity types.
The takeaway here, I hope, is that often there is a lot more subtlety to performance related things than might meet the eye and, often, we ask ourselves whether solving these problems is really worth the time in cases like this where there exists an industry-standard performant approach already working (using textures or graphical representation).
Last edited:
