It’s automatically turned on? Hopefully theres a way to opt out of it.
1 Like
You can, and everybody wants it to be opt-in. I think it looks awfu;.
1 Like
Maybe because R6 is too simple and can’t be implemented, or maybe it’s a way to keep forcing R15/Rthro
2 Likes
Im glad this is togged on by default as someone who both creates and plays roblox experinces. I already get very annoyed/sad when i lose access to my layered clothing when a experience is r6 and im sure it’ll be the same when i can’t use my dynamic head in a experience.
3 Likes
Almost every avatar update in the past has consistently been opt-out rather than opt-in. Roblox wants to promote avatar content being consistent in experiences by default; if you think about the user experience, a user should expect the avatar that they spent their time and robox building on the website to work in any experience they join. This feature is no different from layered clothing, rthro, custom emotes/animations, UGC hats, etc—it’s just another expansion to the avatar that is designed to work out of the gate in every Roblox experience.
If it doesn’t work in your experience, simply ot out of it.
12 Likes
Yeah, I’m afraid this isn’t “simply”, and not what I’m concerned about.
I don’t necessarily mind if the end goal of an avatar update is that it’s available by default to all experiences. Avatars and customisation are a pivotal part of the Roblox experience and there are more experiences that allow you to bring your own avatars than not so I get why this is the case. What I do not agree with is that there’s no rollout period here where the Default is Disabled.
This update launching as Enabled is a huge problem for me. It doesn’t allow me to gauge appropriately whether or not this update is right for and compatible with the avatars and customisation I do allow or want to allow for my experiences. It is also pointed out that this update has a non-negligible memory cost, so when I’m concerned about memory use especially on phones or large experiences I can’t test the impact first before deciding whether or not to allow it.
Instead of being afforded the luxury of time, I now have to spend a good amount of time going into experiences I develop for that use R15 and disable them which is time consuming and wasteful, and then I can decide which ones to gauge testing for after that. So obviously I’m unhappy that I now have to find time to opt-out of this feature across too many experiences than comfortable.
The problem isn’t that it’s an opt-out feature. The problem is that it is starting as one. Even layered clothing started as a rollout period so weak example. Different avatar features have different technical requirements, other examples aren’t relevant here.
11 Likes
Probably because facial animation only works on MeshPart heads, which is an R15-only thing
2 Likes
I’m still confused how will it be usable when this is supposed to be opt-in first and not finished but i think replacing Heads with Dynamic would require some extra script if this is set to be enabled.
I’m not against this update either
It’s a fair assessment that this shouldn’t be enabled by default yet. Performance concerns are valid and I think it’d make more sense to have a rollout period.
I just really don’t think this update is as breaking as people think it is.
Worst case scenario: Players can dynamically rotate their neck transform with the view of their head in the web camera. Minimum priority animations that target the FaceControls and Neck of the LocalPlayer’s Humanoid might apply transforms WHEN there is a FaceControls instance in the player’s head.
If there are cases where you think this might break something, you should definitely voice them here.
11 Likes
I can understand not wanting your game to use this feature, but the default setting of enabled is not a big deal when all you do is “disable” it, save your game and publish the update. The social issue of is it fair or not aside, is this really putting a big burden on your game development to turn off one setting and save? It seems like a whole lot of complaining for no reason other than convenience to me. I welcome new features, especially when I can turn them on and off to test and gauge if it is useful or not. It’s about as useful to complain about this as to complain about the feature that let’s you resize unions non-uniformly. 
8 Likes
The only real way I think this may be a breaking change for me is the involvement of Animators. I don’t know if the animations loaded by facial animations are tied to the Humanoid’s Animator or not but I have animation-intensive experiences, one of which allows a player to have effectively three different characters assigned on one Humanoid for character switching. I try and stay conscious of how many animations I’m loading onto one Animator given there’s a maximum.
For all other intents and purposes, the wording “non-negligible memory cost” scares me as a developer who works on an experience with mobile compatibility in mind and the update in general presents an inconvenience, albeit mild, for going in and making sure this feature is disabled given that I override avatar appearances with R15 as the base character rig. I’m also now hearing about head turning being part of dynamic heads which I already have implementations for in code but those are according to the camera’s direction.
Overall I just would’ve liked some time first to know what’s coming and prepare for it. That’s my number one pet peeve. I don’t mind the rest - I hope people who want dynamic heads enjoy them.
I would be inclined to agree if only my main project didn’t consist of 40+ places without an easy way to go and update all of them quickly unless this is a Game Settings option that all of my places can adopt (I’m required to do this as my experience is worth several GB total and cannot be uploaded into less places). Opening 40+ places just to change one feature and make sure it doesn’t appear on live servers is not really fun. If I knew in advance, I could publish the setting change with a general content update or large patch.
Non-uniform union resizing is seriously incomparable to an avatar update.
7 Likes
Does this mean that facial animations will cause lag in some experiences on low-end devices?
If so, will there be a custom feature for users to enable and disable facial animations on all experiences 
?
4 Likes
Now this is constructive feedback I agree with. 
Just like the spatial voice and chat channels, having the ability to turn this off on your own device either for performance reasons or you just would rather not see it, I think would be useful for the end users.
3 Likes
Quick clarification for those that are worried about suddenly being hit by performance issues:
This rollout will not turn on dynamic heads for all players in your experience all at once, it only controls whether dynamic heads are allowed into the experience – if a player hasn’t explicitly equipped a dynamic head they’ll still have a classic one.
That means that the rollout of dynamic heads will inherently be a gradual one that ramps up over time as players naturally decide to equip a dynamic head, so you should have time to notice any problematic trends emerging before they cause significant issues and disable the setting / let us know.
26 Likes
Hope this stays opt-out able, since i prefer having option to disable/enable it for my own games
2 Likes
We’re screaming into an abyss because being “meta-versy” and pleasing your investors is way more important than having common sense when doing these sorts of changes, but why would you make a critical change into an opt-out instead of opt-in on first release, with no prior announcement?
4 Likes
Eh no it doesn’t stop to change the head in studio. but ROBLOX just doesn’t allow it, I think ROBLOX really want us to use r15. and am not the only one saying this New StarterPlayer Property - EnableDynamicHeads - #14 by inHeadspace
1 Like
Just make it disabled by default.
There are a lot of games that rely on changing the face decal.
1 Like
Some heads not having face decals has already been a thing for well over a year now.
If your place uses R15 avatars and has Workspace.MeshPartHeadsAndAccessories enabled (it’s enabled by default) then not all heads will have a decal, for example some Rthro heads that don’t support 2D faces.
5 Likes
Same with the teamcreate property, I find it frustrating that its always enabled when creating new places and I always have to make sure I turn it off before publishing.
EDIT: additionally having a widget that lets us toggle default studio settings would be a cool idea instead of having forced roblox defaults.
1 Like