3D eye position and other properties in blueprint#11788
Conversation
|
Web viewer built successfully.
View image diff on kitdiff. Note: This comment is updated whenever you push a commit. |
|
Latest documentation preview deployed successfully.
Note: This comment is updated whenever you push a commit. |
|
co-review on build
|
crates/store/re_types/definitions/rerun/blueprint/archetypes/spatial_information.fbs
Outdated
Show resolved
Hide resolved
crates/store/re_types/definitions/rerun/blueprint/archetypes/eye_controls3d.fbs
Show resolved
Hide resolved
crates/store/re_types/definitions/rerun/blueprint/archetypes/eye_controls3d.fbs
Outdated
Show resolved
Hide resolved
| /// Initially, the up-axis of the eye will be the same as the up-axis of the scene (or +Z if | ||
| /// the scene has no up axis defined). | ||
| /// | ||
| /// A zero vector is valid and will result in 3 degrees of freedom. |
There was a problem hiding this comment.
That's only the case for ego perspective though, no?
There was a problem hiding this comment.
Hmm it behaves weirdly in both instances I think, so can maybe just remove that comment?
There was a problem hiding this comment.
sure, don't recall having that feature 🤷
Wumpf
left a comment
There was a problem hiding this comment.
Super exited about this, so much goodness in here. Worth sharing on Discord as well :)
But I think we should iterate a lil bit on the readability of the logic here, leaving it in a better state since surely after this big change we'll miss some corner case and will have to come back to it many times - in particular update_target_eye is very intimidating right now.
I do love though that a lot of the camera code is no longer spread over several modules as much which makes it easier to reason about it!
Also plz grep for #8265 to check whether there's more tech debt associated with this if you haven't checked already.
crates/viewer/re_viewer/tests/snapshots/all_view_selection_uis/Dark/3D.png
Show resolved
Hide resolved
| test_context.with_blueprint_ctx(|ctx, _| { | ||
| ViewProperty::from_archetype::<EyeControls3D>( | ||
| ctx.current_blueprint(), | ||
| ctx.blueprint_query(), | ||
| view_id, | ||
| ) | ||
| .save_blueprint_component( | ||
| &ctx, | ||
| &EyeControls3D::descriptor_position(), | ||
| &Position3D::new(15.0, 5.0, 15.0), | ||
| ); |
There was a problem hiding this comment.
given how often this shows up it makes me wonder whether we should have a utility specificially in re_view_spatial/tests to set the camera :)
we can put that in a follow-up tho / whoever gets annoyed enough by this
Did grep for that and a few others, and didn't find anything. Also for tests that used raw_input |
There was a problem hiding this comment.
ControlEye makes so much more sense and the method cuts makes this thing a lot easier to follow & make it feel more maintainable for the next person, thank you!
One nasty thing I noticed only now unfortunately is that the selection panel needs too much horizontal space now, way more than we give it by default
The reason for that is ofc "show smoothed bounding box". We have to figure out how to make this shorter, not sure yet 🤔
Btw. without that it's almost alright, but something strange is going on with direction vs position. Seems those boxes are too wide. We can let that one slide though if we find a shorter name for the above
Agreed on slack to merge after removing show smoothed bounding box had been removed from the blueprint.
### Related * Fixes regression in #11788 ### What Fixes regression when tracking entity where inputs don't work correctly when tracking an entity. * [x] another round of manual testing on the web viewer build
### Related * Fixes regression in #11788 ### What Fixes regression when tracking entity where inputs don't work correctly when tracking an entity. * [x] another round of manual testing on the web viewer build
Related
What
Stores more eye properties in blueprint, like eye position and eye look target. Making it controllable from python.
New selection UI for the 3d spatial view:

I've also updated tests which before this either directly wrote to the spatial view state, or artificially did inputs to zoom out the view. I did not bother to recreate the viewing angle of these exactly as I didn't think that was important to the tests.