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.

Sign up for GitHub

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

Jump to bottom

Consolidate Render(Ui)Materials(2d) into RenderAssets #12827

Merged
merged 14 commits into from
Apr 9, 2024
Merged

Consolidate Render(Ui)Materials(2d) into RenderAssets #12827

merged 14 commits into from
Apr 9, 2024

Conversation

superdump
Copy link
Contributor

@superdump superdump commented Apr 1, 2024 •
edited
Loading

Objective

  • Replace RenderMaterials / RenderMaterials2d / RenderUiMaterials with RenderAssets to enable implementing changes to one thing, RenderAssets, that applies to all use cases rather than duplicating changes everywhere for multiple things that should be one thing.
  • Adopts Improve render asset #8149

Solution

  • Make RenderAsset generic over the destination type rather than the source type as in Improve render asset #8149
  • Use RenderAssets<PreparedMaterial<M>> etc for render materials

Changelog

  • Changed:
    • The RenderAsset trait is now implemented on the destination type. Its SourceAsset associated type refers to the type of the source asset.
    • RenderMaterials, RenderMaterials2d, and RenderUiMaterials have been replaced by RenderAssets<PreparedMaterial<M>> and similar.

Migration Guide

  • RenderAsset is now implemented for the destination type rather that the source asset type. The source asset type is now the RenderAsset trait's SourceAsset associated type.

@superdump
Implement RenderAsset trait for target type instead of source type
4052c56 
This will enable removal of RenderMaterials, and it allows implementing
creation of GPU types from any type.

Co-authored-by: Wilhelm Vallrand <>
@superdump
Remove all Render(Ui)Materials(2d) implementations
89eeb5d
@superdump superdump mentioned this pull request Apr 1, 2024
Closed
@superdump
Copy link
Contributor Author

superdump commented Apr 1, 2024 •
edited
Loading

I would love to find a way to not require people to implement AssetUsages for custom materials, and instead just use a default. But I haven't had any good ideas yet. I can't implement for AssetUsages for T at least. And not every Asset should be a RenderAsset.

@NthTensor NthTensor added C-Feature A new feature, making something new possible A-Rendering Drawing game state to the screen A-Assets Load files from disk to use for things like images, models, and sounds M-Needs-Migration-Guide A breaking change to Bevy's public API that needs to be noted in a migration guide labels Apr 1, 2024
@superdump superdump force-pushed the render-asset-generic-over-target branch from 8f133a8 to 7abd50e Compare April 2, 2024 01:13
@infmagic2047
Copy link
Contributor

I would love to find a way to not require people to implement AssetUsages for custom materials, and instead just use a default. But I haven't had any good ideas yet. I can't implement for AssetUsages for T at least. And not every Asset should be a RenderAsset.

My ideas: Keep the asset_usage() method on RenderAsset instead of using a separate trait (it should take &Self::SourceAsset param now). Add methods to Material traits that allow overriding the usage, and use them in the RenderAsset implementation of PreparedMaterial. The required migration would be minimal in this way.

@superdump
Copy link
Contributor Author

@infmagic2047 great idea! So simple! :) I love it.

@IceSentry IceSentry self-requested a review April 5, 2024 21:20
pcwalton
pcwalton approved these changes Apr 5, 2024
View reviewed changes
Copy link
Contributor

@pcwalton pcwalton left a comment

Choose a reason for hiding this comment

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

This looks fine. I'll trust you that it was necessary to move RenderAsset over to be implemented on the render world type.

@IceSentry
Copy link
Contributor

@pcwalton here's the justification from the original PR:

Remove one to one correlation between "main world" asset and GPU asset, by swapping base type that implements RenderAsset to be the GPU asset type. That would make RenderAssetPlugin more flexible, being able to prepare different data based on same source asset (example: effect plugin could preprocess mesh buffer data for specialized rendering, without affecting main render flow).
That also makes RenderAssets more explicit.

@IceSentry IceSentry added the S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it label Apr 6, 2024
@superdump
Copy link
Contributor Author

