Fix image planes not working correctly in some named-transform frame scenarios#12276
Fix image planes not working correctly in some named-transform frame scenarios#12276
Conversation
|
Web viewer built successfully.
View image diff on kitdiff. Note: This comment is updated whenever you push a commit. |
MichaelGrupp
left a comment
There was a problem hiding this comment.
LGTM. Some snapshot tests are still failing tho.
|
that difference is curious. https://rerun-io.github.io/kitdiff/?url=https://github.com/rerun-io/rerun/pull/12276 |
|
Looks a like an origin axis marker that's now appearing? |
|
that's the one I changed, but the failure looks like a change in eye position which is a bit odd |
|
eh okay whatever, looks really like only a bounding box changed for some reason 🤷 |
There was a problem hiding this comment.
Wahh my tab did not have the convo above 🙈.
It's hard to notice, but there's a new transform frame in there in the center of the plane. Did we regress with my PR landing?
| ) | ||
| .collect::<Vec<_>>(); | ||
|
|
||
| // TODO(andreas, grtlr): We should not re-query all those transforms. We still have them around in `tree_transforms_per_frame` (and a bit below in later `self.transform_infos`). |
| c.read_lock_transform_cache(ctx.recording()) | ||
| }); | ||
|
|
||
| let lookup_image_plane_distance = |transform_frame_id_hash: TransformFrameIdHash| -> f64 { |
There was a problem hiding this comment.
Just realized this although I touched the code yesterday: Kinda cool that this is not a name clash in the compiler. 🤓
Related
What
Previously, when looking for the image plane distance of a pinhole camera we were looking for the entity with that coordinate frame. Not only is it inconsistent to how our pinhole camera visualization work via
child_frame, but also means that if your pinhole doesn't have the right coordinate frame in general we never found the plane distance.Made sure the adjusted test captures this problem now.