Bounding box not taking transformation hierarchy for rr.Pinhole correctly into account

[roym899]

Describe the bug
It seems like the current 3D bounding box is not properly taking a pinhole's transform hierarchy into account.

If the camera is at the origin of its parent frame, the global origin will always be part of the bounding box. However, the transformed origin is also taken into account.

When there's both a parent transform and a child transform the bounding box calculation seems completely incorrect.

To Reproduce

import numpy as np
import rerun as rr

rr.init("bounding_box", spawn=True)
rr.log("parent", rr.Transform3D(translation=[5.0, 5.0, 5.0]))
rr.log("parent/camera", rr.Pinhole(width=640, height=480, focal_length=320))
# rr.log("parent/camera", rr.Transform3D(translation=[1.0,1.0,1.0]))  # this will affect the bounding box, but not in the correct way
# rr.log("parent/points", rr.Points3D(np.random.rand(10, 3)))  # uncomment to avoid collapsing bounding box (not needed with the current behavior)

Screenshots
Camera at global origin, no transforms at all -> collapsing bounding box (I assume this is the correct behavior)

Camera at local origin (bounding box seems to align with frustum origin + world origin)

Camera additionally locally transformed (bounding box changes but completely incorrectly (now the frustum is completely outside)

Expected Behavior
Not entirely sure what the consensus is about frustum being part or not part of the bounding box. But at least the origin should properly be taken into account. I guess in that case, for all the above cases the bounding box should collapse. When also logging the points in the above example, the bounding box should include the pinhole origin and the points.

Desktop:

• OS: Ubuntu 20.04

Rerun version

rerun_py 0.12.0-alpha.1+dev [rustc 1.74.0 (79e9716c9 2023-11-13), LLVM 17.0.4] x86_64-unknown-linux-gnu

[emilk]

Let's test if this is a new or existing bug (if new we should fix it before 0.12)