As a Roblox developer, current collision fidelities are not adequate enough, and they block creativity. Which is why I propose a “HighPrecision” collision fidelity.
If this issue is addressed, we will no longer have to strategically split meshes, use invisible parts as fillers, and other tricks to get barely appropriate collisions on complex MeshParts.
Use cases:
Complex Roads
Custom Terrain
Important gameplay assets that need extremely accurate collisions
Many more things I can’t think off of the top of my head, I am always running into collision issues
Matching competitor game engines(UE4), as they have this feature.
Even if this is to use a lot of CPU, we still need the option available for outlier cases. From what I can tell, Terrain already has accurate collisions, so we should be able to also get this with meshes.
Here is another poster who ran into the same issue:
PreciseConvexDecomposition failing with my low-poly roads
This is using PreciseConvexDecomposition. Particularly, most issues arise in areas with dips. (Do note that this is a sea bed so it’s meant to be extremely large, jagged, and spread out over a large area)
This would be so beautiful. The biggest use case for me would be the ability to make large low poly terrain using modeling programs without having to worry about wonky collision.
Based on my understanding which albeit isn’t perfect, I believe collision detection cannot actually represent a mesh. Collision meshes use special data and that has to be solved for from the visual data. It’s hard to go from triangles > collision data from what I understand because the collision data has to be solid and isn’t made up of triangles, there are probably cases where it is impossible to represent something perfectly because it would take infinite data, or, it might take millions of tiny cells in the collision geometry or something that could kill performance and eat up a lot of memory because of a little tiny detail on something.
It’s probably a similar reason why CSG always seems to do a horrible job with little tiny details, there are lots of cases it can’t perfectly represent a shape because it has to be solved for and sometimes solving for that shape means millions or billions of data points that mean nothing in the big picture.
I think that a feature like this might actually be more complicated than it seems at first glance but I agree that it would be great to have visually accurate collisions.
To be more specific, collision works with a very specific kind of mesh, known as convex meshes. These meshes have surfaces that always curve outward, with no holes or tubes or indents of any kind. If you want to build up a collision mesh for a physics simulation, it almost always has to be done using convex meshes only, because the underlying math depends on some useful properties of convex meshes to keep everything performant.
The problem with using visual geometry as collision geometry is that your geometry is most likely not convex - you can have meshes with all the holes and dips you want. To circumvent this problem, Roblox uses a convex mesh decomposition algorithm to turn your visual, non-convex mesh into one or more convex meshes. At the time of writing, there’s four such algorithms:
Box - simply uses a single cuboid as your collision mesh, satisfying the convex requirement and performing well, but not a great approximation of the visual geometry
Hull - uses the convex hull of your visual mesh as your collision mesh, which is a better approximation, but doesn’t support dips or holes because only one convex mesh is used
Default - a more complex decomposition algorithm which attempts to approximate your visual mesh using multiple convex collision meshes - it’s not a precise match but it may be enough for most cases
PreciseConvexDecomposition - a complex algorithm like Default, but which attempts to match the visual geometry as close as possible with multiple convex collision meshes.
For the reasons I stated above, it’s impossible to exactly match the visual geometry in all cases, because it’s simply of the wrong format. The four algorithms above are just different trade-offs to reach an appropriate result.
A more actionable feature request in this case might be to improve the accuracy of PreciseConvexDecomposition rather than to supersede it. After all, it is supposed to be the solution to exactly this kind of problem where a tight fit is needed between visual and collision geometry.
Speaking of which this would be great if you could bake any static objects. These would not move at all and would have better collision, lighting, and physics accuracy at the cost of being forced to be anchored permanently, which also applies to this feature request.
I doubt Roblox would want to allow anything to be baked. I once saw a Roblox employee saying that they didn’t want baked lighting because they want Roblox worlds to be “dynamic”. I do think that them adding baked static objects is more likely than baked lighting, though. So many games have terrain, roads, buildings, etc. that never move and would benefit from some physics improvements. However, I don’t think it would be added for a very long time, if ever, as they probably have other priorities.
Of course, maybe that’s what you wanted, and you’d like Roblox to interpret this as just a hollow shape, like a kind of dome with an interior. Setting aside all the other problems that could end up creating, there’s one killer issue that means this mesh is physically impossible to simulate:
It has zero thickness, meaning it has zero volume, meaning it has zero mass.
Have you ever tried to accelerate something with zero mass? It’s kinda problematic. In fact, it’s not really physically simulatable. That’s why you can’t use meshes with zero mass for a physics simulation.
For those reasons, what you’re getting with those algorithms is probably the best you could ask for from the Roblox engine. Consider using a different mesh - preferably, one that’s properly closed and which has non-zero thickness.
Blender actually has a modifier that can help with this in some cases - the Solidify modifier. Here’s what the mesh looks like with it applied - notice there’s no more red back faces, which means it’s properly closed off. It also now has some thickness, which can be configured to taste:
You should get much more preferable results from Roblox with these meshes - I suspect this may also help people trying to make triangle terrain in Blender who may accidentally be creating zero-thickness meshes in a similar fashion
I’m running into the exact same issue. When building a driving game building realistic roads with parts can be very part consuming and unoptimized, not to mention they often leave little bumps all over the road.
The logical thing to do for a driving game developer would be to use optimized and smooth mesh part roads. But we run into one massive issue and that is ROBLOX collisions. Even when using PreciseConvexDecomposistion the collisions still fail and cause cars to float on top of the road.
PrecisionConvexDecomposistion Collisions failing with my low-poly race track
