-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add RenderTarget::TextureView
#8042
Add RenderTarget::TextureView
#8042
Conversation
Welcome, new contributor! Please make sure you've read our contributing guide and we look forward to reviewing your pull request shortly ✨ |
It looks like your PR is a breaking change, but you didn't provide a migration guide. Could you add some context on what users should update when this change get released in a new version of Bevy? |
Bumping |
@@ -368,6 +370,24 @@ impl CameraRenderGraph { | |||
} | |||
} | |||
|
|||
/// Stores Texture Views used as render targets. | |||
#[derive(Default, Clone, Resource, ExtractResource)] | |||
pub struct ManualTextureViews(HashMap<u32, (TextureView, UVec2)>); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure what "Manual" is supposed to mean here.
I think I'd prefer using a wrapper type for the u32. It wasn't immediately obvious to me what the u32 was supposed to be.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd also add a note in the comment that the UVec2 is the size. Or maybe just say that it stores the texture view and it's size
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok great I've updated the comment.
Manual
is intended to describe that these are texture views we are managing ourselves outside of Bevy, either by creating them in wgpu or being given them by OpenXR, WebXR etc. I agree its not obvious, any suggestions? Maybe something like Custom
or External
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added the ManualTextureViewHandle
wrapper type, im a little concerned its bloating the camera.rs
file, would you like the ManualTextureView
struct moved to a seperate file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've created manual_texture_view.rs
, let me know if you want that reverted.
@@ -502,13 +542,16 @@ impl NormalizedRenderTarget { | |||
/// [`OrthographicProjection`]: crate::camera::OrthographicProjection | |||
/// [`PerspectiveProjection`]: crate::camera::PerspectiveProjection | |||
/// [`Projection`]: crate::camera::Projection | |||
/// [`CoreSet::PostUpdate`]: bevy_app::CoreSet::PostUpdate |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why was this line added?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -436,13 +465,15 @@ impl NormalizedRenderTarget { | |||
NormalizedRenderTarget::Image(image_handle) => { | |||
images.get(image_handle).map(|image| image.texture_format) | |||
} | |||
NormalizedRenderTarget::TextureView(_) => Some(TextureFormat::bevy_default()), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this line is correct. As far as I know, it's possible for a TextureView to be a different format.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok we should check that, my understanding was that the TextureView
is opaque and we dont have access to the format, @kcking do you have thoughts on this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if it is something we want to track, maybe instead of storing a (TextureView,UVec2)
tuple, we can store some struct
pub struct ManualTextureView {
texture_view: TextureView,
size: UVec2,
format: TextureFormat,
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed, storing the correct TextureFormat
makes the most sense to me.
RenderTarget::TextureView
So, the implementation seems good to me, but I'm not sure I understand why this is necessary. Isn't the Image render target just a wrapper around targetting a TextureView? As in, couldn't you just use the render to image feature and use the texture view of the image? |
There's a quick discord conversation about this, essentially OpenXR requires you to use its |
Alright, makes sense. In that case this PR seems fine. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a suggestion for adding a comment regarding the use case for this.
Looks good otherwise, though I'm not a rendering expert. Has my approval with or without my suggestion.
Co-authored-by: Paul Hansen <mail@paul.rs>
Co-authored-by: Paul Hansen <mail@paul.rs>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oof looks like my suggestion somehow ended up with trailing spaces and it broke cargo format. My bad.
Co-authored-by: Paul Hansen <mail@paul.rs>
Co-authored-by: Paul Hansen <mail@paul.rs>
Straightforward enough, and on the critical path. Let's see what the community can do with this <3 |
# Objective We can currently set `camera.target` to either an `Image` or `Window`. For OpenXR & WebXR we need to be able to render to a `TextureView`. This partially addresses bevyengine#115 as with the addition we can create internal and external xr crates. ## Solution A `TextureView` item is added to the `RenderTarget` enum. It holds an id which is looked up by a `ManualTextureViews` resource, much like how `Assets<Image>` works. I believe this approach was first used by @kcking in their [xr fork](https://github.com/kcking/bevy/blob/eb39afd51bcbab38de6efbeeb0646e01e2ce4766/crates/bevy_render/src/camera/camera.rs#L322). The only change is that a `u32` is used to index the textures as `FromReflect` does not support `uuid` and I don't know how to implement that. --- ## Changelog ### Added Render: Added `RenderTarget::TextureView` as a `camera.target` option, enabling rendering directly to a `TextureView`. ## Migration Guide References to the `RenderTarget` enum will need to handle the additional field, ie in `match` statements. --- ## Comments - The [wgpu work](gfx-rs/wgpu@c039a74) done by @expenses allows us to create framebuffer texture views from `wgpu v0.15, bevy 0.10`. - I got the WebXR techniques from the [xr fork](https://github.com/dekuraan/xr-bevy) by @dekuraan. - I have tested this with a wip [external webxr crate](https://github.com/mrchantey/forky/blob/018e22bb06b7542419db95f5332c7684931c9c95/crates/bevy_webxr/src/bevy_utils/xr_render.rs#L50) on an Oculus Quest 2. ![Screenshot 2023-03-11 230651](https://user-images.githubusercontent.com/25616826/224483696-c176c06f-a806-4abe-a494-b2e096ac96b7.png) --------- Co-authored-by: Carter Anderson <mcanders1@gmail.com> Co-authored-by: Paul Hansen <mail@paul.rs>
Objective
We can currently set
camera.target
to either anImage
orWindow
. For OpenXR & WebXR we need to be able to render to aTextureView
.This partially addresses #115 as with the addition we can create internal and external xr crates.
Solution
A
TextureView
item is added to theRenderTarget
enum. It holds an id which is looked up by aManualTextureViews
resource, much like howAssets<Image>
works.I believe this approach was first used by @kcking in their xr fork. The only change is that a
u32
is used to index the textures asFromReflect
does not supportuuid
and I don't know how to implement that.Changelog
Added
Render: Added
RenderTarget::TextureView
as acamera.target
option, enabling rendering directly to aTextureView
.Migration Guide
References to the
RenderTarget
enum will need to handle the additional field, ie inmatch
statements.Comments
wgpu v0.15, bevy 0.10
.