Action Required: MeshPart Heads & Accessories (May 27th)

Previous post:

Hi developers,

We’re excited to release several new technologies and features for avatars in the near future. In order to do this, the entire avatar needs to use MeshPart instances. This will change heads and accessories from using SpecialMesh instances to using MeshPart instances.

Opting Into MeshPart Heads & Accessories

Since this may break scripts that depend on the existing structure of heads, we have introduced a new property Workspace.MeshPartHeadsAndAccessories, as a way to opt-in to this new format.

image

This property gives you three settings:

  • Disabled - Keep the current behavior
  • Enabled - Characters will load using MeshPart Heads & Accessories
  • Default - Currently, means the same as “Disabled”, but will switch to mean “Enabled” as we continue to roll this feature out.

Default will switch to Enabled on May 27th, 2021

You should change this setting to “Enabled” as soon as possible and make any necessary script changes. This will prevent unexpected changes in behavior in the future when “Default” is changed.

Head Changes

Heads will now be a MeshPart instance and no longer contain a “Mesh” SpecialMesh instance.

Current Format New Format
image image

In addition, the “face” decal may not exist on heads which do not support faces.

For example, Magma Fiend Head does not support faces. The MeshPart version of this head will load into the game as:

image

Accessory Changes

The “Handle” Part instance of accessories will now be a MeshPart instance and no longer contain a “Mesh” SpecialMesh instance.

Current Format New Format
image image

Things to Look Out For

We expect the vast majority of existing games to work perfectly fine with this feature, however there are a few known incompatible features which some games may encounter:

  • Reading and writing to SpecialMesh.Scale has no direct MeshPart equivalent
    • Use Humanoid.HeadScale.Value instead
  • Reading and writing to SpecialMesh.VertexColor has no MeshPart equivalent
  • Reading and writing to SpecialMesh.MeshId has no MeshPart equivalent

Head collision sizes with MeshPart heads may be larger than before in some cases.

Previously, this was always a 2x1x1 box, now the collisions will match the bounding box of the head mesh. If you receive reports about players not being about to fit through some doors or spaces in your game, it’s possible this is the reason why.

We are investigating possible compatibility options for this to allow developers to choose how head collisions work in games.

MeshPart Heads and Accessories will only load through the HumanoidDescription, Player:LoadCharacter(), or default platform avatar loading systems. If your game uses a custom avatar editor with InsertService:LoadAsset(), the delivered assets will remain as SpecialMesh assets for the time being. We will be investigating a way to support this in the future.

This change only modifies how assets are loaded into the game. Characters with SpecialMesh heads and accessories will continue to work in the future, but may not support some future features.

If your game does have issues, you should switch the Workspace.MeshPartHeadsAndAccessories setting to “Disabled” until these issues can be resolved.

Future Features

It is important that you opt-in as soon as possible to give your players the best experience.

In the near future, MeshPart Heads and Accessories will be required for new features like:

  • Skinned Meshes
  • Layered Clothing
  • Physically based rendering
  • Facial animations
  • And many more avatar features!

You should opt-in with “Enabled” as soon as possible to ensure your game is compatible.

Feedback

If you run into issues with this feature in your game, please let us know why in this thread! We will actively work to make this feature compatible with as many games as possible.

If you find any head or accessory assets that do not look or behave as expected, please also provide those in this thread as well.

256 Likes

This topic was automatically opened after 14 minutes.

This is exciting! The possibilities of PBR on avatar items/accessories are amazing, and I’m excited to see what the future has in store for avatars! However, I do have some things I want to mention.

The fact that there isn’t an alternative for VertexColor is frustrating - I found this extremely useful for recoloring an avatar in-game. I’m also worried about the difference in head collisions - Humanoid.HeadScale.Value isn’t a proper alternative for SpecialMesh.Scale, especially when it’s going to modify collisions.

26 Likes

That Future Features list has me hyped. Awesome work Osyris. Happy I could assist getting this feature ready by trialing it in Break In

12 Likes

I actually do have one issue regarding this. A while back, I reached out to an engineer asking if ‘legacy’ packages would have their head hats converted into actual head parts. The engineer pinged another one, but never got any response : Migrating Heads and Accessories to be MeshParts - #68 by RobieTheCat

Will packages like the Crimson Claw Package have their heads converted into actual heads? Right now, their ‘heads’ are actually just “Hat” accessories. Here’s the crimsons claw’s head (Crimson Claw: The Vengeful Head - Roblox). Notice how the head is actually a hat accessory.

It would be really neat if these packages could have their ‘head’ hats converted into actual head parts, so that they can make use of the upcoming avatar technologies such as facial animation and layered clothing. If these packages’ heads are kept as hats, they wouldn’t be able to make full use of this technology which isn’t ideal. It’s also worth noting that you cannot properly wear hats with these packages, because of the aforementioned issue.

25 Likes

This is exciting! I will definitely be opting in and ensure compatibility in my games.

Curious to see how customizable layered clothing will be for developers and the options we have regarding them as opposed to traditional clothes.

6 Likes

