[Merged by Bors] - simplified API to get NDC from camera and world position

[mockersf]

Objective

• After [Merged by Bors] - Add capability to render to a texture #3412, Camera::world_to_screen got a little bit uglier to use by needing to provide both Windows and Assets<Image>, even though only one would be needed

  bevy/crates/bevy_render/src/camera/camera.rs

  Lines 117 to 123 in b697e73

  	pub fn world_to_screen(
  	&self,
  	windows: &Windows,
  	images: &Assets<Image>,
  	camera_transform: &GlobalTransform,
  	world_position: Vec3,
  	) -> Option<Vec2> {

• Some time, exact coordinates are not needed but normalized device coordinates is enough

Solution

• Add a function to just get NDC

[superdump]

Code-wise fine. Just @alice-i-cecile 's documentation comment to address.

[IceSentry]

I wouldn't mind having a description of the NDC acronym somewhere in a doc comment

nevermind, it's already there

[aevyrie]

@mockersf here are some proposed changes to this PR: mockersf#78

I was experimenting with using a trait to remove the need for passing both Image and Window resources into the world_to_screen() function.

If you have a Window or Image:

camera.world_to_screen(window, global_transform, world_pos)

If you have a RenderTarget or Camera:

let sized_target = camera.target.as_sized_target(windows, images);
camera.world_to_screen(sized_target, global_transform, world_pos)

[alice-i-cecile]

I like aevyrie's changes quite a bit here. Do you agree @mockersf?

[mockersf]

after playing with the changes from @aevyrie, I disagree with them as they make it possible to use invalid parameters by using a different camera for the target as the one used for the projection matrix

[cart]

Relevant to some of the general sentiment expressed here: in my "high level render targets" changes i'm experimenting with syncing render target logical and physical width/height to Camera fields, which makes methods like "world_to_screen" much nicer to use (and cleans up internals in a number of places). That wouldn't block anything here, just something to start thinking about / developing opinions on.

[alice-i-cecile]

Relevant to some of the general sentiment expressed here: in my "high level render targets" changes i'm experimenting with syncing render target logical and physical width/height to Camera fields, which makes methods like "world_to_screen" much nicer to use (and cleans up internals in a number of places).

The main complaint I have here is the need for Assets<Images> in these APIs. I understand why it exists (because we may be rendering to something other than a window), but it's a confusing and boilerplate-heavy API. It sounds like we'll be able to clean that up with your changes, which I would really like.

[mockersf]

For my use case, having a world_to_ndc works better than having to go through the screen dimensions with world_to_screen. And as a bonus you don't need the render target size 🙂

[cart]

bors r+

[bors]

Pull request successfully merged into main.

Build succeeded:

• build-android
• build (nightly, ubuntu-latest)
• build (stable, macos-latest)
• build (stable, ubuntu-latest)
• build (stable, windows-latest)
• build-wasm (nightly, ubuntu-latest)
• build-wasm (stable, ubuntu-latest)
• check-compiles
• check-doc
• check-markdown-links
• check-missing-examples-in-docs
• check-unused-dependencies
• ci
• markdownlint
• miri
• run-examples