Add relative position reporting to UI picking

[bytemunch]

Objective

Add position reporting to HitData sent from the UI picking backend.

Solution

Add the computed normalized relative cursor position to hit_data alongside the Entity.

The position reported in HitData is normalized relative to the node, with (0.,0.,0.) at the top left and (1., 1., 0.) in the bottom right. Coordinates are relative to the entire node, not just the visible region.

HitData needs a Vec3 so I just extended with 0.0. I considered inserting the depth here but thought it would be redundant.

I also considered putting the screen space position in the normal field of HitData, but that would require renaming of the field or a separate data structure.

Testing

Tested with mouse on X11 with entities that have Node components.

---

Showcase

// Get click position relative to node
fn hit_position(trigger: Trigger<Pointer<Click>>) {
    let hit_pos = trigger.event.hit.position.expect("no position");
    info!("{}", hit_pos);
}

[github-actions]

Welcome, new contributor!

Please make sure you've read our contributing guide and we look forward to reviewing your pull request shortly ✨

[ickshonpe]

Works fine, added

                .observe(|trigger: Trigger<Pointer<Click>>| {
                    let hit_pos = trigger.event.hit.position.expect("no position");
                    info!("{}", hit_pos);
                });

to the interactable node in the relative_cursor_position example and the position reported by info! matches the position reported by the example's position text.

I think not repurposing the normal field is a good decision as it's potentially confusing.

[alice-i-cecile]

@bytemunch I think I didn't resolve the merge conflicts quite correctly. Can you take a quick look and ping me once CI is passing again?

[bytemunch]

No worries, I think it was a change in how UI nodes now have target cameras, doing tests now letting github do tests, I need to learn more about local CI runs >.<

[bytemunch]

@alice-i-cecile CI ping :)

[alice-i-cecile]

cargo run -p ci in the future :)

[notmd]

This seems really confusing with docs The position of the intersection in the world, if the data is available from the backend.. In the web, this is the mouse location https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent/x

[bytemunch]

Good point, I overlooked that! Perhaps docs could say something along the lines of The position reported by the backend, if the data is available., as giving mouse coords a la web would still be in screen space rather than world space. Maybe a mention of different spaces in docs would be useful too?

I guess I was thinking solely of my own use-case for having position data in relative local space, and knowing that the pointer position is accessible elsewhere in an observer trigger opted for this space.

[alice-i-cecile]

Good point, I overlooked that! Perhaps docs could say something along the lines of The position reported by the backend, if the data is available., as giving mouse coords a la web would still be in screen space rather than world space. Maybe a mention of different spaces in docs would be useful too?

This would be ideal :)