Specialmesh vs Meshpart

Ive been severely worried lately about if I should use special meshes for my models or not because I’m worried they might get removed or I’m making the wrong choice. I’m ONLY using the cylinder and sphere shapes.

And would their be any good way to convert my models from specialmesh-to-meshpart?

I would think using the command line and just cloning models with the parts being the exact same but meshpart. (As long as I got a sphere mesh that’s the default.)


Specialmesh is just glorified meshparts with a more “customizable” hitbox (for only box). Meshparts are just glorified Specialmeshes with more customizable render fidelity, accurate collisions, etc.

In terms of which one you can use, you can use both :man_shrugging:, but if you wanted to convert specialmesh to a meshpart.

You can:
Export Selection part OR Union it then Export Selection.
Optimize mesh in blender: Why Meshes Are Superior To Unions And How To Easily Convert Them
Export back into roblox into meshpart.

Fun fact:
You can convert a specialmesh into a normal meshpart IF it has an ID (ex: rbxasset:id//)
Same goes for converting meshpart into specialmesh.

This means you can convert the UGC hats or roblox hats into a meshpart if you wanted to or etc.
However if it doesnt have an id, you’ll have to do the blender route.


Very good information. Using both is a good idea I might consider. One of my main questions though is will specialmeshes be at risk of being deprecated? customizable collision boxes with scale is vital.

1 Like

I’m torn between the two. Right now I generally use MeshParts for environments, and SpecialMeshes for character graphics.


  • :white_check_mark: Accurate collisions
  • :white_check_mark: Better performance for similar MeshParts due to instancing
  • :white_check_mark: Supports LOD, but I don’t think it’s quite ready yet
  • :x: Size cannot be smaller than 0.05 or larger than 2048. Large meshes perform worse than small meshes.
  • :x: Doesn’t support texture compositing on uv map via transparent decals
  • :x: Doesn’t support color tinting, making it useless for character skin tones


  • :white_check_mark: Large graphics-only meshes have great performance if you keep a small part size
  • :white_check_mark: You can create a mesh using just an id, and don’t need to clone an example, so it can be packed into a string for replication if you know what you’re doing
  • :white_check_mark: You can change texture color using mesh.VertexColor
  • :x: Requires 2 instances
  • :x: Can’t use Roblox materials for textures
  • :x: Doesn’t look like it will support LOD any time soon

This is exactly what I needed. But unfortunately the “vital” part for scale is because of the foliage. Due to the type of ranged system I use it doesn’t play nice with any hitboxes including uncolliding ones. So I’ll just have to find some way to work around it or fix it.

1 Like

It’s possible it will be deprecated once MeshParts can do everything SpecialMeshes can, but deprecation does not mean removal, just that MeshParts will likely get better updates and performance improvements. Customizable collision boxes aren’t vital for every use-case. It just depends what you need.

1 Like

For some of my use-cases, I don’t need raycasting so I set the SpecialMesh part’s size to (0.05, 0.05, 0.05) to reduce the chance of collision and improve performance.

1 Like

Thanks for this post. Still helpful to this day.

You mentioned that MeshParts have better performance for similar MeshParts due to instancing. Do SpecialMeshes also take advantage of instancing?

I don’t believe they do, but I could be wrong.
I also made this reply before skinning and SurfaceAppearance textures were released for MeshParts.

Hey thanks for your reply. After 3 years from your previous comment lol. Maybe bumping this post will help us find the answer.