Camera animation

[marcibk]

mapbox-gl-js version: 2.3.1

Question

Hi there :). I am using terrain 3d and have a route animation. I want to achieve sth. like https://www.relive.cc/view/vAOZDD5poqL with the camera. Tried a lot with the free camera path example but I don´t want to follow the route 1:1 and have the "laggy" follow animation. I tried with turf.simplify but it´s still following always over the track. I want to have a follow animation like in this video. Can you give me some hints on how to achieve this? Thank you so much for your help! Kind regards

Links to related documentation

https://docs.mapbox.com/mapbox-gl-js/example/free-camera-path/

[karimnaaji]

Hey @traingethermarc , this tool might not exactly be what you're looking for but have you tried using https://developmentseed.org/gl-director/?

Concerning having an API for simplifying camera animation, we've been considering adding ways to facilitate path following so any early feedback on what you're trying to achieve or how you would use it would be great.

I consider that they are still two difficult things with the current free camera API, what we'd like to facilitate is for a given path:

• (1) Find the camera path, this includes:
  • How far from the initial path the camera should be placed
  • How much smoothing is applied to the camera movement
  • What is the altitude of the camera along the camera path
• (2) How to animate it over time, and possibly chaining camera animations (camera choreography):
  • Duration of the animation
  • Interpolation between frames

A challenge of (1), and possibly in the video that you mentioned above, is finding the sweet spot between a camera path crafted manually (e.g. editing each keyframe location for where the camera should be placed) compared to one generated by code while still having something that looks natural.

An API of that sort could allow as input:

• An initial path to follow
• A camera offset (how far and in which direction against the initial path the camera should be)
• Some hints on how to follow elevation (baseline ensured min elevation for example)
• A smoothing parameter for the camera path (how much smoothing and simplification on the initial path is allowed after offsetting, to prevent high frequency turns if the initial path isn't nicely defined, a bit similar to turf.simplify)

[marcibk]

Hi @karimnaaji - thanks for your reply! This tool is super nice, but the route is always different in my case, so it´s hard to adapt a similar pattern. In my opinion it´s a math/logic problem. There are 2 approaches I guess:

1. Follow the track (smooth) from above, with a high camera looking directly at a location. - but this looks pretty static/bad and is not nice to look at, especially with dynamic routes, this can lead to problems pretty quickly.
2. This is the approach I would like to go for: Calculate a camera path next to the track with turning camera etc. (like in my reference) I tried it with a bbox already, but it´s still hard to have a good looking result (or even WORKING result) for every track, because sometimes the camera is stuck in the mountains or just looks super bad (because the track is not visible). Just trying to find some ideas on how to achieve this.

[rreusser]

I've only so far tested it in 2D, but I implemented a proof of concept for a sort of camera controller. The key feature of this controller is that it's a PI controller (proportional, integral), which makes it not deterministic in the same sense that it may not always yield the exact same final state, depending on the particular timing between frames. By sacrificing this, I think we'd gain a huge amount of flexibility, power, and value. Its inputs are lookAt point, camera pitch, bearing, and distance (in units of km). You provide them as often as you want, and it moves the camera smoothly to attain them (approximately as they animate; exactly once steady state is achieved).

Proportional means it moves the camera and look at point proportional to the distance between the current and target state.

Integral means that it integrates the accumulated state error (distance between target look at point and current look at point), and feeds that into the lookAt point controller. That allows it to track moving points without the excessive lag that tends to plague strictly proportional controllers.

Live example: https://observablehq.com/d/fb32bbf9ea0f2e41

When the camera and lookAt point are panned together, orientation of the camera is maintained: (see end of video for response to abrupt changes)

https://user-images.githubusercontent.com/572717/132393890-b21aeee2-73bd-4812-9fb3-48f4c268bdf5.mp4

When only the lookAt point is moved, the camera tends to follow behind:

https://user-images.githubusercontent.com/572717/132394037-201e034b-9e32-41eb-9dfc-1728db305d0d.mp4

Some particular details regarding the above discussion:

• Calculating camera paths: Really just not a thing in this approach, which I think is the best case scenario. It updates the camera live on every frame, and if the specified parameters change, it simply responds differently, without ever computing or recomputing any path.
• Path smoothing: the lag of the P controller obviates some of the need for path smoothing. Note in videos above that abrupt changes are approximately but not perfectly tracked.
• Choreographing sequences of animations: this approach doesn't know the difference between one path or another, or one animation or another, eliminating the need to link up animations.

• Following a path: In my example, I used turf.js to evaluate a path on every frame and feed that point into it. I think the most flexible approach would be for such a function to know nothing about paths, and instead look at it as a per-frame externally-supplied point to look at, and if that moves, then the camera moves.

  Considering the above relive.cc example, if you wanted to start at zero pitch, then pitch the map and zoom in, then follow the path, that's totally up to you. You'd simply ease the prescribed camera distance and pitch values and feed them into the follow function on each frame. They wouldn't even have to be smooth values in order for the resulting camera path to be smooth.

• Getting stuck behind a mountain: it'd be perfectly possible to sample elevations and use the gradient to gently push the camera bearing toward the side of the hill from which the path would be visible.

Downsides

• non-deterministic: depends on frame timing. Different users may not observe an identical final state, for example if the bearing is left free to drift (follow mode).
• offloads choreography onto user: developers would have to evaluate a path, for example with turf.js, and feed that into the API. I think this could be done in ~3 lines of code, so personally I view this as an advantage.

Possible design

map.follow(): a function you may call as often as you like. Inputs are:

• lookAt
• distance: camera distance, in units of kilometers
• pitch: camera pitch
• bearing: camera bearing If you don't provide camera parameters, it could maintain the current values. We may also want to expose PI controller parameters, for fine control. As soon as called, it would enter animating mode. When it reaches steady state, the animation would terminate. It would also immediately terminate on user input.

[rreusser]

Also, from https://github.com/mapbox/mapbox-gl-js/issues/981#issuecomment-281212219:

In the pursuit of making GL JS the smallest & sharpest tool possible, we're going to punt on this feature and encourage it to be written as a plugin.

I'd fully support this as a standalone plugin (it's the way I've prototyped it). Inclusion as an API method would benefit from some API coherence, but one way or another, I mainly just think it's useful functionality people would benefit from.