-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
Key render phases off the main world view entity, not the render world view entity. #16942
base: main
Are you sure you want to change the base?
Conversation
view entity. We won't be able to retain render phases from frame to frame if the keys are unstable. It's not as simple as simply keying off the main world entity, however, because some main world entities extract to multiple render world entities. For example, directional lights extract to multiple shadow cascades, and point lights extract to one view per cubemap face. Therefore, we key off a new type, `RetainedViewEntity`, which contains the main entity plus a *subview ID*. This is part of the preparation for retained bins.
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.
Nothing gets drawn for the UI, but I'm not very familiar with the camera extraction internals and I couldn't quite unravel the problem.
Very loosely, from what I can tell:
extract_default_ui_camera_view
spawns a default camera view entity for each camera which has an ExtractedView
with subview_index: 1
and then creates a corresponding TransparentUi
render phase.
But the extracted uinodes are given the entity id of the non-ui camera ExtractedView
entity so that in queue_uinodes
the non-ui view with subview_index: 0
is retrieved and then no TransparentUi
phases are found because they were all keyed to subview_index: 1
.
Setting the subview index to 1 in extract_cameras
fixes the UI examples but that breaks everything else of course.
This should fix the issue with the UI. The proper fix was a bit tricky and involved creating a new subgraph runner to make sure to run the UI rendering subgraph on the right render world entity. |
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.
Multi-window UI isn't working, I think I found the problem though.
Otherwise everything looks good now, the different shaders etc all seem to be working correctly.
let Some(mut render_views) = world.try_query::<&DefaultCameraView>() else { | ||
return Ok(()); | ||
}; | ||
let Some(default_camera_view) = render_views.iter(world).next() else { |
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.
The multiple_windows
example doesn't render the label for the second window. It seems that it just needs to look up the correct view using graph.view_entity()
here:
let Some(default_camera_view) = render_views.iter(world).next() else { | |
let Ok(default_camera_view) = render_views.get(world, graph.view_entity()) else { |
We won't be able to retain render phases from frame to frame if the keys are unstable. It's not as simple as simply keying off the main world entity, however, because some main world entities extract to multiple render world entities. For example, directional lights extract to multiple shadow cascades, and point lights extract to one view per cubemap face. Therefore, we key off a new type,
RetainedViewEntity
, which contains the main entity plus a subview ID.This is part of the preparation for retained bins.