It only works in studio now
30char
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.
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)
This is really exciting! I canât wait to see what people will create using this.
Hey! No looking behind the curtain.
The mesh format has not changed from AvatarEvolution.
We gotta do what we gotta do
I was actually more interested to know if something changed here:
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.
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.
@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.)
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.
Every day we stray further from this gameâs blocky origins.
A good quality of life update to be honest.
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.
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.
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:
What am I doing wrong?
I wanted to see if I can add bones âon the flyâ, but I have never done mesh skinning before, so Iâm a bit clueless on what to do & how I can get it to work
wire.rbxm (4.3 KB)
Your meshIds are for version 3.01 meshes, meaning they either didnât get imported using the Avatar Importer, or the importer didnât find any vertices with bone weights.
Also, the Bone instances have to have names that match the bones in the source file that the vertices were weighted to, all the association is done by matching names (strings).
Oh thank you. Yeah, I didnât use Avatar Importer at first, but then did and it still didnât work (probably because I didnât set any bone weight to vertices).
Iâm trying to make a wire with smooth bends.
Ideally, Iâd have just one MeshPart, and then control the bends with bones. But I also want to give players the ability to make as many bends as they wantâwhich creates a few questions:
- Do I have to up the resolution of the geometry for it to bend nicely multiple times?
I currently have it like this:
- Is it possible to add/remove/manage bones in Studio, so I can have as many as is currently needed (2 bends-2 bones, 15 bends-15 bones), without having a predetermined amount of bones? For example, it would be a bit pointless to have 20 bones if the wire is all straight, without actual bends. I also donât want there to be some limit to how many bends there can be, say a player wants to bend the wire 21 times, but there are only 20 bones.
Is it even possible to do it with just one MeshPart?