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!
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.
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.
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.
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.
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.
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.
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.
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.
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;
That’s what I was thinking as well, but ROBLOX probably won’t do that as it would be more stuff that they would have to look after and it could eventually get to the point where they just can’t maintain it anymore.
I agree, I think this is the best solution (Your solution), there is a minority of games still loved by the community, I hope they won’t be broken due to this future update.
Hearing the mention of facial animation confuses me, especially when this seems to be implying that heads from bundles currently on the catalog would somehow be changed to support facial animations.
Is this something we should actually expect to happen? Even the bundles being released as part of this current event have head models like that look like this:
This mesh could never support facial animations without being completely remodeled and retextured. I am very excited to see how Roblox rolls out these new features that leverage mesh deformation, but the task to make legacy catalog items cooperate with these changes seems impossible.
The first (and most obvious) issue is that the MeshPart is bigger than the old handle, leading to the particles being generated outside of the hat, rather than inside. At first glance, this seems like it would be the only issue, but this hat is unique because it actually has a script that retextures it for certain holidays.
As seen in the image above, this change actually causes the retexture function of the script to break (specifically the mapping of the texture seems to be off). I haven’t looked into exactly what’s causing this to happen, but it happens for most of the hat’s themes.
I hope this can be resolved before this fully rolls out!
