Roblox Mesh Ids

Understanding how 3D models actually work inside Roblox

Most people who stumble into Roblox 3D development quickly hit a wall when they try to import custom geometry. The system doesn't accept Blender or Maya files directly. Instead, you export to .fbx, upload through the Creator Dashboard, and then you're handed a number. That number is your Roblox Mesh Id. It sounds simple, but getting models to actually look right in-engine involves more than just finding the ID and slapping it onto a MeshPart. A Roblox Mesh Id is a unique identifier assigned to a 3D mesh asset hosted on Roblox's servers. When you upload an .fbx file as a mesh asset, the platform converts it and assigns that persistent ID. You then reference it in Lua with the MeshId property, prefixed by http://www.roblox.com/asset/?id= or simply using the Content: from type MeshPart. The practical workflow looks like this. You prepare your model in Blender, making sure normals are clean and the triangulation isn't a mess. Export as .fbx with Apply Modifiers checked and Armature Removed if you don't need animation rigging in the upload. Upload to the Roblox Creator Portal under the 3D Assets section. Once processing finishes, you copy the asset ID from the URL bar and paste it into your MeshPart.MeshId property in Studio. That's the basic path. It takes maybe 5 minutes per model once you've done it a dozen times.

Here is where things get interesting, though. Roblox Mesh Ids do not preserve PBR materials the way you might expect from other engines. The upload process strips most material data and converts everything to a basic texture approach. Your diffuse map comes through, but roughness and metallic values are either lost or mapped in an undocumented way. I spent about three weeks trying to get normal maps to work correctly on uploaded mesh assets before I figured out that Roblox's mesh pipeline essentially flattens any normal map into the base color channel through a gamma adjustment that has nothing to do with standard PBR. The workaround I ended up using was baking the normal information into the diffuse texture itself at export time. Render the normal map in Blender, overlay it onto your base color texture with the Multiply blend mode set to roughly 60% opacity, and upload that combined texture. It is not a perfect solution. The models look slightly flat under dynamic lighting, but they are acceptable for most in-game environments. This approach cut my iteration time from about 45 minutes per model down to roughly 8 minutes because I stopped fighting the engine's material pipeline. There is also a hard polygon limit that catches people off guard. Roblox imposes a vertex count ceiling on mesh assets, and it varies depending on whether the asset is being used in a experience meant for mobile or PC. The unofficial limit appears to sit around 65,000 vertices per mesh for most purposes. Exceed it and the upload either fails silently or produces a corrupted mesh that renders as a blank gray shape in Studio. I learned this the hard way when a detailed chair model I had been working on for an hour simply vanished from the workspace after upload. The console showed no error. The mesh just wasn't there. I had to go back and decimate the geometry, which took another 30 minutes of retopology work.

Another thing that nobody mentions in the official documentation is that mesh assets are cached server-side for a period of time after upload. If you update a mesh with the same asset ID, old clients that have already loaded the previous version may continue rendering the old geometry for several seconds or even minutes. This causes desynchronization between what the developer sees in Studio and what players are actually experiencing. The fix is to increment the asset version or use a unique ID strategy where you generate a new asset each time something changes during development. That means keeping a separate spreadsheet tracking which ID corresponds to which model revision. It is annoying but necessary if you are shipping frequent updates. File format matters more than most people realize. Roblox accepts .fbx and .obj files for mesh uploads, but .fbx is the better choice for anything beyond simple geometry. The .fbx format preserves UV coordinates, which means your texture mapping stays intact through the upload process. With .obj files, UV information sometimes gets mangled during conversion, and you end up with textures that look stretched or rotated wrong. I switched from .obj to .fbx exports about two years ago and saved probably 20 hours of retexturing work across a single project. For animation, mesh assets support SkinnedMesh objects, but the rigging requirements are strict. The bone structure has to match exactly what Roblox expects, and the skinning weights need to be clean. Broken weight painting results in meshes that look fine at rest pose but distort horribly when animated. There is no debug mode for this. You only find out when you playtest and watch your character's arm fold backward like a broken hinge.

The biggest limitation of Roblox Mesh Ids is that they are fundamentally a static geometry solution. You cannot update the geometry of an existing mesh asset without creating a new one. There is no procedural update path. If you need to change the shape of a model after deployment, you publish a new asset, update the ID in your scripts, and hope no one has the old one cached. This is a bottleneck for anyone building games that rely on dynamic world modification or player-generated content using custom meshes. If you are working on a project that requires frequent mesh updates or procedural geometry, the alternative path is to build models using Roblox's built-in geometry primitives and CSG operations. It is less visually precise but avoids the entire asset pipeline problem. For most projects though, the MeshId approach is fine. Just keep your vertex counts reasonable, bake your materials correctly, and don't trust that an uploaded mesh will look exactly the same in-game as it does in Blender.