Please don’t merge this yet. I want to think about a couple of things with it so I am convinced implementing RenderAsset on the destination type is better.

@superdump superdump removed the S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it label Apr 7, 2024
@superdump superdump added the S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it label Apr 9, 2024
@superdump superdump requested a review from robtfm April 9, 2024 13:18
@superdump superdump enabled auto-merge April 9, 2024 13:24
@superdump superdump added this pull request to the merge queue Apr 9, 2024
@superdump
Copy link
Contributor Author

I turned out that robtfm had a branch that did basically the same thing last year after I commented that implementing RenderAsset on types that implement Materials was problematic in various ways:

Merged via the queue into bevyengine:main with commit ab7cbfa Apr 9, 2024
28 checks passed
@superdump superdump mentioned this pull request Apr 9, 2024
Open
19 tasks
@JMS55 JMS55 mentioned this pull request May 25, 2024
Closed
ChristopherBiscardi added a commit to ChristopherBiscardi/bevy_ecs_tilemap that referenced this pull request Jun 7, 2024
@ChristopherBiscardi
RenderAssets<Image> is now RenderAssets<GpuImage>
2bdc9f1 
Implemented in [12827](bevyengine/bevy#12827)
@ChristopherBiscardi ChristopherBiscardi mentioned this pull request Jun 7, 2024
Merged
@interwhy interwhy mentioned this pull request Jun 8, 2024
Merged
zhaop added a commit to zhaop/transform-gizmo that referenced this pull request Jun 24, 2024
@zhaop
Impl RenderAssets for GizmoBuffers instead of GizmoDrawData
4c7fbeb 
Addresses Bevy [12827](bevyengine/bevy#12827)
@zhaop zhaop mentioned this pull request Jun 24, 2024
Closed
rparrett added a commit to StarArawn/bevy_ecs_tilemap that referenced this pull request Jul 5, 2024
@ChristopherBiscardi @rparrett
Update to 0.14.0 (#537)
aee4779 
* Update to 0.14.0-rc.2

* [12997](bevyengine/bevy#12997): rename `multi-threaded` to `multi_threaded`

* RenderAssets<Image> is now RenderAssets<GpuImage>

Implemented in [12827](bevyengine/bevy#12827)

* FloatOrd is now in bevy_math

implemented in [12732](bevyengine/bevy#12732)

* convert Transparent2d::dynamic_offset to extra_index

[12889](bevyengine/bevy#12889) Gpu Frustum Culling removed the dynamic_offset of Transparent2d and it became `extra_index` with the special value `PhaseItemExtraIndex::NONE`, which indicates the `None` that was here previously

* RenderPhase<Transparent2d> -> ViewSortedRenderPhases<Transparent2d>

[12453](https://github.com/StarArawn/bevy_ecs_tilemap/pull/bevyengine/bevy#12453): Render phases are now binned or sorted.

Following the changes in the `mesh2d_manual` [example](https://github.com/bevyengine/bevy/blob/ecdd1624f302c5f71aaed95b0984cbbecf8880b7/examples/2d/mesh2d_manual.rs#L357-L358): use the `ViewSortedRenderPhases` resource.

* get_sub_app_mut is now an Option

in [9202](https://github.com/StarArawn/bevy_ecs_tilemap/pull/bevyengine/bevy/pull/9202) SubApp access has changed

* GpuImage::size f32 -> u32 via UVec2

[11698](bevyengine/bevy#11698) changed `GpuImage::size` to `UVec2`.

Right above this, `Extent3d` does the same thing, so I'm taking a small leap and assuming can `as`.

* GpuMesh::primitive_topology -> key_bits/BaseMeshPipeline

[12791](bevyengine/bevy#12791) the `primitive_topology` field on `GpuMesh` was removed in favor of `key_bits` which can be constructed using `BaseMeshPipeline::from_primitive_topology`

* RenderChunk2d::prepare requires &mut MeshVertexBufferLayouts now

[12216](bevyengine/bevy#12216) introduced an argument `&mut MeshVertexBufferLayouts` to `get_mesh_vertex_buffer_layout`, which bevy_ecs_tilemap calls in `RenderChunk2d::prepare`

* into_linear_f32 -> color.0.linear().to_f32_array(),

[12163](bevyengine/bevy#12163) bevy_color was created and Color handling has changed. Specifically Color::as_linear_rgba_f32 has been removed.

LinearRgba is now its own type that can be accessed via [`linear()`](https://docs.rs/bevy/0.14.0-rc.2/bevy/color/enum.Color.html#method.linear) and then converted.

* Must specify type of VisibleEntities when accessing

[12582](bevyengine/bevy#12582) divided `VisibleEntities` into separate lists. So now we have to specify which kind of entity we want. I think we want the Mesh here, and I think we can get rid of the `.index` calls on Entity since Entity [already compares bits](https://docs.rs/bevy_ecs/0.14.0-rc.2/src/bevy_ecs/entity/mod.rs.html#173) for optimized codegen purposes. Waiting to do that until the other changes are in though so as to not change functionality until post-upgrade.

* app.world access is functions now

- [9202](bevyengine/bevy#9202) changed world access to functions. [relevent line](https://github.com/bevyengine/bevy/pull/9202/files#diff-b2fba3a0c86e496085ce7f0e3f1de5960cb754c7d215ed0f087aa556e529f97fR640)
- This also surfaced [12655](bevyengine/bevy#12655) which removed `Into<AssetId<T>>` for `Handle<T>`. using a reference or .id() is the solution here.

* We don't need `World::cell`, and it doesn't exist anymore

In [12551](bevyengine/bevy#12551) `WorldCell` was removed.

...but it turns out we don't need it or its replacement anyway.

* examples error out unless this bevy bug is addressed with these features being added

bevyengine/bevy#13728

* check_visibility is required for the entity that is renderable

As a result of [12582](bevyengine/bevy#12582) `check_visibility` must be implemented for the "renderable" tilemap entities. Doing this is trivial by taking advantage of the
existing `check_visibility` type arguments, which accept a [`QF: QueryFilter + 'static`](https://docs.rs/bevy/0.14.0-rc.2/bevy/render/view/fn.check_visibility.html).

The same `QueryFilter`` is used when checking `VisibleEntities`. I've chosen `With<TilemapRenderSettings` because presumably if the entity doesn't have a `TilemapRenderSettings` then it will not be rendering, but this could be as sophisticated or simple as we want.

For example `WithLight` is currently implemented as

```rust
pub type WithLight = Or<(With<PointLight>, With<SpotLight>, With<DirectionalLight>)>;
```

* view.view_proj -> view.clip_from_world

[13289](bevyengine/bevy#13489) introduced matrix naming changes, including `view_proj` which becomes `clip_from_world`

* color changes to make tests runnable

* clippy fix

* Update Cargo.toml

Co-authored-by: Rob Parrett <[email protected]>

* Update Cargo.toml

Co-authored-by: Rob Parrett <[email protected]>

* final clippy fixes

* Update Cargo.toml

Co-authored-by: Rob Parrett <[email protected]>

* Simplify async loading in ldtk/tiled helpers

See Bevy #12550

* remove second allow lint

* rc.3 bump

* bump version for major release

* remove unused features

---------

Co-authored-by: Rob Parrett <[email protected]>
@zhaop zhaop mentioned this pull request Jul 6, 2024
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@JMS55 JMS55 JMS55 left review comments

@IceSentry IceSentry IceSentry approved these changes

@pcwalton pcwalton pcwalton approved these changes

@robtfm robtfm Awaiting requested review from robtfm

Assignees
No one assigned
Labels
A-Assets Load files from disk to use for things like images, models, and sounds A-Rendering Drawing game state to the screen C-Feature A new feature, making something new possible M-Needs-Migration-Guide A breaking change to Bevy's public API that needs to be noted in a migration guide S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
6 participants
@superdump @infmagic2047 @IceSentry @pcwalton @JMS55 @NthTensor