Picking: Declare working space in HitData position

[bytemunch]

What problem does this solve or what need does it fill?

Currently the returned position field in HitData is space-ambiguous, leading users down a docs rabbit hole as they need to discern what backend is being used, then access that backend's docs to learn what space the position data is in.

What solution would you like?

Something similar to Projection's variant solution, like

pub enum PositionSpace {
    World(Vec3),
    Local(Vec3),
    Screen(Vec2),
    Ui(Vec3),
    // ...etc.
}

This could extend to a better all-round solution, perhaps allowing normal data to be only included where necessary, e.g.

pub enum PickPosition {
    World {
        position: PositionSpace,
        normal: PositionSpace,
    },
    Screen(Vec2),
    Ui(Vec3),
    // ...etc.
}

(of course this is a rough outline, above code snippets are nonsense together but I hope you get the idea :) )

What alternative(s) have you considered?

• Leave things as-is, expect user diligence
• Enforce specific spaces per dimension, all 3d in world space, all 2d in screen space

Additional context

Inspired by @notmd's musings on the subject here

Related: #17681

[notmd]

This will make the HitData size larger and significantly degrade DX because you have to match each variant, you already have to handle the Option. I think adding docs which space is used to each backend is enough.

[bytemunch]

Oh I thought enums had compiler magic making them size free, research shows they're max variant size + 8 bytes, making this a bad solution for something done multiple times a frame. The matching issue is a pain too, I guess a user would need to know in advance what they're destructuring to, meaning the doc trail still needs to be followed.

[alice-i-cecile]

I'd prefer docs here :) If we really want to enforce this we could do an associated constant for each backend or something but let's start with a light touch.