Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

in a large scene, is it better or worse to combine some meshes with many triangles into one mesh? #625

Open
ka1nong opened this issue Mar 3, 2023 · 2 comments
Assignees

Comments

@ka1nong
Copy link

ka1nong commented Mar 3, 2023

raycast、swwwp、overlap and simulation.will there be a noticeable difference in their performance?Is there any relevant article to explain? thx

@PierreTerdiman
Copy link

PierreTerdiman commented Mar 7, 2023

There are no articles about this as far as I know. And as often with performance-related questions, the answer is "it depends". The best thing to do is really to try and see for yourself.

Generally speaking, for rigid body simulation I would say that there should be no drastic difference in performance between the two, because meshes have their own acceleration data structures ("midphase" structures), and in the end you are just putting some pressure either on the broadphase or on the midphase. They are not the same structures so there will be some performance differences between the two, but which one "wins" depends on a lot of details like how the meshes are spatially organized (do they overlap a lot, etc), how many dynamic bodies are colliding with them, etc.

Now for pure scene-query structures I would say that yes, combining all meshes into one can provide faster queries. The reason is that scene queries do not go through the "broadphase", like rigid bodies, but they go through a scene-level AABB tree which is not as optimized as the midphase AABB trees (for technical reasons, because we rebuild the scene-level tree constantly, while the midphase trees are mostly static). Thus traversing the scene tree, before hitting the midphase trees in the leaves, is technically a bit less efficient than it could be. Whether it is enough to give a "noticeable difference" is hard to tell without testing though.

I did see a clear case in the past where merging the trees gave large speedups in raycast performance: this was when meshes (parts of a game level) overlapped a lot, to the point that they all had roughly the same bounding box, which defeated the purpose of the scene-level tree. (Imagine taking a game level, sorting triangles by material, and creating a physics mesh for each material. You end up with that kind of bad case). In this scenario merging everything into the same mesh (basically one giant mesh for the whole level) provided huge speedups for scene queries.

On the other hand traversing a huge mesh can take longer, just because the tree can be deeper (so it takes more time to reach its leaves). And at the end of the day, you can also find configurations for which merging everything into a single mesh will be slower. Imagine a room with a cube shape - 4 walls, 1 ground, 1 ceiling. You can model that with 6 meshes, or merge everything into a single mesh. Now imagine an object standing in the center of the room in the air, not touching anything. With 6 meshes the broadphase will report no collisions between the floating object and the walls/ground/ceiling, and you will early exit, never entering midphase/narrow-phase. With the room merged into a single mesh though, the floating object's bounding box is now completely overlapping the room's bounding box, so you end up calling the narrow-phase for this pair, and you're in pretty much the worst case for the midphase, where the code will traverse a potentially large tree without ever returning a hit - there will be no early exit, no caching, etc. In this case keeping the room's components separated would give much faster results.

So, again, "it depends", and I cannot give you a definitive answer here.

@ka1nong
Copy link
Author

ka1nong commented Mar 8, 2023

thank you for your detailed answer

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants