Note: This whole thing really extended beyond my original scope, but I didn’t want to leave anything out. There may be references to and a bit of feedback on other articles related to the initial topic, and a lot of the principles laid out here are what I recommend be applied generally. It’s quite a long read as a result.
I am referring to this article here: External Modeling | Roblox Creator Documentation
I will admit this feedback is going to be based on my own frustrations, but I can’t imagine that only a few people have had similar issues. Also, I am mainly using Blender, but unless you can get a student license for Maya (if they even offer that), I can’t imagine most modelers here can cough up the ~1.5k to use anything else. In that case, while I understand the need to be universal in the instructions, there should probably be some bias towards Blender, such as what settings or hotkeys to use to do certain things. Anyone using (and affording) Maya is more likely to be very familiar with 3D modeling concepts anyways and should be able to interpret the more general instructions.
Overall, I’d summarize the main issue with this article is that it tells you things you need but doesn’t tell you what those things are. On top of that, I think people would appreciate it if it was explained why certain things should be a certain way. Context, if you will.
In the General section for example:
Make sure your units are set to centimeters.
But why? As far as I can tell this does not affect export size; only what unit Blender uses for coordinates (ie, an object or vertex at 1.2 m will then turn into 120 cm when units are changed). This is confirmed by my tests that show that exporting at the same export scale results in the same meshpart mesh size when imported to Roblox, regardless of which unit you tell Blender to use.
Furthermore, it should be made clear somewhere that the Blender-to-Roblox stud size ratio for an FBX file is 100:1, that is, 1 meter in Blender’s default configuration (which not many modelers have reason to detract from) is 100 studs, requiring you to set a scaling of 0.01 in export settings if you were using meters initially, which I imagine most modelers do. In other words, even if you read this documentation first, it is still not made clear what the Blender meter or Blender centimeter to Roblox stud conversion rate is. It means little to the reader until it’s put in context. A number of users like myself may also not read this article too deeply until they have already made the initial form of the avatar, by which point they likely will have already been modeling with meters.
The best that the Developer Hub can offer is the troubleshooting section on meshparts which mentions a scenario about Extremely Large FBX Files Exported From Blender, in which it mentions that “Blender may apply a scaling factor when exporting a mesh as an .fbx file”, but again does not specify the actual numerical value of this scaling factor. It also suggests using .obj but the Avatar Importer article only says to use .fbx.
Right, back to the Avatar Importer article, pardon my tangent.
The article mentions the relationship between “Geo meshes” and their parents and their transform values relative to their parents. What’s a geo mesh? How do we clear/apply transform values? Yes, it can be concluded, but not learned, that the geo mesh is the actual mesh object representing the look and shape of the respective body part. For a platform that is supposed to be a viable starting point for prospective and younger game developers, the documentation overall requires a lot of assumption on the reader’s part and assumption of prior knowledge.
One CRITICAL missing piece of information is the fact that the types of objects representing joints are empties, which after scouring the article several times and even using CTRL+F on the page, are not mentioned at all. Ever. The fact that attachments are stated to be meshes can very understandably lead the reader to erroneously conclude that the joints too, are meshes with a certain name. Take a look at the hierarchy table:
Other than not mentioning empties for the entirety of the article as previously mentioned, it is not made clear that Head for example is the location of the empty where the actual joint representing the “Neck” motor6D is going to end up. Apply that to all other joints. In fact “motor6D” is likewise oddly entirely absent from the article. The word “joint” is used, but again, the article does not specify where or what in the hierarchy table joints are. In essence, something like the following example would make the instructions much more clear:
Geo meshes (which are the ones named “[body part]_Geo”) are parented to empties, which are the ones named after the respective body part in the hierarchy. Root and HumanoidRootNode are empties as well.
followed by:
The location of the empties determine the location where the avatar importer will generate motor6Ds for the avatar’s various joints. For example, the Head empty will become the Neck motor6D, the LeftUpperArm empty will become the LeftShoulder motor6D, ect.
Finally, having figured it out with a combination of intuition and luck and replacing all the meshes with empties, I ran into this problem documented here: Avatar Importer imports rig backwards relative to everything else - #2 by SkyKurr
Numerous attempts to fix the thing brought me nearly to wits end, and I essentially concluded that I’d have to rotate the body parts 180° and tediously place the joints back to the correct spot; simply mirroring them over the X axis risked messing up how the transform information for the empties were read.
Before I attempted that however, I took and shot in the dark and on a whim I selected everything in the .blend file and turned it 180°, so that the model was essentially “looking towards” Global -Y. As you can see in the linked thread, that fixed it for some reason. There is hardly existent or easily accessible documentation that explains why this worked. The Developer Hub page definitely should have mentioned this hidden requirement.
At best I can figure is that Roblox reads FBX files differently from how Blender exports them. Whether this is an issue on Blender or Roblox’s end is beyond me. Maybe one of these export options can help:
However, changing these settings to every conceivable variation didn’t seem to help, possibly because whatever is causing the issue is equally affected by the transform settings. (This is almost turning into Platform/Engine Feedback but these are issues easily remedied with proper documentation.)
I think that’s all. Again, sorry for the long read.
