Hey everyone! I have extended this to include a WIP specification for version 4.00 of Roblox’s mesh format. I still haven’t fully deciphered the purpose of all the data it stores, but I’ve got it down enough to where it can at least be read fully.
Check out the version 4.00 [WIP] section to learn more!
Let me know if you guys have any insights to things I left stubbed out or wasn’t sure about.
Some time ago, I discovered some Python 2 code for a .mesh parser on GitHub and modified it to run standalone. Though these changes weren’t major, I’ve since lost it to hard-disk damage.
Um I have a question I gotta ask, Um how do you write the script mesh format 4.00 on the roblox studio?. Because I was trying to import a mesh the has like between 46k and 70k tris. And I was trying to figure out a way how to import them. But I don’t how to make a script for it to reduce it’s self. And I really need some help to learn how to do it.
Has anyone written anything that can read 1.00 mesh data and export it to a .obj?
Really very interesting, I think I will use it for a project. Thanks for that! P.S.: How did you even get this information out?
I reverse engineered it, nothing too special lol.
Wow, I didn’t know. Anyway, it sounds very interesting, thanks for that!
This to me, seems to be incorrect, at least for 1.00 meshes. I wrote a parser for 1.x and 2/3 meshes, and whenever I invert the tex_V coord like mentioned here, textures look incorrect
From checking some of the S15_Lola V4.00 mesh files I have the following comments that may be useful.
The meshHeader field numSkinData is only 16 bits not 32 (and is followed by a 16 bit number set to 1 in mesh files used for S15_Lola)
There is no meshHeader field to define the number of Envelopes so it is the same as numVertices except when the numBones is zero when there are no Envelope structs in the file.
The SkinData struct appears to be an extension to the LOD data (the facesBegin and facesLength contain the same information).
The SkinData struct would appear to define a different section of the shared vertex and face array and to allow the mapping of bone indices to the bone array.
I did notice a couple of these the other day when I was fixing some implementation issues with the mesh format in Rbx2Source
Hey everyone.
I’ve made a revision to the spec which accounts for the new tangent vector data, which is packed into the 4 bytes that were previously used for the UV’s dummied out tw Z-coordinate.
Let me know if you have any questions!
Made another set of revisions to finalize a majority of the version 4.00 mesh format specification!
ofc maybe we can of version format revisions that’s how mesh like question
One last update to specify how the envelopes are tied to the mesh subsets and to clear the last 2 undefined bytes in the MeshHeader. The version 4.00 spec should be 100% complete now!
Let me know if you guys have any questions.
Have updated this with a WIP spec for version 5.00! I think I figured out most of it, but still need to do some experiments to make sure I’m covering it all correctly.
At the very least it should be trivial to read the data into a structure that fits the data 
The version 5.00 mesh spec is now 99.9% done! Just need to figure out the purpose of unknown_offset, but everything else has been fully cracked! 
Enjoy!
Thats very kind of you to keep this up to date even after 3 years. Also, I was wondering if there are any decoders for v4 and 5 meshes?
[EDIT] : It is actually possible to download meshes directly in the .OBJ (only face, vertices and uv data) format by using https://thumbnails.roblox.com/v1/assets-thumbnail-3d?assetId=AssetId
This will return an URL under ‘imageUrl’ field which will return the URL for the .OBJ object under ‘obj’ field.
Interesting! How would I use this API to read the mesh format data itself? I want to be able to count triangles in a Studio session.
I’m pretty sure you can upload the meshes directly through the mesh upload API if you have the mesh already converted to this format, I haven’t tested it fully though
You could also load in the mesh using PromptImportFile or local content paths but these have their own problems (mainly asset caching)
I’ve made some final amendments and corrections to version 5.00 and made a placeholder section for version 6.00, which isn’t being used in practice yet but does exist.
I can now say I’m 100% confident in my spec for version 5.00 and have implemented it in practice!
I have a reader for the mesh format fully implemented in --!strict Luau here if anyone is looking for a reference:
