Move HalfSpace and some of Frustum (renamed to ViewFrustum) from bevy_camera to bevy_math

[kfc35]

Objective

• Does the latter half of Resolve overlap between bevy_render primitives and bevy_math primitives #13945
• Does the first two thirds of bevy_render::Frustum should live in bevy_math #13878
• Finish some of what Move Frustum, HalfSpace from bevy_render to bevy_math #13882 started

Solution

• Moves bevy_camera::primitives::HalfSpace to bevy_math::primitives::HalfSpace (first commit)
• Moves some of bevy_camera::primitives::Frustum to bevy_math::primitives::ViewFrustum (second commit)
• I basically followed Jondolf’s directions on the two refactorings. aabb, obb, and sphere stuff stays in bevy_camera (for now? If sphere is refactored, it has been stressed to be done as a follow up )

Testing

I ran the lighting, 2d_gizmos, and 3d_gizmos example just to make sure the lights… and camera… (and action!) were still working. Everything seems to be fine there compared to main. If there are any other examples I should run to make sure things look good, let me know.

[atlv24]

why is that even a thing at all?

[kfc35]

I don’t actually know, but I’m not curious/courageous enough to try removing it
Trying to be as minimally invasive for this PR as possible

[atlv24]

dunno #22693

[alice-i-cecile]

Looks like one of your doc links is broken :)

[Jondolf]

I'm generally in favor of something like this! I think starting with a direct port like this is fine, though long-term, I'd like to handle things a bit differently. I didn't look at the code too deeply yet, just some general initial thoughts in this area:

• I would personally prefer if we replaced our existing plane types with a representation like this one (normal and signed distance). The existing ones are kinda useless. Edit: specifically infinite planes, I don't really care what we do with finite planes, I'd make them meshing-only or remove them
  • Planes are more general-purpose, and a half-space is also defined by a plane, just with the additional semantics that it represents one of the two regions created by the plane, not the plane itself. IMO these semantics can generally be derived from surrounding context (ex: you could have a half_space property that is still defined by a Plane3d).
  • Alternatively, we could also keep HalfSpace2d and HalfSpace3d for their special semantics, but as newtypes over Plane2d and Plane3d.
  • Note that I have my own Plane2d and Plane3d types implemented locally. IMO they have a better and more complete API than the half-space type here. I made a gist for them here.
• I would like to have both HalfSpace2d and HalfSpace3d. HalfSpace shouldn't be a 3D-specific type.
• This has been discussed a million times, but we really need to figure out what shapes we include in bevy_math and if/how to categorize them. Unlike most other shapes, these probably won't have meshing or some other features.

[github-actions]

Your PR caused a change in the graphical output of an example or rendering test. This might be intentional, but it could also mean that something broke!
You can review it at https://pixel-eagle.com/project/B04F67C0-C054-4A6F-92EC-F599FEC2FD1D?filter=PR-22684

If it's expected, please add the M-Deliberate-Rendering-Change label.

If this change seems unrelated to your PR, you can consider updating your PR to target the latest main branch, either by rebasing or merging main into it.

[atlv24]

Generally onboard with this direction. I avoid touch bevy_math because people have a lot of conflicting opinions about it which makes PRs stagnate and die, so while I would have chosen different names for things I dont want to feel strongly enough about it that i contribute to the problem.

Im fine with merging as is, provided CI passes. I have some feelings about the NEAR/FAR constants living in bevy_math, and the more render-y specific stuff being here, but eh. I like seeing any movement at all on this. Agree with Jondolf about 2d/3d variants in the future, maybe good to make space for them now by going to HalfSpace3d immediately.

[alice-i-cecile]

I'm happy with this as an incremental improvement, but unsurprisingly Jondolf has good takes on the longterm plans :)