I really want to use the ROBLOX animation system, but it’s getting very difficult to do that. I can make animations for one weapon, but not be able to use them for the other 50 because the grip positions vary. I end up having to make tons of animations when I should only have to make one. I can run a plugin to auto-generate new animations out of the one which means it’s not as bad as making all the animations from scratch, but having to use the publish prompt for each and every one of those animations is just as annoying.
I don’t see why animations are tied to these archaic assets. It made sense when they were paid assets (), but now it’s nothing more than an encumbrance. It forces me to re-make animations when I shouldn’t, and I can’t even share my animations without someone having to re-import the raw instance. LoadAnimation should support instances instead of just assets.
Um, I have no trouble using a single animation for multiple different swords (if I understand what you’re saying) and they do have different tool grip positions but changing the tool grip doesn’t seem to affect the animation. Then again, I’m not changing the grip position or CFrame of the handle during animations and I’m not sure how complicated your setup is.
If you want to see my animations you can check them out here
You don’t have any issues because the hands are never moving to different points on the sword. The left hand is free, and the right is always in the same spot on the sword. Try having the hands grip different parts of the sword:
On each hilt, is a decorative piece (the yellow part). The first one needs to be gripped with the hands close together, but the second has to be gripped with them far apart. Already, I have to create two separate animations and publish them separately, whereas if I could use instances, I could generate animations based on the grip positions and only make a single grip animation.
To get more complicated, imagine you need to make parry and block animations where the hands move to different spots on the weapon. Now you have to make 3n animations (grip, parry, block) with n being the number of swords with unique grip positions.
When it really gets bad though is when you start getting into guns. Guns almost always have different grip positions unless they’re different skins/versions of the same gun. Out of 50 swords, I might only have 5 unique grip positions, but with guns, chances are all 50 of them have unique grip positions. If I want to make a reload animation, I have to make 50. If I want to make a sprint animation, I have to make 50 more. Now we’re at 150 animations (grip, reload, sprint), and that’s atrocious.
I’ve seen this accomplished by using a single animation, by offsetting the limb before playing the animation (since the animation will offset the current limb, meaning you can also add an extra offset yourself).
However for guns, procedural seems to often be easier!
This may work for getting the starting grip positions on the gun right when playing an animation, but when I want to grip mags that are offset different from the starting position in a reload animation for instance, a single animation wouldn’t be able to do the job. I could change the C0/C1 at each stage of the animation to make sure the offsets always match up, but if I’m continually changing C0/C1 I might as well just be using custom animations.
At this point there isn’t a solution but to write a custom animation system. Some problems require a custom solution and this will always be the case. Software isn’t good enough yet to magically interpret what users want to see happen (yet)
We’re not talking some edge case here. This prevents the ROBLOX animation system from being used (feasibly) in any sort of FPS game, one of the big uses of animations, and one of the genres @zeuxcg and some of the other ROBLOX staff members have been encouraging developers to use ROBLOX animations for.
And I’m not wanting this to magically happen either. I made a feature request specifically elaborating on what I wanted (a definitively achievable goal – not magic prediction) and why it should be implemented.
and I see 1 FPS game, which in this scenario is our edge case, and the rest are using ROBLOX animations. The only feasible way to use ROBLOX animations with a shooter is to do custom animations per gun, or modify the limb C0/C1 at runtime which as you stated, you mightaswell implement your own system at that point. I definitely would consider an FPS an edge case for animations, especially at the level that Phantom Forces or Kinetic Code operate.
While FPS is sort of an edge case in ROBLOX, we definitely should figure out what changes are required to make ROBLOX animations work.
I’ve said it before and I’ll say it again - custom animation systems are bad. The amount of overhead in Lua compared to C++ is insane. We’re planning to work on this next year, but it will never be good - Lua just sucks from a performance standpoint, frankly - it will just be less bad. For some games right now it’s a necessary evil - we should figure out how to fix this (for example, some games have animation editors that allow extra property manipulation - we should figure out if this is something we want to support first-class, or alternatively provide a way for a developer to integrate this by e.g. storing some metadata for each pose, or just by naming keyframes & associating extra data with them…)
Now, the specific solution to the problem mentioned in this thread of course is something we should discuss - it’s not clear that playing animation instances is a good idea (the encoding of cframe data into a instance hierarchy is pretty suboptimal. We have it well encapsulated so we can change it in the future - may become more important for R15 etc. - but then the use case mentioned in this thread would still require replicating many Pose instances, which is not great).
I think it would be brilliant to be able to animate any mathematical property (or non mathematical, which instead of tweening would switch to the specified value once the animation reached that keyframe).
The current animation system is on/off. In order to make it dynamic there isn’t any way to do it without scripting, which in our scenario is done via Lua. How could we implement a better system? From what I’ve seen in other game engines, they all use systems that are “custom” (in the sense that they are done at runtime) however they do it in a faster environment such as C++ (in Unreal) or C# (unity).
Do you have an idea on how this can be solved that we could build off of? Or have you seen cases where dynamic animations are done in a way that doesn’t require the animation being modified at runtime?
), but now it’s nothing more than an encumbrance. It forces me to re-make animations when I shouldn’t, and I can’t even share my animations without someone having to re-import the raw instance. LoadAnimation should support instances instead of just assets.
