When set to a mesh ID, that mesh is used as the collision mesh.
If the collision mesh is complex, a pop-up appears warning the user that it might cause performance issues.
Objectively, this is a super weird feature request.
But I think it makes a lot of sense in the context of ROBLOX.
4 Likes
Frankly I think you could accomplish this behavior by welding an invisible Mesh to the visible, non-collidable Mesh, so I’m not sure this feature would be necessary. I guess it just depends on what you’re trying to make.
1 Like
Might be worth noting this wouldn’t work for raycasting without some hacky whitelist/blacklist-ing.
Maybe a better feature request would be to have a collision option that better approximates the mesh rather than what Default does. I don’t think anyone would want to give their mesh a radically different hitbox than the mesh being rendered, so this seems like a simpler request rather than setting an arbitrary collision mesh.
Not to mention that arbitrary meshes aren’t necessarily sealed.
Better yet - support for custom made collision within the fbx.
Unreal has a feature when you import an fbx with mesh layers named using the prefix “UCX_” will automatically create collision based on each closed convex 3D shape.
2 Likes
Bumping this, currently need it for my terrain optimization project at my studio. We’re experiencing major difficulty with collisions due to Roblox’s hull decomp algorithm using voxels, which are strained at larger sizes (terrain). This is requiring us to either use hundreds of unique MeshParts for the colliders (based on an approximation of the convex hull decomp algo Roblox uses) and then merged meshes on top or generating thousands of WedgeParts to act as the colliders.
Both of these options could be circumvented given the mesh is extremely low in poly count if we could set a raw CollisionID or make our own hull in Blender and use that.
Old feature request, but 100% a good idea.
1 Like