Where was this when I needed it the most? Also love that TF2 nope.avi reference lol.
Great update! Excited to use it in a new character creator system!
Any idea when it might go live?
I think if there’s a feature for the Scale tool like a list of objects which’s hound be scaled, with some already on others off (parts = on/proximityPrompts = off)
Are we gonna be able to use the Scale tool while making animations? Such as Move, Rotate, Scale.
Looking forward to it! Any updates on the release date?
2 Likes
Sweet feature! We tried using it to animate layered clothing rigs but ran into an issue.
Trying to animate the ScaleTo property causes some serious delays and visual artifacts. It appears like Layered Clothing is completely recalculating every time ScaleTo is run. Would it be possible to just reuse the cached value for layered clothes data but scale it uniformly?
3 Likes
This is great! When is this planned to go live? I’d love to start using this in my experiences.
10 Likes
Would be really nice if there is a scale function for terrain as well
There are engineers working on making it much easier to do bulk operations on terrain like that right now, be on the lookout for that stuff when it comes out.
3 Likes
Hello!
I have stumpled upon an issue in the production of our animations within Prior Extinction.
(It should be noted that I don’t even have this Beta enabled, but it’s still effecting me.)
Whenever we export our models from Blender, we usually do 1.0 scale, as it’s easier to scale the model to the desired size we want from there.
In this case, we have scaled down Spinosaurus to be ~20x smaller than import size at 0.051 scale, which also is the scale of the animation that is imported. These two Spinosaurus’ models are the exact same physical size, but handle the very same animation very differently.
I believe the issue stems from the different set ups between the models.
The one where the Foot IK hardly moves :
The one where the Foot IK works perfectly :
From what I have read, each “Model” has its own scale. Perhaps, using these different set ups, is what is causing the problem.
The first model (The one that doesn’t work) hasn’t received any edits to work ingame, so it uses the same “Model” group it was given from it was imported.
The second one, doesn’t use the original “Model” group, as the mesh has been placed inside an already-existing “Model” group, that is made to work with all our scripts and features.
This issue only started occuring a few weeks ago, so I am 300% sure it is related to this scale feature.
(Last time we imported animations, was ~4 weeks ago (27th of March), when it worked just fine.)
The only solution I currently see, is that we instead start setting up all our animations, on the model which has already been set up with our scripts and features, instead of the freshly imported one.
Thank you,
- Jaco
1 Like
That likely isn’t related to the scale feature but rather the numerous issues with animations and Motor6D that they keep experimenting on.
It seems that the AnimationSpeed of animations are changed based on the HipHeight property under the Humanoid. How does that system and the new animation scaling for the scale property work together?
I don’t have a use case to change the HipHeight of my custom characters, nor do I feel as though the scaling system interrupts my workflow as of right now. I am curious. I view the scaling of AnimationSpeed via the HipHeight to generally be a good thing, changing how it works would probably break a ton of games on Roblox. Anyhow, interested to hear what you have to say.
Would love to be using this but it’s still disabled.
Any ETA for when this will ship?
6 Likes
Sorry for the long delay! I kept ending up getting occupied with other work which pulled me away from getting this to production (but not for long enough for it to be worth handing off the remaining work to someone else).
The last bits which we needed to get in for this to go live are completed and on their way to production now. We’ll have to wait for a mobile force update to flip the final switch. Expect this go live by June 7th (or possibly May 31st if things line up right).
Well spotted.
-
TL;DR: yes there is some code to make the scale applied by this interact correctly with that existing HipHeight based hack.
-
Long story:
- The existing HipHeight based hack only applies to the offset of the HumanoidRootPart joint. So for Instance, how far above the ground you float with the floating animation.
- The default animations are designed to only use an offset on the HumanoidRootPart joint for this reason, because that’s the only joint the old HipHeight based hack works on. They use pure rotations on all the other joints.
- The new animation scaling included in this feature solves the problem once and for all applying the scale to the entire animation, not just the HumanoidRootPart joint offset.
- In the case of the HumanoidRootPart joint offset, the model scale is ignored if the HipHeight based hack was applied. This works because the HipHeight itself naturally gets scaled by ScaleTo, so the scale factor is already factored in.
7 Likes
Awesome! This is a huge feature that will make any kind of experience that deals with scaling models much easier, thanks for your diligent work on it!
1 Like
Any roadmap or estimate on when animations can be scaled with script live?
1 Like
When ScaleTo releases on production. Everything is in place for a full release when the next mobile force update happens, so not that far away.
4 Likes
just switched my games’ scaling to use the new scaleto, only to find out its not accessible yet 
1 Like
Your question has already been replied to previously:
2 Likes
oh my bad, thank you very much!
1 Like