I am currently making destruction for my game Using CSG,
However the collision gets weird when there’s multiple holes in the part. When Destruction happens in areas where destructed faces are near, the collision of the part bugs out and the player is left floating in the spot.
Player Floating in multiple craters
Collision working normally on a single crater
So Far I’ve tried multiple solutions:
Precision option - When I used the precision option, the problem still persist and makes the computation much longer. Not viable when a game will have multiple explosions at once.
Box Collision - Instead of making the visuals as the collision, I decided to create 2 parts: 1 handles Collision, 1 handles Visual. The visual will have all the thorn parts while the collision is invisible and the crater is just a box. The problem still happens when enough craters are in the part but can handle more craters.
Voxel destruction + CSG - I decided to try out Voxel destruction for the collision and CSG for the visuals of the destruction. It works well with parts but when it came to wedges and corner wedges the module I’m using did not know how to handle it.
Are there any other solutions or alternatives? A Voxel system alternative that can handle wedges would be ideal.
1 Like
You can probably try turn on Show Decomposition Geometry under Studio Settings to view the physics of the craters.
I’m having this issue too.
I looked into the bug a bit and it seems to just be resetting the parts colliders every time a new CSG operation is applied to it.
Edit: This only seems to be happening to larger parts. I’m not really sure what’s going on here to be honest.
Hoping it gets fixed soon.
The GeometryService CSG API has hard limits for the collision geometry. I will explain how it works and it’s current limitation, so you can use its strength to your advantage when applicable.
If you pass the Default CollisionFidelity option to the API, the first time you call the API, it will do a cleanup pass to prepare it for fast incremental collision geometry. The cleanup pass, has a large tolerance and covers cavities that are relatively small in terms of percentage of volume to the main part of the CSG operation. So if you have a very big plate for the ground and dig a tiny hole, that will be covered by the cleanup pass. In the subsequent API calls, the fast and precise incremental algorithm is run and you get a pretty nice hole. The caveat is the fast incremental algorithm makes a lot of data and if not kept in check, it will put a lot of memory and compute pressure on the physics collision system. We monitor the number of convex hulls per object and if it passes a threshold, we try to cleanup the collision geometry to relieve the systems. After the cleanup pass, your precise holes might get covered up and cause inconsistencies during gameplay. It is not yet possible to reduce the memory and keep the same level of precision at the same time.
If you do decide to use the CSG system, I recommend to chop up your map into a grid, and also slices in depth, such that a typical hole is more about 20% volume or more of any plate piece. You may have to do more CSG operations, but you will go around the current limits imposed. If the map is large enough you are eventually going to use a lot of physics memory and either run into Out of Memory issues or frame rate drop. But at least you can try exploring the limits.
This is understandable, but disheartening to hear. For me when I CSG large parts the geometry resets every almost time with default collision fidelity (It’s usually when its less than ~10% volume).
Breaking up the parts isn’t great for my use case either because there currently isn’t a great way to deal with lots of CSG operations. With a few parts like a map you won’t have a big issue but anything past that you start to run lots of lag. Even if the parts geometry is otherwise simple. Unioning the parts before hand does make the process much faster but usually results in a significant loss of accuracy.
PreciseConvexDecomposition isn’t a great alternative but it’s probably the most usable. It can get extremely slow and results in a lot of unnecessary complexity, but it’s less prone to issues.
You guys have done truly amazing work optimizing it so far and I’d love to use it in a game soon, but as it stands currently its applicable use cases are very niche. Though perhaps in the future could we see better support for multiple operation parts? I think this would be a game changer.
