Skip to content
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

[Merged by Bors] - Port bevy_ui to pipelined-rendering #2653

Closed
wants to merge 19 commits into from

Conversation

Davier
Copy link
Contributor

@Davier Davier commented Aug 14, 2021

Objective

Port bevy_ui to pipelined-rendering (see #2535 )

Solution

I did some changes during the port:

  • separate color from the texture asset (as suggested here)
  • give the vertex shader a per-instance buffer instead of per-vertex buffer (incompatible with batching)

Remaining features to implement to reach parity with the old renderer:

  • textures
  • TextBundle

I'd also like to add these features, but they need some design discussion:

  • batching
  • separate opaque and transparent phases
  • multiple windows
  • texture atlases
  • (maybe) clipping

@cart
Copy link
Member

cart commented Aug 14, 2021

Brilliant! I'll take a look at this ASAP.

In regard to your second and third lists:

Fortunately we already have a draft MSAA implementation.

I'm cool with entirely ignoring the third list in the description. I'd prefer to not focus any time on adding new features to the current Bevy UI system, as thats next on our list of things to rework.

@alice-i-cecile alice-i-cecile added A-Rendering Drawing game state to the screen A-UI Graphical user interfaces, styles, layouts, and widgets labels Aug 16, 2021
@alice-i-cecile alice-i-cecile added this to the Bevy 0.6 milestone Aug 16, 2021
@alice-i-cecile
Copy link
Member

For batching, perhaps coordinate with #2642?

@cart
Copy link
Member

cart commented Aug 18, 2021

For batching, perhaps coordinate with #2642?

I'd honestly rather just punt it unless @Davier is extremely motivated. We should invest the smallest amount of time possible in "legacy stuff".

@Davier
Copy link
Contributor Author

Davier commented Aug 21, 2021

For batching, perhaps coordinate with #2642?

I've taken a lot of inspiration from that PR already, so implementing batching should be straightforward. I'm happy to do it (and any other point in the 3rd list) if you agree to review it, but I understand that you have a limited bandwidth.

I'd honestly rather just punt it unless @Davier is extremely motivated. We should invest the smallest amount of time possible in "legacy stuff".

I'm doing it to learn so it's fine even if we throw it away soon. Or is there is another part of the renderer that I could help with?

examples/README.md Outdated Show resolved Hide resolved
@cart
Copy link
Member

cart commented Aug 24, 2021

I would review it, but given that I haven't reviewed the current batching pr yet, maybe hold off until after. There are a few corner cases that I'm worried about that I haven't tested on the current impl.

@Davier
Copy link
Contributor Author

Davier commented Oct 16, 2021

Text and Text2d are now implemented. The ui_pipelined and text2d_pipelined examples seem to work correctly.
Should we start to review and merge now so that more people can try out the new renderer? Or wait for the other in-flight PRs to be merged (shaders as assets, sprite batching, MSAA, ...)?

@Davier Davier marked this pull request as ready for review October 16, 2021 13:49
@Davier
Copy link
Contributor Author

Davier commented Nov 24, 2021

Updated on top of pipelined-rendering. The first commit is a simple copy of the old bevy_ui and bevy_text to make reviewing changes easier.
I used the last changes in bevy_sprites, including batching.
I'll rebase on top of #3175 when it's merged.

Remaining issues/questions:

  1. the background is not cleared with ClearColor if there is no 2d or 3d camera, in that case the UI is drawn on top of garbage (see Support for RenderPass that renders to WindowSwapChain before MainPass  #3190).
  2. the VisibleEntities component is required for a camera to work, even if the UI camera has no culling
  3. should the UiPipeline specialization be removed since the key is empty? I kept it to make it easier to add new specializations in the future.
  4. should the UI renderer use MSAA? (it's not fit for 2D rendering as discussed on discord, we should consider other anti-aliasing methods such as TAA)

Possible future improvements:

  1. clipping
  2. texture atlases
  3. opaque / transparent / alpha mask phases
  4. use depth buffer to avoid overdraw
  5. include flags in the vertex buffer and skip sampling the texture when possible (like for PBR)

@cart cart changed the base branch from pipelined-rendering to main November 24, 2021 21:50
@cart
Copy link
Member

cart commented Nov 24, 2021

Changed the base branch to main because thats where development is happening now!

Copy link
Contributor

@colepoirier colepoirier left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I approve, but someone with more bevy experience and/or more experience with the new renderer will need to do the final sign off. I don’t see any obvious problems but I don’t think I would be able to see a great deal of the problems if they do exist.

Copy link
Contributor Author

@Davier Davier left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did another full self review. I caught a few things and detailed a few others, hopefully it will help other reviewers.
I recommend selecting all but the first commit in the filters, to view what actually changed.

crates/bevy_asset/src/handle.rs Outdated Show resolved Hide resolved
examples/ui/ui_pipelined.rs Outdated Show resolved Hide resolved
pipelined/bevy_core_pipeline/src/lib.rs Show resolved Hide resolved
Comment on lines 89 to 93
for (entity, mut draw, visible, text, global_transform, calculated_size) in query.iter_mut() {
if !visible.is_visible {
continue;
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be updated now that we have Visibility and ComputedVisibility

// FIXME there is no frustrum culling for UI
pub visible_entities: VisibleEntities,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I considered there is no need for frustum culling since every UI item is usually on-screen, so I didn't use Visibility, ComputedVisibility and VisibleEntities. VisibleEntities is only included here because the camera systems require it.

However I now realize we need a way to manually hide on-screen nodes, like it was possible with the Visible component. Instead of adding the full frustum culling like in bevy_sprite2, I think I'll just skip queuing when Style::display == Display::None.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In case of a scrollable element part of the UI items are likely outside of the bounds of the scrollable element and thus must be invisible.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm tackling that case in another (soon to be) PR for clipping, where I implement the Style::overflow property (it is currently commented out). I calculate how items are clipped in the queue_uinode fn, and skip those completely clipped. It instead might be possible to calculate it beforehand and setting a ComputedVisibility accordingly.

pipelined/bevy_ui2/src/lib.rs Outdated Show resolved Hide resolved
pipelined/bevy_ui2/src/render/mod.rs Outdated Show resolved Hide resolved
pipelined/bevy_ui2/src/render/render_pass.rs Show resolved Hide resolved
pipelined/bevy_ui2/src/ui_node.rs Outdated Show resolved Hide resolved
pipelined/bevy_ui2/src/update.rs Show resolved Hide resolved
@Davier
Copy link
Contributor Author

Davier commented Nov 28, 2021

There is an issue with updating images (including text glyphs), like for sprites (see #3207). Whichever solution is chosen for sprite should also be applied for UI.

@Davier
Copy link
Contributor Author

Davier commented Dec 3, 2021

There is an issue with updating images (including text glyphs), like for sprites (see #3207). Whichever solution is chosen for sprite should also be applied for UI.

Fixed in a6f1581 (after rebasing on top of the fix for sprites). I chose to reuse SpriteAssetEvents, since the bevy_ui2 already depends on bevy_sprite2. Maybe that resource should be renamed to be more generic, or even placed in bevy_render2 or bevy_core_pipeline?

@TheRawMeatball
Copy link
Member

The last commit could likely be reverted, as in retrospect, I don't think the ControlNode s are a great idea, and were merged too hastily.

@cart
Copy link
Member

cart commented Dec 9, 2021

I'm diving in to this now. Tip for reviewing: deleting the old bevy_ui and bevy_text and replacing them with the pipelined crates makes it much easier to review these changes because you can see the actual diffs.

@mockersf
Copy link
Member

mockersf commented Dec 9, 2021

or in GitHub UI, there's is a dropdown when viewing file changes saying "changes from all commits" where you can select every commit but the first one (the url won't be valid if more commits are pushed)

@cart
Copy link
Member

cart commented Dec 9, 2021

Just merged #3209. Lets resolve conflicts, make sure this plays nicely with the new clearing behavior, and address the remaining open comments. Then i think this is ready to go!

@Davier
Copy link
Contributor Author

Davier commented Dec 10, 2021

Unless there is more feedback on Visibility, everything is addressed. I only lightly tested the new modifications. I'll play a bit more with it tomorrow, but it already looks good to merge if you want to.

@cart
Copy link
Member

cart commented Dec 10, 2021

Changes look good to me. I'm gonna think on the visibility situation for a bit, but I think this is probably good to merge!

@cart
Copy link
Member

cart commented Dec 10, 2021

I'm fine with the choices you made regarding visibility. An empty VisibleEntities on the ui camera doesnt bother me and it leaves the doors open to future UI visibility work. The fact that UI elements dont have visibility / computed visibilty atm is also ok by me (for now).

@cart
Copy link
Member

cart commented Dec 10, 2021

bors r+

bors bot pushed a commit that referenced this pull request Dec 10, 2021
# Objective

Port bevy_ui to pipelined-rendering (see #2535 )

## Solution

I did some changes during the port:
- [X] separate color from the texture asset (as suggested [here](https://discord.com/channels/691052431525675048/743663924229963868/874353914525413406))
- [X] ~give the vertex shader a per-instance buffer instead of per-vertex buffer~ (incompatible with batching)

Remaining features to implement to reach parity with the old renderer:
- [x] textures
- [X] TextBundle

I'd also like to add these features, but they need some design discussion:
- [x] batching
- [ ] separate opaque and transparent phases
- [ ] multiple windows
- [ ] texture atlases
- [ ] (maybe) clipping
@bors bors bot changed the title Port bevy_ui to pipelined-rendering [Merged by Bors] - Port bevy_ui to pipelined-rendering Dec 10, 2021
@bors bors bot closed this Dec 10, 2021
@Davier Davier deleted the ui_pipelined branch December 11, 2021 13:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Rendering Drawing game state to the screen A-UI Graphical user interfaces, styles, layouts, and widgets
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants