In that case you are severely misinformed.
Who is ‘we’? I don’t mean to be that person but you appear to have no experience in professional Roblox development, let alone game development.
16 Likes
Animations dont work. There is no error but it doesnt seems to load into the bones
1 Like
“But will the Skinned MeshPart support only a single mesh part or multiple mesh parts?”
Each MeshPart has a single meshId.
“Also will there be a tutorial for using Skinned MeshParts? (In Roblox)”
Yes
“And finally, will the rig limit stay to 50K after the beta?”
Not sure.
“Anyways, this is a great feature! Keep up the good work!”
Thank you
3 Likes
It only works in studio now
30char
2 Likes
I’m super excited about the new features of this update. But I still think r6 and r15 are iconic to the game. Changing this could make people not want to play anymore.
1 Like
If I’m allowed to ask, what changes were made to the mesh format between Avatar Evolution and now? I’ve been working on a reverse engineered spec of the format for people making 3rd party extensions.
Although I don’t have it 100% accurate yet, I was able to figure out enough of it to where I could reliably read all of its data.
Currently I have the following pseudo-header spec:
// version 4.00
// Additional types are defined below.
struct Mesh
{
MeshHeader header;
Vertex[numVerts] verts;
Envelope[numVerts] envelopes;
Face[numFaces] faces;
int[numLODs] lods;
Bone[numBones] bones;
byte[nameTableSize] nameTable;
SkinData[numSkinData] skinData;
}
struct MeshHeader
{
short sizeof_MeshHeader;
short numMeshes;
int numVerts;
int numFaces;
short numLODs;
short numBones;
int nameTableSize;
int numSkinData;
}
struct Vertex
{
float px, py, pz;
float nx, ny, nz;
float tu, tv, tw;
byte r, g, b, a;
}
struct Envelope
{
byte bones[4]; // [citation needed]
byte weights[4]; // [citation needed]
}
struct Face
{
uint a, b, c;
}
struct Bone
{
int nameTableIndex;
short id; // [citation needed]
short parent;
float unknown; // [stub]
float r00, r01, r02;
float r10, r11, r12;
float r20, r21, r22;
float x, y, z;
}
byte[nameTableSize] nameTable;
struct SkinData
{
int facesBegin;
int facesLength;
int vertsBegin;
int vertsLength;
int numBoneIndices;
short boneIndices[23];
}
The actual spec I wrote can be found here:
(cc @RobieTheCat)
8 Likes
This is really exciting! I can’t wait to see what people will create using this.
1 Like
Hey! No looking behind the curtain. 
The mesh format has not changed from AvatarEvolution.
7 Likes
We gotta do what we gotta do 
I was actually more interested to know if something changed here:
3 Likes
Ah right, I remember this now. I did remap this character to use R15 format of 4 separate textures for Head, Torso, Arms and Legs. The earliest version of her had a single texture atlas for the whole character, which was set on all 5 of the key R15 body parts, such that the Humanoid compositor was baking tiny copies of her whole atlas into each region of it’s composite (e.g a copy of her whole character texture in the leg area, arm area, head area, etc… of the Humanoid composite). If the figure on the right is this old version of her, then she’s not a good example of what a skinned R15 will look like, and the character on the left is standard avatar resolution.
4 Likes
Thank you for all the work you guys put into giving developers the tools to make some incredible creations, can’t wait to see what’s in store now. 
4 Likes
@Maximum_ADHD the difference is that in the Studio Beta each MeshPart has a flag bit to say if it has skinned mesh. This assists in quickly determining how it will be rendered even before the mesh data is fetched from the server. The MeshPart instance in the DataModel is updated - not the mesh data (verts/faces etc.)
4 Likes
Hey @FilteredDev, just to expand on @RobieTheCat’s answer:
Motor6Ds define a relationship between two parts. Bones don’t. To have thousands of animated joints with Motor6Ds you need thousands of parts. For bones that don’t have any meaningful affect on physics, like face bones, that’s excessive.
However, with Bones you can have thousands of animated bones on a single part.
The C0 and C1 properties of a Motor6D are for defining the reference position and orientation of the joint pivot relative to each part. Part0 and C0 are considered the “parent” part for animation, but since we also have a child part we also need to define the same pivot on the child part too. You could also think of these as defining the offset of the part’s center relative to the joint itself.
For Bone, the Parent and CFrame properties inherited from Attachment fill the same role as Part0 and C0. Unlike normal Attachments (currently), Bones can also be parented to other Bones, and will transform relative to their parent Bone. For these we don’t need a C1, the child Bone’s CFrame does the job. The “bind pose” data in the mesh itself handles the offset of the vertices of the “parts” inside the mesh relative to the bones.
Inheriting from Motor6D just doesn’t make sense. Attachment was 90% of we needed, something that defines an offset relative to a parent. We just needed to add support for deeper parent relative nesting and Transform for animation.
The math for the Transform property works the same way as it does for Motor6D. A single mesh with the same hierarchy of correctly oriented Bones as an R15 can play standard R15 animations as is. If you have procedural animation code for Motor6Ds that just works with Transform, it might even work on Bones as is.
Also tentative future plans…
Another reason we decided to use Attachment, is we wanted to have the option to attach things to Bones that don’t have a part of their own.
Although it doesn’t right now, we want to make physics use the animated, transformed position of Bones for simulation in the near future.
Like if we added a RigidConstraint weld-like joint that used Attachments, we’d want you to be able to weld a shield to the animated hand bone even with a custom single part, single mesh “S15” character.
10 Likes
Every day we stray further from this game’s blocky origins.
5 Likes
A good quality of life update to be honest.
2 Likes
This update is one that I and a ton of folks have been undoubtedly waiting for - I’m absolutely stoked for what folks will make with this!
I have no idea why nostalgia pandering seems to be the common theme whenever good updates pop up - it’s either “this wasn’t wanted” or “where is the blocky style” being touted. For goodness’ sake, Roblox has made far more possible today than before and a ton of us want to get more expressive with what we do - nostalgia can’t be used for the sake of preventing any sort of progress on the platform. We’ve come a long way with the API updates and now this, far more power lay in the hands of the developer than ever before - it is incredibly saddening that all this good stuff will always have someone muddling it with cries of old Roblox.
8 Likes
I personally haven’t seen anyone ask for this, but I could be wrong. In general I’m referring to everything Roblox has recently put out that we haven’t asked for
Anyone that liked that comment, along with the people that didn’t ask for it.
I don’t really see how my comment is indicative of not being experienced in professional game development.
2 Likes
Here is a test file that I know will export a working, importable character, a version of Roblox avatar that has skinning–very crude skinning. There is joint blending only on the left elbow, right knee, and right ankle (robot limbs are “rigidly skinned”,meaning the parts vertices are weighted to a single bone), and because I didn’t add extra geometry to make it able to bend smoothly, it looks terrible. This model has my character’s hair and glasses merged into the head mesh. This is to keep this example simple, as importing accessories is normally a separate process.
Also, I used the already-humanoid-composited version of the mesh parts, so they are all referencing the same composite texture for simplicity. This means that if you import this character, the resulting images will be doubly-composited and very low resolution, like on the right test model in the original post. You wouldn’t make an actual avatar with an already composited texture like this, normally your source would have a full 1024x1024 image for the Head, each arm (or one for both arms if they’re symmetrical), the two Torso parts combined, and each leg (again, they can share if symmetrical). So normally 4 to 6 textures, depending on character symmetry.
This Zip file contains the composite texture map, Blender 2.8 source file, and my exported FBX. It should import correctly, using the R15 preset in the Avatar Import, giving you a character that can be renamed “StarterCharacter”, put into StarterPlayer and it should just work, albeit with very low-res texturing for the reasons noted above.
File: BendyAllYourBlox.zip (896.4 KB)
Export settings you need when exporting from the blender file to FBX are:
16 Likes