Thanks!, i found out what the problem is… i tracked the wrong part
anyways! it works now!!! thanks!!
Thanks!, i found out what the problem is… i tracked the wrong part
anyways! it works now!!! thanks!!
I’ve been trying to import custom rigs for months now, and have been experiencing a really strange issue which I still have no clue how to fix, and i genuinely cannot find any answers on this forum as of now:
When you import a “custom” rig, with moving parts of the mesh separated and bones matching each parts name (so that the MeshParts are connected via Motor6Ds and don’t deform using Bones), if you attempt to import an animation, they either don’t work at all or are distorted.
(I am using Blender 2.91.2)
Heres it happening with the example “S15_Lola_IPose.fbx” rig:
(each objects name has had the “_Geo” suffix removed, which mimics a custom rig)
In Blender:
Rig imported through “Custom”, with animation:
Even with the _Geo suffixes added back, and using the rthro import option, while it looks better, you still get the same issue of the animation being incorrect.
When exporting, i have the “Camera” and “Lamp” object type toggled off, and even have “Selected Objects” toggled on so that it does not include anything but the object + armature itself.
I’m very unsure if there is some special way you are supposed to export rigs from blender to studio, or if this is an issue with studio itself.
This is the “part cant be named the same as the bone” bug I mentioned a few posts up. Just change the names, and it works. What happens is this:
If you name the bones the same names as the parts/objects, it uses the parts as the bones via Motor6Ds. I am 70% sure this is intended behaviour if the user wants to preserve the hitboxes for their rigs, or wishes for their rig to be compatible with their current game that uses R15, as seen here.
I personally need the rig to be like this so i can distinguish between the different parts of the rig (headshots, bodyshots, etc) and so that im able to easily connect objects to each bodypart without having to rig it in Blender.
You mentioned that you will be able to attach MeshParts to Bones soon, would you have any estimate when this will become a feature?
You are going to have to modify your parts’ origins so that they behave identically to the R15 rig. I’m not aware of any guidance online how to position your axes, so you might be experimenting a bit.
I am a little bit unsure what you mean by “moving parts origins so they behave like the R15 rig”.
Do you mean moving the object’s origins in Blender, and then importing? Because if so, the origins in Blender do not influence how the model is rigged and moves. Or do you mean modifying the C0 and C1 of the Motor6Ds that connect each MeshPart? because for rigs that don’t follow R15 whatsoever and are completely custom (for instance, Viewmodel rigs for FPS games, or just rigs that have hugely different proportions), I don’t see how this will apply.
When the bone and mesh have the same name, whether R15 or not, the mesh becomes the bone and the origin is the pivot point. That’s why so many people in this thread had weird deformations.
I had a tiny tiny cube correctly labelled left hand, just to be sure. The pivot point was the torso, which was the origin of the part.
How does Lola manage to keep her RootPart in her character when uploaded with the plugin?
My custom import (a different character) with the exact-same rigging name convention has the RootPart all the way out in space / not near the imported character, sort of like this (to provide an example):
Any help would be appreciated.
the rootpart is generated at 0,0,0 in blender.
Ah that must be why, the avatar I am exporting is not at the root, so I will try that.
Alternatively, I will try forcefully repositioning the root in studio while maintaining the bone positions.
Ho ahead, but exported animations will be messed up with the force reposition method if im not mistaken.
I’m going back to the original idea that triggered my current problem. I’m trying to split up my animations now.
“any priority will overlap if there are no keyframes assigned to a certain bone”
Unfortunately, the animation importer/editor (or blender, I’m not sure which) assigns keyframes to all bones, all frames. The editor portion of the plugin is not equipped to handle this. It seems like an absolute train wreck…
Edit: looks to be a failure of Blender, circa 2017. No solution available. Roblox could bypass this with a way to select multiple tracks and either delete selected or extract selected into new animation.
Somehow i was clicking to check articles again but page didn’t exists
This is where i clicked
now i ended up with
now i’m confused and i want to check what’s S15 requirements please bring it back
OK, it took a couple days, but I solved it. In order to bypass the FBX issues caused by Blender, I had to build an animation splitter plug-in.
I didn’t even realize I had this skill…
This gave me access to just the animation in the left arm, and loaded it as a core animation, which brought the arm out of the T pose for the default jump… This might even look good once I replace that animation, which apparently makes arms flap in the breeze.
But for now, I have defeated the beast! Wow, that was painful… I hope Roblox has some better tools coming for skinned meshparts and animations. I have tons of ideas, but no access to those discussions.
Sorry for the really late reply, I didn’t see this post and didn’t know what change has been made that was messing up my imports. I assume it is related to this, as this affects something that is somewhat similar to what I assume 3D clothing will be like in function. I’m not too sure if it is related to the same exact update however, but probably, in some capacity.
I can’t post in #bug-reports so I made a post in #help-and-feedback:art-design-support :
Custom rig importing with Avatar Importer is broken in recent update (causes floating eyes?) - Help and Feedback / Art Design Support - DevForum | Roblox
In short, the same file I have uploaded just days prior started behaving strangely, as when I uploaded it again, the eyes were floating.
(Screenshot from my post):
I assume this is related to the 3D clothing updates, since the eye is a single mesh with a few faces, facing outwards, like how I assume 3D clothing will be like. Oddly enough when I made some more of these types of meshes as an example (just duplicated the topology of the head and other parts of the body, then separated them to a different object) then they didn’t float. Only if I duplicated and did this with the vertices of the eyelids did it happen. So it’s probably related to some complicated vertex data stuff that I don’t understand.
I later figured out a workaround, which was to add a lot more vertices to the eyes. Because I noticed if I added just a few more, then the eyes would float a bit closer to the head. So going off that logic, I added a lot more vertices. I assume this works on some form of a weight based system. I actually made a complete(-ish) eyeball with a bit more vertices and it worked, now it is at the place where it’s supposed to be when I import.
On the bright side of things, now I can make the eyes rotate.
The change I mentioned was only enabled for a couple of hours that morning, so if this issue persisted longer than that, it is something unrelated. I will share your post with the importer group, maybe they will have an idea.
Floating parts for me have always been a function of part origins. Now everything gets the same origin as the rig (which also becomes the HRP).
I was thinking that too in retrospect but then how did adding more vertices fix it? And setting the eyes’ origin to gemoetry/to world origin didn’t actually change anything either when I imported them. They are literally just not where they are supposed to be on import, unless I add a bunch more geometry to them to weigh them down.
Also for some reason for me the HRP is still given at the world origin instead of the center of the rig, so I don’t think that update is quite out yet.
And when I select them, the highlight box (or their actual position) is at the right place, but the mesh itself is just somehow messed up. If I move their bone they snap back to place but their motor6D breaks.
Either way doesn’t matter anymore since I fixed it by the method I described above.
By the way never really posted a demo of what I’m doing here, so here’s a short recording. Going to be some sort of a fighting game demo since I don’t have much free time, but I have plans to make some kind of an RPG later on. Although the whole idea of mesh deformation characters might not be that groundbreaking of an idea on Roblox by that time.
Also learned scripting just for this, or more like while messing around with it, pretty fun so far.
Cool stuff that it has, as of now:
(Also besides other stuff but these are what are mainly related to skinned meshes and I’m gonna keep this related to the topic)
So yeah if anyone needs some help then feel free to ask, I have gone through a lot of trial and error to figure these out and now I have some experience.
One main thing that is still a problem is hitboxes, since they don’t really move with animations. But I do have some things in mind, so I will report back when I get to messing around with them.
Edit: Since I still see people stumbling into this post once in a while, I’d like to note that I attempted doing this again in favor of using layered clothing and for that I remade the whole thing. Basically you still need a character that follows the r15 schema (15 separate limbs) but you can skin it so that it bends all the same. If you average the normals along the cuts then there won’t be visible seams between the bodyparts either.