Issue Type: Other
Impact: Moderate
Frequency: Constantly
Date First Experienced:
Date Last Experienced: 2021-03-02 23:03:00 (-07:00)
Reproduction Steps:
Get an FBX format file compatible with the Avatar Importer. Import it using the Custom and R15 options in the Avatar Importer. Observe results.
Example provided in private message.
Expected Behavior:
Note: As definitive documentation on how actually correctly set up an FBX file for custom Avatars is, to only slightly exaggerate, absolutely elusive, I cannot guarantee that I am doing everything correctly. My expected results here will be based off of literal weeks of manually using a series of trial and error and educated guesses before attaining a working result before the bugs in this bug report broke everything again. Anyways—
(I’ll be often abbreviating “Motor6D” as “M6D” for brevity)
What I believe to be the expected result:
For every empty, and starting from the highest (top) object within the authoring software’s (Blender in this case) object hierarchy, which should be an empty as well—
- Check if the empty has a mesh child that has the same name but with _Geo at the end
- Create a Motor6D on the _Geo mesh, with
Part1being that same mesh, andPart0being the parent mesh, if one exists. The M6D’s pivot point will be the same location as the empty was within the authoring program. For the very top empty in the hierarchy, a root part is generated on import. - Search for any child meshes under the empty with _Att at the end. Create attachments on the origin of each _Att mesh on the same location as they were within the authoring software, and set all their
Parents to the empty’s _Geo mesh.
Repeat for every empty found in the imported FBX file, going down the hierarchy.
The R15 import option also generates a humanoid and other avatar metadata and is supposedly more strict with the mesh naming convention but otherwise acts almost exactly the same. It also generates additional attachments on each Motor6D location, which the Custom option does not do.
The ability of the Avatar Importer to create Motor6Ds and attachment points in exactly the correct locations makes it perfect for cylindrical joints for animating mechanical props as well as conveniently having the attachments used to line up the modular parts that we use for our weapon and vehicle system in our game. For example, this is the only practical way to make sure that something like a tank turret or door hinge pivots exactly where it needs to without any “wobbling” as there is no way to do so within Studio anywhere near as fast. For the attachments, we (and I imagine other games) use them to line up where one part of an object lines up with another, allowing us to dynamically swap out parts of objects at will without any overlap, gaps, or misalignment. I might turn this particular aspect into a feature request later on as an extension of the Avatar Importer’s abilities.
That being said, assuming the Avatar Importer actually works as expected, using it this way should work completely fine as well, as there aren’t any external factors or extra steps outside the actual custom avatar workflow being used here; we’re just using the generated objects in a slightly different way after the fact.
Actual Behavior:
For the “Custom” option:
- RootPart part is generated at the relative [0,0,0] position (relative to any other meshes within the FBX file) in the authoring software, even if one was never exported. If an empty named “Root” is in fact required, please make this more clear.
- All attachments are generated in their correct locations
but are all parented to RootPart.and under the correct mesh (see workaround below). - A Motor6D is correctly generated on each _Geo mesh that was under an empty with
Part1being the respective _Geo mesh, butPart0for every M6D is RootPart instead of the preceeding parent mesh.-
The pivot point for every M6D is in the center of RootPart, which further prevents any attempt to animate the rig correctly.This is now fixed, with the pivot points now in the correct spots. The incorrect parenting part of this bug makes this fix meaningless however.
-
For the “R15” export option:
- HumanoidRootPart is generated wherever it was set to within authoring software, which is expected. If not set, generates at relative [0,0,0] as it does above.
- Any attachments that don’t have Root as their parent do not generate. This is probably expected as R15 otherwise looks for attachments with the correct name, but is relevant to the workaround.
- Unlike the Custom option, the pivot points for every Motor6D are in the correct spot and the rig can be animated correctly.
Workaround:
The only workaround I’ve determined is to import the rig as an R15, which at least leaves the rig able to be animated. However, you must put any custom-named attachments under Root on import. This requires you to then move all the attachments to their correct parents within Studio. The issue is that because attachments keep their Position property when re-parented, and Position is relative to the mesh’s bounding box, this means that they never maintain the same WorldPosition value. This can be avoided by first copying the WorldPosition, re-parenting the attachment, then pasting the WorldPosition back in to restore where it’s supposed to be.
However, as a separate but related minor bug, WorldPosition does not automatically update when the attachment is re-parented and copying and pasting the old one doesn’t work as the attachment still thinks it’s in the same spot as before and so doesn’t bother to move itself. This can be fixed by deselecting the attachment and selecting it again, after which the WorldPosition value is correct and allows you to paste the old one to restore the attachment’s position. This makes the already tedious workaround process even more so.
At the time of writing this bug report, the Custom option suddenly now correctly puts attachments under the correct mesh instead of RootPart. I cannot be assured that at least this part of the process will remain fixed and recommend it still gets looked at, but for now the workaround is as follows:
- Import the FBX file twice; once as an R15 avatar and once as a Custom avatar.
- Clean up all R15 avatar related objects as desired.
- Move all attachments from the Custom avatar to their counterparts in the R15 Avatar. Since each pair of meshes has identical bounding boxes, all attachments should be in the same relative position.
You now have a rigged model with the correct Motor6D placement of the R15 import combined with the correct and convenient attachment placement of the Custom import. hooray
This workaround of course is not exactly convenient, and since I need to import each avatar twice, it doubles the amount of storage space needed in Roblox’s servers for every “completed” model/avatar. There’s also the need to delete all the avatar related stuff and replace the Humanoid with an Animation Controller. In total, this is very disruptive to my workflow.
This whole thing may be related to the issue I reported here some time ago, which is where I got the original, now crossed out workaround.