Custom terrain / roadway gripes: Add Enum.CollisionFidelity.Exact and raise the part size limit for MeshParts

As a Roblox developer, it is currently too difficult to create efficient and physically reliable terrain layouts using meshes or CSG.

While Roblox’s smooth terrain system is good, it is not the answer for developers like me who are trying to create massive open world environments that span several tens of thousands of studs across. The system is simply overkill for what I need, and forcing players to load a smooth terrain level of that size would never fly. The only answer is to create terrain layouts using individual parts, as I have traditionally done. I have explored the possibilities of recreating my games’ terrains using MeshParts, but Roblox currently makes a system like that impossible in two ways:

1) Roblox has no option for respecting a mesh object’s exact geometry when creating its default hitbox.

When creating roadways using CSG or MeshParts, it is difficult to guarantee that the roadway’s surface hitbox will follow the exact curvature of the roadway. This issue affects MeshParts far worse than it does CSG, but the issue still remains for both forms of building. With inexact hitboxes, players will find their cars periodically gliding above the visible roadway surface, clipping into the roadway surface, or smashing into hitbox artifacts from nearby terrain.
This issue is particularly detrimental to roadway construction as MeshParts are proving to be the best way to build smooth roadways, which is pivotal to creating a driving experience with controllable vehicles. As it stands, the physics engine currently interprets any microscopic bump (or even a transition between two identically leveled parts!) as an excuse to catapult your wheels into the air when driving at any appreciable speed, forcing vehicles to either lose control or take an unplanned trip to the stratosphere. Using MeshPart construction, it’s guaranteed that these microscopic bumps can be eliminated and that your roadway surfaces will be smooth.

As a demonstration:

Here’s my nice, happy road:

Here’s how I’d generally like it to collide, the collision boxes for each part glide through the dip following exactly where the road visually goes. In portions where the road goes through a hump or a curve, this setup with parts will create those pesky microscopic bumps, but that’s what Blender is for! Right? Wrong.

Here’s how I reduced it in Blender. All the microscopic bumps are gone as are the unnecessary faces underneath, leaving a clean surface that glides across where the individual parts went.

And here’s what happens to the hitbox when I reimport it to Roblox. As you can see, it slices sections of the roadway out and oversimplified it. This left jarring transitions between slopes that clip above the roadway (as you can see by the roadway lines sporadically disappearing), and it also left corners being significantly cut which would cause confusion for anyone trying to interact with that roadside slope.

While the issue isn’t awful persay in the images displayed, it is notably awful near sharp curves, slopes, etc. These limitations with the physics engine and Roblox’s hitbox creation with MeshParts force game creators like me to either choose between poor vehicle handling with parts and CSG as vehicles get flung by microscopic bumps, or wildly inaccurate hitboxes with MeshParts that cause vehicles to glide over or through roadways.

As I have already discussed the issue of microscopic bumps with the physics team to no avail as this is simply just how the physics engine inherently works, I request that Enum.CollisionFidelity.Exact be created for use cases exactly like this, where any amount of simplification done by the Default mode is detrimental to the hitbox’s functional performance as a surface.

2) Roblox limits mesh part sizes to 2048 x 2048 studs.

My maps tend to run large, usually covering swaths of 30-50k square studs. It is not possible to create meshes for sections of roadway, single fields, or a “block” of land surrounded by roads as these areas almost always have an axis that exceeds the 2048 stud limit. I’ve dabbled in the use of FileMeshes for filling in some of these areas, but the issue then becomes that FileMeshes don’t collide, nor do they use Roblox’s materials.

I would greatly appreciate it if this limit were raised, as it would allow me to create better environments with more detail using fewer parts which would drastically increase performance for my players.


I would like to add on to this by saying that all parts under BasePart should have their limits increased to something like 8096 or 16192, or even infinite. I also feel that a thing that could drastically improve terrain in Roblox, is if Roblox added in a terrain system similar to the Source Engine’s. Where it’s a dedicated Part class titled something like “Terrain” or “Editable (maybe?).” Being able to sub-divide, scuplt, move vertices around, etc.

I’d also like to add that Enum.CollisionFidelity.Exact should work for pre-existing MeshParts, if possible.


I strongly support. The hitbox solver for high-poly meshes is great I’m sure, but at low-poly it’s awful and I can’t use the meshes I’ve created for my games because of this. You can check out for the same problem: Mesh hitboxes still off?.

I hope Roblox fixes this soon. My own idea for a solution would just be to have Roblox create exact hitboxes polygon-by-polygon when the polygon count is below a certain threshold, 150 for example. Above that and it will optimize the hitbox.

Integrating the exact hitboxes into Default based on an arbitrary triangle limit would cause issues for me as I’m likely going to be over that limit on most of my surface meshes. A new mode, I feel, would be the best solution for everyone.


That’s a good idea, I like the addition of the new enum.


It would be helpful if this reduced total memory usage compared to creating your own hitbox - most other solutions involve generating separate hitboxes out of wedgeparts, which can be quite inefficient if the algorithm isn’t perfect. However if it ends up using significantly more memory then there doesn’t seem to be much point to this feature, just use a separate hitbox.

1 Like

I tried converting a few of the roads in our map from Special Meshes w/ wedge part hitboxes to MeshParts with default collision fidelity

Way more memory, and I didn’t even convert all of them. I think that answers that…

1 Like

I can support this. I only use meshes for simple props and don’t even consider using them for landscape or actual important aspects of my game because the collisions are always sub-par. If I could pick and choose which meshes to optimize, I would be a happy camper. I’d also finally start taking meshes seriously as a way to make my worlds.

1 Like

Nice, I figured the custom wedgepart hitbox case HAD to be more of a memory hog as a matter of principle. I’m glad to see that noted more empirically, I really hope we get a solution for this.