3d importer frequently fails to import certain bones of a skinned mesh

Thanks for the report! We’ll follow up when we have an update for you.

4 Likes

I also have a rigify rig whose bones are not importing properly or at all.

1 Like

Sorry for the bump, but this really needs to be fixed.

This is an issue for a model I’ve been trying to import


It uses bones for the origin of certain models. I need a reference so I can transfer the origins from the bones, but Roblox won’t let me import just the bones.

1 Like

Going to bump again, this is a ongoing issue that STILL happens and is heavily affecting & even halting my workflow and ability to work on my projects.


magbone2

This has happened with multiple rigs of mine and seemingly at random a certain bone will not import at all.

1 Like

Found somewhat of a solution.

The missing bone was called “Mag”. It was then renamed to “Mag2” and suddenly started importing properly.

Try renaming your bones to see if any of them are fixed like this.

2 Likes

Where are you renaming them for this to work? In Blender or on the import screen to Roblox?

You have to rename them in blender, they dont exist/arent imported in roblox.

Hey sorry it took so long to get around to this, we will take a look

1 Like

We currently intentionally remove bones that have no vertices tied to them. Can you all share why you want unused bones to be imported? We can re-consider that choice depending on the use cases.

1 Like

Given that Bone instances are a subclass of the Attachment class, bones can be used in combination with RigidConstraints to attach accessories to skinned MeshParts - where the bone acts as an attachment point. This seems to be the intended workflow as per this staff post from a few years ago: Skinned MeshPart Studio Beta - #268 by ContextLost

However, as soon as you use a RigidConstraint to attach an accessory to a skinned MeshPart you will run into a problem. When you set a bone as Attachment0 and the accessory’s attachment as Attachment1 inside the RigidConstraint, the constraint will move the accessory such that the bone and attachment overlap exactlyt. This means you will either have to:

  1. Edit the position attachment inside the accessory
  2. Add additional bones to the skinned MeshPart that act as ‘attachment points’ for accessories.

Option 2. is in this case far superior for a multitude of reasons:

  • The additional bones can be animated individually, giving more control over potentially animating accessories separately from your skinned MeshPart while maintaining relative positioning to the skinned MeshPart.
  • If you are making a game where players can run around as custom characters while still having some of their personal accessories equipped (for example in a game where you turn into a robot character but you still get to wear your scarf, backpack, etc.) you cannot expect the developer to edit all existing accessories players could wear so that their attachments line up correctly with your skinned MeshPart.

In my case I am working on a game with custom characters that also wear accessories I created. I intend to sell those accessories as UGC items as well, so my main priority is ensuring that the attachment inside each accessory is placed such that these accessories fit the average Roblox character. So my custom characters will need these vertexless bones to act as attachment points.

My current work-around for this problem is making sure that these bones that act as attachment points are tied to exactly 1 vertex and have a weight low enough to be almost neglectible but still get picked up by the importer. As you may guess, that workflow is not intuitive and I wish that could be changed.


Another use-case was mentioned earlier in this topic as well:

1 Like

Also to add onto my previous reply, maybe it wasn’t clear from my original post, but the video I attached to the bug report does show me adding a vertex to the bone (timestamp 0:48). I also verify if the vertex is moving along with the bone when transformed (timestamp 1:25).

So unless I am misunderstanding how bones work, it seems that the importer also refuses to import bones currently that have a weight below a certain threshold. If so, such arbitrary restrictions open the door for a lot of confusion unless explicitly documented.

This issue is actually still happening and causing discrepancies between the rig from my modeler and what I’m seeing in studio , it seems like studio is removing some bones as if they are leaf bones with no influences but they do affect the rig, and it’s removing bones unreliably for the skinned mesh character .

2 Likes

2 months later and we’re still struggling with this issue.
The problem for me comes from external modelling, whether it’s importing assets from a game or using models from non-Roblox developers. And as mentioned before, vertexless bones can be used as points for attaching accessories. I don’t see why it’d be intentional to exclude such bones from the importing process when those bones are typically made for a reason. Why not make it an option when importing?

3 Likes

This is still an issue. Randomly removes bones that are tied to vertices.

1 Like

Would be useful for IK controls.

Trying to use the hand bone for an IK control so I can have great precision on how my custom character moves its arms, since using a bone, and then a bodypart/attachment doesn’t work very well together at all.

2 Likes

Thanks for all your feedback. Makes sense why you want to keep bones even with zero/low weights. We will work on adding support for that and you should expect a solution in the next month or so.

2 Likes

Thanks so much! :heart:

I have had this problem for a while, but finally you are making the necessary efforts to resolve it.
I really hope you can get it fixed sooner than the date you specified.

Hi, we decided to handle your use cases by allowing you to opt in to keeping bones that have zero influences. The import preview window should now show a check box that says Keep Zero Influence Bones. It will default to false but if you check it, all bones should be imported.

7 Likes

Thank you for having reconsidered this design choice and adding the checkbox! :raised_hands:

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.