Replies: 1 comment 1 reply
-
There have been various discussions on voxel shapes: #446, #552, #1067, #1381. Please check these answers for the first part of your question.
Yes, if you want to use marching cubes then I'm sure you can implement the cells in a more efficient way than a MeshShape. Your voxel world lends itself very well to find which cells are overlapping and then you can just test the triangles that are part of overlapping cells. |
Beta Was this translation helpful? Give feedback.
-
I was wondering how hard would it be to support compound collision shapes, that are made of simple convex colliders laid out in a grid?
The assumption is that it could provide a much faster alternative to general-purpose compound colliders, since there is no need for an acceleration structure to wrap all the possible shapes there could be in it. Instead, the grid provides an implicit, direct mapping to the shapes contained inside. There would only be a need for 1 shape instance per type of shape, and grids could contain indices to them (maybe palette-compressed, or even user-provided so it could use the same data storage used by the game). In voxel games, this would be a great alternative to baking complex editable compound colliders, or using mesh colliders, which are both expensive to bake and modify at runtime. Maybe some things I can think of that would still depend on the amount of subshapes would be center of mass or inertia tensor, but these would only be necessary for dynamic bodies.
I haven't looked yet into how to create new custom shapes in Jolt (if that's possible?), but are my assumptions valid?
Another thing encountered in voxel games are marching cubes, which produces meshes that have triangles particularly well distributed into "cells" of a grid. Would it be beneficial to exploit this to speed up mesh colliders having such characteristic, instead of having to assume any distribution of triangles?
Beta Was this translation helpful? Give feedback.
All reactions