As a Roblox developer, it is currently too hard to have good Mesh and CSG collision working how you want.
my suggestion is to add a slot in mesh and csg where you can insert another mesh id for use as a collision, this mesh id will work as collision.
the mesh collision needs to have a perfect collision instead using the normal roblox that generate collision, fallow the examples.
Collision made by hand
now the roblox automatic collision generated.
In the end, do we really need a new property or object to achieve separate visual and physical mesh components? Seems pretty simple to me to - as we’ve seen - create two separate meshes that each either specialize in visuals or physics. The improvements to memory with this feature would be relatively insignificant.
Idea is cool, but the MeshPart’s collision wouldn’t be as smooth as you pictured it. There are a lot of concave shapes in the “walking area”. Approximate Convex Decomposition will round that area up, which will cause a character to float near the “railings”.
Hey there, there is a longer, manual way to do this. The original mesh being collision disabled and importing a mesh using this plugin https://www.roblox.com/library/267728602/Physical-Obj-Importer to turn the mesh into parts. Meshes still don’t have good collisions, so use parts as collisions until that happens.
the problem with that is that you need to disable the mesh collision for that.
if some part in roblox have no collision the camera pass inside.
also it generate alot of parts for that.
my suggestion there is a better collision with 1 part only
Yes please! I think the default collision fidelities should still be an option, but this in addition to it. At the moment meshes are very unreliable with collisions, and it’s too much work on the physics engine to weld invisible wedge .obj models to a meshpart, so having these kinds of complex collisions would be perfect.
create two separate meshes that each either specialize in visuals or physics
There is a subtle problem with this, if a part is either CanCollide = false (the visual part) or Transparency = 1 (the collision part), then the camera system will pop through the part. This implementation sacrifices camera collisions.
It’s also just inconvenient to have the need to keep the two parts synced up when moving and resizing. Or if the part is to be unanchored, you need to keep the parts welded together.
I’d really like custom collision hulls, but I don’t like this particular implementation. I’d prefer something like what zeuxcg mentioned before; you somehow tag objects as collision meshes, and they’re used for the collision hull when the mesh is imported.
Also, with this implementation it’s unclear how the hull should scale relative to the mesh if the mesh is at a non-default scale when setting the hull.
You could use the importer to make a lot of parts, then union them together to make one part, and the union could be transparent (1 transparency) but have collision, and the mesh would be opaque and have no collision.
The camera wouldn’t be able to go through the transparent union, I believe.
The problem with this is that the union will have it’s own collision mesh generated, therefore defeating the whole purpose. Not only this, but the CSG solver will think the mesh is too complex and not union it.