This really gets me excited. I have already been messing around with these in my project on wave deformation using mesh parts. Do we expect to see SkinnedMeshes react to physics? Currently, the bounding box is that of the part’s original shape.

Also I am slightly concerned on how you are going to push this feature out to the public, especially existing accessories that use SpecialMeshes.

3 Likes

Wouldn’t it allow exploiters to change the MeshPart ID through a script?

3 Likes

Is there any plan to apply this to Players:CreateHumanoidModelFromDescription() potentially as a fourth argument? Was super eager to finally fix the issue with my game having small heads with some characters only to be met with disappointment. :Q


No. Wouldn’t replicate.

1 Like

I couldn’t really process what the update was, but if i’m correct, enabling a mesh property will allow things such as animated facial expressions, layered clothing, etc to be used in game.

And not long ago, while creating Dummies for measuring, etc I ran into a issue with Roblox’s built in Dummy creating plugin. At the moment I cannot show or recreate issue, but selecting R6 and pressing things such as man dummy, block dummy, etc will lead me to getting only Block Dummy even when selecting something else.

I cant tell if this is just a coincidence after getting shown this update, but its a possible issue. Thanks!

3 Likes

Will particle and noise hats remain functional with this change?

1 Like

Will look into this, but I don’t have a great answer for you right now. The dragon “head” accessory will be a MeshPart and work with some of the future features, but you’re correct facial animation probably wouldn’t work with a “head” accessory.

The post details how you can “opt-in” your game so that it downloads MeshPart versions of heads and accessories. We’re doing a gradual opt-in to avoid breaking games.

This should not be a concern. If they could change the ID, it wouldn’t replicate up to the server.

This should already work assuming you’ve set Workspace.MeshPartHeadsAndAccessories to Enabled.

They should. Let us know if you run into any issues.

5 Likes

I’m not quite sure how to feel about this update, it will cause a bunch of older games that do things to the head mesh to break and I’m not sure if there’s a workaround to this. Not to mention the head collision changing will cause other things to break such as collision when walking through holes that were originally made with old terrain before the conversion.

I understand that this update plays a part in the future of the platform, but it pains me to imagine that a bunch of games that people put days, weeks, even months into could potentially break. If only we had a separate part of the platform that worked as a time machine, like a ROBLOX Legacy Edition.

6 Likes

Very much appreciated! Would definitely love a response when there’s a more clear direction for this.

Yeah, this is why I’ve been pushing to get them converted into actual heads, so that they can make use of facial anims + properly wear hats / layered clothing accessories.

3 Likes

One question I have is scaling and moving around these meshparts now. Currently, the bounding box for a typical unsealed 1.0 is 4x5x1 studs, but since the head mesh itself isn’t a perfect 1x1x1 stud proportion, will there be anything to change this? Maybe it is just me but working with small decimals is not preferable.

As you can see, the bounding box is slightly altered. It goes over the rest of the body due to the head. While this does not seem to be a big issue, I kinda value precision and I prefer not working with itty bitty decimals. One advantage of special meshes was being able to control something like the bounding box. However, something like pivots maybe be a suitable fix, but nevertheless I’d like some attention towards this.

8 Likes

I agree with you that might cause a lot of problems for these games but this update is not yet on ROBLOX so I think they have time to find a way to put these new things in roblox without breaking old games.

3 Likes

Are you talking about ROBLOX or the developers of these older games. Because a lot of older games are no longer being developed. The best solution (in my eyes) is just to make enable it default for newer games but keep it disabled for older ones.

6 Likes

Awesome stuff yet again, always exciting to see changes that lead to even bigger technological changes. However I do have an issue with this:

I’m guessing over time, SpecialMesh would be discouraged for use (within avatars anyways), but a property that that SpecialMesh have is VertexColor in which you can directly “recolor” the color of a SpecialMesh’s texture, assuming the texture is white, see below:

This is very helpful for my game where you can change your characters hair color to whatever the players desire.

MeshPart has a TextureID property, but nothing else (that I know of) that can change color of the texture directly. Perhaps this update could be accompanied with this feature to color MeshPart textures.

25 Likes

Hi @Osyris.

Currently in my game I would do Accessory.Handle.Size = Vector3.new(0, 0 ,0) to prevent any weird Physics, Collision, Touches and Hitboxes.

Physics, Collision and Touches can be fixed by doing Massless = true, CanCollide = false and CanTouch = false however it’s a hassle for Raycasting which is why I find it easier to set the Part.Size to 0.

With this new change I can no longer do this

3 Likes

Huh, I don’t think it’s working for me. I used the following in the command line:

local f = Instance.new("Folder", workspace); 
f.Name = "Personas 2"; 
for i, v in pairs(game.ReplicatedStorage.Personas:GetChildren()) do
    if v:IsA("Model") then
        local HD = game.Players:CreateHumanoidModelFromDescription(v.Humanoid.HumanoidDescription, 
        Enum.HumanoidRigType.R6); 
        HD.Name = v.Name; 
        HD.Parent = f; 
    end 
end;

and all the loaded models’ head were of parts:

Is it because they’re R6 models or something of the sort?
The property is also enabled:

image

2 Likes