Camera path animation?

[clochardM33]

Is there any way to animate a camera position (implicitly as though it were a model animation)?
This would be to have a canned fly-by or similar.

Moving camera locations on a timer event (not that I've tried it) is a bit clunky for me.

Thanks,

[elalish]

glTF does suppport animated cameras, but we currently don't read them. Part of the reason is it's a bit unclear how to handle the situation where the glTF camera's aspect ratio doesn't match your element's. I would be open to a PR to add this functionality if you're interested.

[clochardM33]

That all makes perfect sense.
I would offer that the default orbit camera is a different thing to an animation and as such it is reasonable that they don't interact, which is your former point.
Some screenshots attached. I will work on sharing a more interactive look, but it's in public/private (corp) no mans land.
They show (in a very abstract way) a framework for training material; you've bought a thing, some annotation has brief techy notes, the MV is used as a prop when talking through how it works.
The initial request would end up as running a camera path animation either from a click event or as one of the list animations to give a "worm's eye view" of the equipment. The kit has a concept of flow through it and being "part of the flow" is a value-add that you can't get either for real or in slides.
Which creates another FR: could you expose what is an what isn't a camera animation so they could be triggered differently?

[elalish]

Well, you can probably select the camera animation by name easily enough. Do you mean you want two different animations to run simultaneously?

[clochardM33]

I hadn't thought any of this through, but yes it would mean 1 camera and 1 geometry animation can run simultaneously. A bit like an animation with a camera orbit. Thanks.

[clochardM33]

Hi,
I've linked you to a private repository which has a more interactive version. Notes in the Readme

[elalish]

I'm not sure glTF makes an distinction between types of animation. You might be better off just exporting a single animation with both the geometry and camera animated in sync. Less chance for error that way too.

[clochardM33]

It's been a while, but going back to this one...
Forget importing camera paths for the time being.
I can get almost the right outcome by keyframing cameraTarget (and associated), but what would be a sensible approach for handling the interpolationDecay value?

The non-sensible approach is to guess and set it bigger than the keyframe interval.

If I want a linear transition between "keyframes" and I know the keyframe timing what would is the relationship of these to interpolationDecay (assuming that there is one)?
By linear I mean no ease in or ease out of the motion or no ease out at least.
So from point A it moves to point B and gets up to speed pretty much straight away, through to B at that speed and then when going from B to C it appears to move at a constant rate with no slow down/speed up.
This is ignoring things like distances between points could be different which would affect the actual speed.
Thanks.

Actually I might be asking the wrong thing.
Maybe the question is can you just define the transition time between current camera position and a new camera position and set it so there is only linear movement?

[elalish]

No, you can think of the decay like a spring & damper. If you really want it exactly linear, you should just calculate for every frame (do your own interpolation) and use jumpToCameraGoal() inside your RAF callback. If you want keyframes, then just select the next one significantly before you get to the current one, so the camera never gets too close to its goal. That will keep the acceleration fairly steady.

[clochardM33]

Got it. That is plenty to go with. Thanks.