Separate meshpart visual and collision meshes

[NWSpacek]

I am making a railroading game, and it would be very helpful if I could have a collision model slightly different than the visual mesh.

Consider this old railroad track:

It’s 3 blocks, with 1x1 rails set 4 studs apart and a mesh to make the rail look 0.7 studs wide.

Here is the same track, but using meshes. Instead of a 1 stud tall railbed, its now 1.5 studs, and instead of a 1 stud tall rail, I’ve used meshes to scale the rail down to 0.5 studs high. Overall, the same track. Except for one problem: the trains ride 0.5 studs higher in the air. Trains already made with 1 stud rail heights in mind cannot run on the new tracks, and there is a possibility that the train-rail interfaces in PGS will be inclined to derail more often with the shorter height.

So what are the current possible solutions?

• Use an additional brick as the collision mesh. This is undesirable because it will inflate the brick count a considerable amount in the game I am making.
• Use a Special Mesh. This is undesirable because Special Meshes cannot have textures applied to them, like the tie texture, and cannot display material textures, like the pebble texture.
• Raise the rail bricks up by 0.5 studs and offset the rail mesh to the bottom. This is undesirable because a lot of rolling stock is made for rails that are 1 stud tall and would float in the air.
• Just leave it as it is. This is undesirable because PGS physics requires balls as the interface between the train and the track, and they can probably climb over the 0.5 stud high wall for the masses I expect to be using and the trains would float in the air like the previous bullet.

None of these fit the bill perfectly, each has only two of the necessary components: small footprint, visuals, and compatibility.

[bigcrazycarboy]

Support. I know that in BeamNG.Drive, the way collision meshes are handled is by having 2 groups in Blender (or the modelling program) and when the mesh is imported, the engine would look for that collision mesh, and make it transparent. This way people can have whatever type of collision they want without needing to recreate their mesh in roblox. This also works well with large meshes.

[Xan_TheDragon (Xan)]

I suggested something somewhat similar to your idea proposed here.

MeshPart collisions enhanced: Allow us to upload dedicated collision models

So I was looking at how roblox does calculation for collisions and I managed to find an old thread on why exact decompositions aren’t likely to happen. Thinking about ways to improve it got the gears turning in my head, and it hit me pretty quick: What if there was a new asset type called “CollisionMesh” (or something similar) where the user could upload a mesh that has under or equal to say, 650 triangles. The mesh would be limited to low triangle count, but would always have an exact decompos…

[NWSpacek]

I searched “mesh collisions” before I posted so :shrug:

[AllYourBlox]

@NWSpacek

Use an additional brick as the collision mesh. This is undesirable because it will inflate the brick count a considerable amount in the game I am making.

I wouldn’t write this off until you’ve tried it and proven that it’s not viable, which should take only a couple of minutes in studio to place thousands of sections with a for loop. A few bricks per section of track doesn’t seem like it would be a problem, especially if they’re all anchored. You’d have total control over fine-tuning the collision shape of your tracks without being at the mercy of any decomposition algorithm (so more future-proof too). Your actual mesh will be CanCollide=false, so you’re removing some overhead as well.

[Xan_TheDragon (Xan)]

@AllYourBlox

You’d have total control over fine-tuning the collision shape of your tracks without being at the mercy of any decomposition algorithm (so more future-proof too). Your actual mesh will be CanCollide=false, so you’re removing some overhead as well.

This is true. You could try doing this method.