If a user hasn't interacted with the camera, continue to resize to the orbit-eye

[jleibs]

What

Our initial orbit-eye state is sensitive to the timing of what content is on screen when the scene is initialized.

There appears to be maybe be a regression that stems from faster scene initialization, potentially interacting pathologically with the fact that our blueprint doesn't yet store the camera position. In any case, there are easy-to-reproduce situations where our timeline hasn't yet updated from the initial time when the scene is first populated, meaning many scenes just end up with the empty-scene initizalization for the orbit-eye, and then stick there even as content is added to the scene.

This only appears to affect examples that run live via .connect(). Using the viewer with a pre-saved rrd file (either locally or on the web) mitigates the issue -- presumably because this causes our timestamp to be updated sooner.

However, even if we initialize timeline differently relative to view creation, it's very easy to create scenarios where you log a small piece of content followed by a large piece of content which ends up significantly outside the FOV.

The Solution

We now track whether any user interaction has occured, and if it hasn't continue to interpolate to the new target eye, bringing new content into the field of view of the scene.

Examples of worse behavior

It's worth noting the behavior of arkitscenes does seem like a regression relative to the current behavior. I don't love the scene bouncing around that way.

https://demo.rerun.io/pr/2839/examples/arkit_scenes/

Examples of improved behavior

However, the behavior of linetrip example and colmap were arguably totally broken before and this seems like a huge improvement:

python docs/code-examples/line_strip3d_batch.py

Before	After

python examples/python/structure_from_motion/main.py --dataset colmap_fiat

Before	After

Fixes #2829

Checklist

• I have read and agree to Contributor Guide and the Code of Conduct
• I've included a screenshot or gif (if applicable)
• I have tested demo.rerun.io (if applicable)

• PR Build Summary
• Docs preview
• Examples preview

[Wumpf]

It's worth noting the behavior of arkitscenes does seem like a regression relative to the current behavior. I don't love the scene bouncing around that way.

I see the bouncing but I don't find it all that irritating as it is smooth enough.
It's interesting though that the camera is as far out as it is; might be worth tweaking / looking into why it is that big.
We probably should at least for debug purposes visualize both the bounding box and the accumulated bounding box
EDIT: Turns out the "show bounding box" tickbox we already have shows the accumulated bounding box

[Wumpf]

played around with it and I really like the behavior but I'd be advocating for having the default_eye generally be further zoomed in while we're on it

[Wumpf]

Let's talk about this briefly in the daily

[Wumpf]

It seems we still have a bug in the bounding box computation somewhere - it ends up being to big occasionally, causing the too-away camera I'm complaining about
EDIT: Likely false alarm - structure-from-motion demo has a few frames with points that are quite far away

[Wumpf]

the biggest risk is that if the user has a single point really far way, the camera will be bonkers. But this is a pre-existing problem as you'd also get that problematic camera when you reset camera (via double click)

[Wumpf]

Experimented with closer cameras and it doesn't work for the general case, what we have is about as good as it can be unless we start reasoning about "visual weight" of a scene