Simpler tween API

It seems like tweening is overly difficult in the Babylon engine. I created a simple playground showing using an external tweening API to accomplish a simple (highly customizable) animation on the camera. Babylon.js Playground

Babylon exposes a similar API which is comparatively verbose and murky/unclear.

I would rather not pull in another dependency for simple tween animations on cameras, (otherwise-) static objects, etc. but I also don’t want to handle the verbose API. It’s simpler from my perspective to instantiate the mesh/whatever in Babylon and use an external library like the one in the Playground above to animate the tween. So I’m hoping Babylon can provide a similar to, from, fromTo API that operates directly on the position, rotation, direction, etc. properties of the various node types.

Terminology explainer: Inbetweening - Wikipedia

Hi @jkeys

Your PG isn’t working for me.

I’m all for simplifying where possible but I can’t yet see how your example is all that much simpler to be honest i.e.

Animation.CreateAndStartAnimation(name, node, property, fps, frames, from, to, loopMode?, easing?, callback?)


GSAP.fromTo(targets, fromVars, toVars) - where toVars object includes above fps + frames (i.e. duration), loopMode, easing, callback plus other args.

I’ve used GSAP and am admittedly still new to Babylon.js animation but the only limitation I’ve run into to date is that Animation.CreateAndStartAnimation only works on nodes. I recently had a requirement to animate Babylon GUI container alpha and colors, so in those cases I had to roll my own animation functions.

1 Like

@inteja hit play, it also doesn’t work for me when fresh loading the PG url. But the script dependency loads and executes well after hitting play!

I guess: the gsap module incldues defaults for FPS, frames, loop mode, and easing. It is ambiguous to me whatever the frames property points to, as well as from and to whereas the GSAP documentation is crystal-clear. any is not well typed and I can’t work with that. And it also is explicitly not creating a Babylon object that needs to be managed and destroyed. It’s animating the properties of a Babylon object without any input on the lifecycle or other properties. That’s what I mean by being a simpler API.

Let me call scene.getNodeByName('myNodeName').fromTo({x: 0}, {x: 1}) and I would be happy.

@jkeys Thanks for the concrete example of what a simplified API might look like, although it’s unclear if node position, rotation, scale or some other Vector3 property is being affected.

In fairness there are defaults for loopMode & easing - they are optional parameters, but I agree in relation to fps + frames vs duration. Maybe someone else can comment on that.

1 Like

My understanding is that Animation.CreateAndStartAnimation is a shortcut/wrapper/convenience function. If you need an object or more control you still have the option of doing so.

1 Like

Good point. And that actually brings up an interesting point – should tweening methods be properties of Vector3?! Almost certainly not but it does lead to a nice API:

scene.getNodeByName('myNodeName').position.fromTo({x: 0}, {x: 1})

But it also brings up a whole set of questions that probably shouldn’t be answered :wink: So, more likely with tweening just being a property of TransformNode/Mesh/Light/etc:

scene.getNodeByName('myNodeName').fromTo('position', {x: 0}, {x: 1})

I agree in relation to fps + frames vs duration

Definitely makes a difference for a non-animator :smiley:

Actually that’s great, I’d prefer a convenience method. But the API exposed by CreateAndStartAnimation doesn’t feel very convenient :smiley:

I agree, something like:

myNode.position.animate(from, to, duration, delay?, easing?, loopMode?)

Would be dead simple, but maybe there’s performance considerations. If every type/property had animate methods it could seriously bloat things … maybe.

Hopefully someone more knowledgeable about the architecture will be able to chime in.

1 Like

I think the reality is that many (if not most) animations aren’t simple 2 keyframe (from/to) animations. Most of the time we need many more keyframes, static path or dynamic math based animation, so adding simple from/to animation methods to each property may be too much overhead for little return, but I’m just guessing here.

1 Like

I would be fine with it being a static method also, it doesn’t need to be a property. The special case of 2-keyframe would seem significant enough to warrant its own API though.

1 Like

@jkeys as far as I understand it (and I may be wrong -often am) that any use of animation creates an animatable under the hood. You could therefore create an animate method on the Node (TransformNode?) class that builds an animatable. Perhaps you would like to have a go and eventually submit a PR if it proves useful.