Visulie 6.1.1
This is a new version! Please update your data and renderer!
Bug Fixes
- Non-animatable instance classes are now flagged.
Features
- You can now animate the “Camera”, Folder, and configuration instances (possible camera animation in the future? Planned, but not guaranteed).
- New “LoadType” for animations. Read more below.
Changes
- Slight changes to the internal signal soft disconnection behavior.
- Loading/creating animations now restricts to one root instance, instead of many. This is a breaking change! Please read below.
VERY IMPORTANT! PLEASE READ!
In the previous Visulie versions, animations could have many “root” instances, meaning you could create/load animations with many top-level instances. For example, your animation layout may have looked like this:
Model
└ Part1
└ ParticleEmitter1
Part1
└ ParticleEmitter2
Part2
└ ParticleEmitter2
Notice how there are multiple different root instances (Model, Part1, Part2). When we want to load this animation, we have to write:
local NewAnimation = Visulie.loadAnimation(data, origin, {Model, Part1, Part2})
… which is long.
The new system restricts you to one root instance. In the case that some of your animations use multiple root instances, the version handler will add a folder to encapsulate everything together. The resulting updated hierarchy would look something like this (using the example from above):
Folder --> the version handler will add this
└ Model
└ Part1
└ ParticleEmitter1
└ Part1
└ ParticleEmitter2
└ Part2
└ ParticleEmitter2
If you use loadAnimation, make sure to alter the code to reflect this change.
Why this change?
Loading animations was previously very verbose.
local NewAnimation = Visulie.loadAnimation(data, origin, {Model, Part1, Part2})
is much more cumbersome to write than:
local NewAnimation = Visulie.loadAnimation(data, origin, Root)
You’d have to get every single dependency, make sure they’re all named correctly, and hope for the best. The more common convention for animators is to provide a single dependent instance, and thus having multiple dependent instances breaks this convention.
There were also many implementation issues that I’ve run into when trying to design for multiple instances, and that “feature” (if you can even call it that) was becoming hard to maintain.
Load Types
This is a new feature added in Visulie V6. Essentially, it reduces the bulk of your animations by optimizing them in different ways. You can edit the load type on the bottom of the selection panel:
There are three possible load types:
Atomic - The same thing as before: it saves everything.
Dynamic - Saves all methods, attributes, tags, but only saves properties that have more than one keyframe.
Pose - Saves only
CFramevalues onBasePartsandModels. Does not save methods, attributes, or tags.
Note that the “Dynamic” and “Pose” load types cannot be used with .new(). When loading the animation back into the editor, you must provide a rig to load into.
Here’s an example use case. Look at this simple animation:
The serialized data has 1192 lines of code! This happens because we are saving literally everything, even the properties that aren’t being animated.
Since we only care about the limbs moving, we can set the loadType to “Pose”, which only saves CFrames from BaseParts and Models. When we serialize the animation now, we end up with only 269 lines (almost a 5x reduction)!
Using a bit of code, the shortened version plays exactly the same in-game!
local walkAnimation = require(script.Parent.Walk)
local Visulie = require(script.Parent.Visulie)
local Model = script.Parent.Beetle
local Walk = require(script.Parent.Visulie).loadAnimation(walkAnimation, CFrame.new(0, 5, 0), Model)
Walk.Loops = true
Walk:Resume()
To load an animation with loadType equal to “Pose” or “Dynamic”, select the animation module, then select the required rig:


