Hello Developers,
In January 2024, we will be making changes to how the Animation Clip Editor saves local animations and how published animations are handled to improve experience loading times.
The Animation Clip Editor currently saves its animation data under the animated rig in the data model. Unfortunately, those saves can add significant weight to an experience’s size and load time, resulting in a weakened player experience, especially on lower end devices. So, we are making three changes to how the Animation Clip Editor manages local animations in order to improve performance and load time, explained below.
How does this affect me?
Unless you specifically use the instances located under the AnimSaves folder of the animated rig (for example, if you access the KeyframeSequence or the CurveAnimation directly in your experience), this won’t affect your existing experiences. However, this update may affect your future workflows, so please keep reading.
What is changing?
Publishing animations: When publishing an animation, there is now a toggle in the Asset Configuration dialog box that allows you to delete the local instances automatically. This option is turned off by default, but if you only use animations using their asset ID and don’t need the KeyframeSequence or CurveAnimation instances, we recommend enabling “Delete Local Instances” to improve your experience’s loading performance.
New animations: Any new animations you create will be saved in a new ServerStorage.RBX_ANIMSAVES.<rig name> folder. The old AnimSaves folder will be replaced with an ObjectValue whose property points to that rig folder.
Migrating existing animations: We’ve added a migration tool to help you with this transition (see the guidelines below on how to use it). When you select a rig from the Animation Clip Editor to work on your animations, a dialog box will show up if you still have animations under the legacy AnimSaves folder. That dialog box will allow you to delete, migrate, or ignore animations.
-
If the animation data is used directly in your scripts, you should choose “Ignore” for now and make the necessary changes to your code so that it uses the new location as soon as possible. The animation will be left where it was — that is, as a direct child of the
AnimSavesObjectValue— and your scripts usinglocal myAnimation = myRig.AnimSaves.myAnimationwill still work. However, the dialog box will show up again the next time you select the rig, so we encourage you to address it as soon as possible. -
If you are still working on that animation, you should choose “Migrate.” This will move it to the new location and create all the necessary instances and folders for you.
-
If the animation has already been published and you don’t need to access its instances in your experience, you should consider choosing “Delete”. You can always import it again later and make additional changes if needed.
This process is instantaneous, and to save time, you can delete or migrate or ignore all animations at once, as seen in the screenshot above.
Finally, if you migrated or deleted an animation by mistake, we recommend you immediately close the place file without saving the changes and load it again.
What if my experience/plugin uses the animation data directly?
In this case, you need to change the code that reads the animation. We highly recommend that you follow the value of the ObjectValue to find the folder, rather than accessing the folder by name coming from ServerStorage, in case multiple rigs have the same name.
More precisely, you should replace code similar to this:
local myAnim = myRig.AnimSaves.myAnimation
✓ WITH this:
local myAnim = myRig.AnimSaves.Value.myAnimation
✗ NOT with this:
local myAnim = ServerStorage.RBX_ANIMSAVES.myRig.myAnimation
Please note that the animation data is now located in ServerStorage, which means that it does not replicate anymore and is therefore not available from the clients. If your clients need access to that data as well, you will have to manually move the KeyframeSequence or CurveAnimation and its descendants to ReplicatedStorage.
Why are we making changes?
Until now, animations have been saved (either automatically or manually) in an AnimSaves folder under the animated rig. This allows you to work on your animations spanning multiple Studio sessions until you eventually publish them.
Once they are published, however, all of those instances — KeyframeSequence, Keyframe, CurveAnimation, FloatCurve, etc. — are no longer needed to play the animations. Unfortunately, all of those unused instances are located in a place that is replicated to all clients when the experience is loaded on your players’ devices, which increases its loading time.
Because of this positive performance impact, we are changing how and where the local animation instance data is stored.
We understand that in some circumstances, you might have used those instances directly from your experience. Or maybe you even worked on a plugin that creates or reads those instances. This is why we are trying to make this process as low impact as possible. If your experience’s design makes this process seem difficult, please let us know below. Thank you.
FAQ
What will happen to my experience if I don’t take any action?
-
Experiences that are already published won’t be affected, and if you don’t update your experience, it will still work as expected. If your scripts use the local animations present in the
AnimSavesfolder in the DataModel, but you don’t run the AnimationClipEditor or decide not to migrate these animations, publishing the experience again won’t have any effect. Your scripts will still find the animations where they expect them to be, in the legacyAnimSavesfolder. If you don’t migrate or delete the animations, you won’t get the benefit of improved loading time, but your experience will still run as expected.
What if I have a lot of local animations in my experience – how long will this take me?
- This process is instantaneous, and to save time, you can delete, migrate or ignore all animations at once by selecting this option in the table header.