Camera follows center of gravity?

[j6k4m8]

As little "creatures" emerge in Particle-Life, it would be fun to have a way for the camera to track them. One easy way — since they are of course not discrete objects at all — would be to track to the center of mass of a few particles nearby, since those will tend to stick together.

The way I'd implement this is something like,

• let the user "drop" a camera into the scene, which tags its nearest N neighbors for tracking
• track those N neighbors and recompute the center of mass and move the camera accordingly
• periodically resample the nearest particles to the camera to avoid drift

Does that sound interesting to you as a feature? I could give it a whack if so!

[DicSo92]

This is a really good idea, and it's actually been requested multiple times already. Because of that, it's most likely going to be the next feature !

What you're describing is also very close to what I had in mind. The main thing we'll need to watch out for is performance, especially CPU-GPU transfers if we need particle data every frame. That can get expensive fast, so it'll need to be designed carefully.

Feel free to give it a shot if you'd like ! I'd be happy to review or iterate on it together.

On my end, I'll probably start by building a camera that just moves and zooms on its own, randomly but smoothly, to give the simulation a more cinematic feel. That should help test the camera architecture and optimizations before adding full creature tracking.

Thanks again for the idea !

[tom-mohr]

Hey, I also love the idea of a tracking camera! In fact, I did implement this at some point (although not in the version that's currently on my github). I did learn some things when I did that, maybe they are of some help.

cinematic camera

So for a cinematic / pleasing camera experience, the camera's state must keep track of both the current "displayed" position, and the "target" position. The displayed position lags behind the target position. The same goes for camera zoom. User actions (arrow keys, mouse events, ...) update the target state.

Also, cursor actions (such as zooming in on a certain point) must be calculated as if the camera was already in it's target position/zoom. Otherwise controls will feel weird when users take many fast actions after another.

Btw, I found the program logic to be easiest when storing the camera state in world coordinates, not in screen coordinates. Probably you already do that.

tracking particles

The camera obviously must keep a list of the particles it currently tracks (a list of indices).
The camera target position should be set to their average, every frame.

This list must be updated regularly, as @j6k4m8 says. This is done with the same procedure that is used to choose the initial set of tracked particles.
There are many possibilities of doing this:.

1. k-nearest.
2. All partciles inside a given radius.
3. One could even do some graph theory: pick the closest point, then select the connected component that it is contained in. Or the 2-connected component... Etc. Connections should be established with some maximal distance, e.g. r_min * 0.8. This would ensure that only tightly packed components are chosen, where the particles are squeezed even closer than r_min.

There are several situations that should discard the current particle selection and cancel the tracking:

1. When the user does something in the GUI that would obviously make it confusing if tracking would continue. Such as randomizing the particle positions.
2. When the user presses ESCAPE or something.
3. When some metric about the particle selection tells us that it has become weird over time. For example, if you use "k-nearest", it should cancel tracking if their average distance to the camera position is very large. If you use "all inside some radius", it should cancel tracking if there are only very few particles in a certain radius. (These thresholds should be adapted to the particle density, i.e. to r_max and the number of particles in the simulation area.)

Also, it's important to somehow "show" to the user that the camera is currently tracking. For example, you could display a blurry vignette over the screen, or something like that.

Also, you must handle the camera behavior differently when periodic boundaries are active. When the tracked center moves across boundaries, the camera suddenly jumps very far! A nice solution would be: Instead of moving the camera, move the particles and make them appear in center. But that's some effort...

[DicSo92]

Hey @tom-mohr, thanks a lot for all the details !

I've implemented a first version of a cinematic camera already, and it's now live so people can test it. I already had some smoothing/interpolation logic in place, so it came together pretty quickly.

For the tracking camera, I'm taking notes of everything you shared, it all sounds really useful. I'll dig into it next and keep you posted on the progress and any problems I run into.

If you get a chance to try the cinematic camera, I'm curious if the movement/controls feel good overall.
Thanks again !

[j6k4m8]

Super cool, I'm liking it so far!! The only jarring thing is that zooming/panning "fights" with the camera's auto-pan a little too aggressively — it makes it feel like I'm asking it to do something it doesn't want to do. Easy fix would be to let the camera dwell where i put it and restart autopan from my current viewport after a user navigation..?

[DicSo92]

Hey, thanks ! Glad you're liking it so far !

Yeah, I noticed that "fighting" feeling too. I actually tried a bunch of approaches to handle manual input during auto-pan, including restarting the auto-pan from the camera's current position, as you suggested.

At first I also thought it was the best solution, but after a lot of testing the result felt worse overall: every time you do small pans/zooms and release, the path gets altered in a kind of random way. After a few quick adjustments the trajectory becomes unpredictable, and it gets harder to manually follow a creature while auto-pan is running.

I think a better compromise might be: when you release manual pan, the new trajectory resumes in the same direction as your last movement. I haven’t tested that one yet.

But thanks for pointing that out, I'm going to add an option right away so you can try both behaviors.

[j6k4m8]

This is AWESOME!