-
-
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
use Material
for wireframes
#5314
use Material
for wireframes
#5314
Conversation
I'm on board with this direction; unifying this is nice. |
@alice-i-cecile from a user perspective there is no breaking change right now |
It's the same WireframePlugin and Wireframe Component that was used before, it's just the internals that changed, so I don't think it counts as breaking. |
f3ef677
to
6b12dc9
Compare
6b12dc9
to
bb3a879
Compare
Example |
It may be worth turning the original version without the material into an example since it was a good reference for rendering something simple without using the material system. |
I think the |
How does this relate to #5303? |
I think it was just me trying to aggressively reduce the size of the PR and have the customizable color in it's own PR |
I realized we don't need the vertex shader anymore since we can use the vertex shader from the Material api. This also fixed a bug where wireframes are broken in DX12 because of some vertex shader issues. |
There's now a few conflicts because of the wireframe override PR. I personally think the api of that PR is flawed so I I'll submit a PR with an API that isn't a breaking change and should create less conflict with this PR. I think we should decided if we want to merge this PR first since it will make it easier for me to resolve conflicts #10023 |
I fixed the conflicts with the |
I don't know what's up with the CI failure. It works fine locally and it's complaining about completely unrelated parts of the codebase. |
Co-authored-by: Alice Cecile <[email protected]>
# Objective - Make the wireframe colors configurable at the global level and the single mesh level - Based on #5314 This video shows what happens when playing with various settings from the example https://github.com/bevyengine/bevy/assets/8348954/1ee9aee0-fab7-4da8-bc5d-8d0562bb34e6 ## Solution - Add a `color` field to the `WireframeMaterial` - Use a `WireframeColor` component to configure the color per entity - Add a `default_color` field to `WireframeConfig` for global wireframes or wireframes with no specified color. ## Notes - Most of the docs and the general idea for `WireframeColor` came from [UberLambda](https://github.com/UberLambda) in #3677 but the code ended up completely different so I created a separate branch. ~~I'm not sure how to correctly credit them on this PR.~~ (I re-created the commit but I added them as co-author in the commit message) ~~Closes #3677 ~~Closes #5301 ~~#5314 should be merged before this PR.~~
# Objective - Use the `Material` abstraction for the Wireframes - Right now this doesn't have many benefits other than simplifying some of the rendering code - We can reuse the default vertex shader and avoid rendering inconsistencies - The goal is to have a material with a color on each mesh so this approach will make it easier to implement - Originally done in bevyengine#5303 but I decided to split the Material part to it's own PR and then adding per-entity colors and globally configurable colors will be a much simpler diff. ## Solution - Use the new `Material` abstraction for the Wireframes ## Notes It's possible this isn't ideal since this adds a `Handle<WireframeMaterial>` to all the meshes compared to the original approach that didn't need anything. I didn't notice any performance impact on my machine. This might be a surprising usage of `Material` at first, because intuitively you only have one material per mesh, but the way it's implemented you can have as many different types of materials as you want on a mesh. ## Migration Guide `WireframePipeline` was removed. If you were using it directly, please create an issue explaining your use case. --------- Co-authored-by: Alice Cecile <[email protected]>
# Objective - Make the wireframe colors configurable at the global level and the single mesh level - Based on bevyengine#5314 This video shows what happens when playing with various settings from the example https://github.com/bevyengine/bevy/assets/8348954/1ee9aee0-fab7-4da8-bc5d-8d0562bb34e6 ## Solution - Add a `color` field to the `WireframeMaterial` - Use a `WireframeColor` component to configure the color per entity - Add a `default_color` field to `WireframeConfig` for global wireframes or wireframes with no specified color. ## Notes - Most of the docs and the general idea for `WireframeColor` came from [UberLambda](https://github.com/UberLambda) in bevyengine#3677 but the code ended up completely different so I created a separate branch. ~~I'm not sure how to correctly credit them on this PR.~~ (I re-created the commit but I added them as co-author in the commit message) ~~Closes bevyengine#3677 ~~Closes bevyengine#5301 ~~bevyengine#5314 should be merged before this PR.~~
# Objective - Use the `Material` abstraction for the Wireframes - Right now this doesn't have many benefits other than simplifying some of the rendering code - We can reuse the default vertex shader and avoid rendering inconsistencies - The goal is to have a material with a color on each mesh so this approach will make it easier to implement - Originally done in bevyengine#5303 but I decided to split the Material part to it's own PR and then adding per-entity colors and globally configurable colors will be a much simpler diff. ## Solution - Use the new `Material` abstraction for the Wireframes ## Notes It's possible this isn't ideal since this adds a `Handle<WireframeMaterial>` to all the meshes compared to the original approach that didn't need anything. I didn't notice any performance impact on my machine. This might be a surprising usage of `Material` at first, because intuitively you only have one material per mesh, but the way it's implemented you can have as many different types of materials as you want on a mesh. ## Migration Guide `WireframePipeline` was removed. If you were using it directly, please create an issue explaining your use case. --------- Co-authored-by: Alice Cecile <[email protected]>
# Objective - Make the wireframe colors configurable at the global level and the single mesh level - Based on bevyengine#5314 This video shows what happens when playing with various settings from the example https://github.com/bevyengine/bevy/assets/8348954/1ee9aee0-fab7-4da8-bc5d-8d0562bb34e6 ## Solution - Add a `color` field to the `WireframeMaterial` - Use a `WireframeColor` component to configure the color per entity - Add a `default_color` field to `WireframeConfig` for global wireframes or wireframes with no specified color. ## Notes - Most of the docs and the general idea for `WireframeColor` came from [UberLambda](https://github.com/UberLambda) in bevyengine#3677 but the code ended up completely different so I created a separate branch. ~~I'm not sure how to correctly credit them on this PR.~~ (I re-created the commit but I added them as co-author in the commit message) ~~Closes bevyengine#3677 ~~Closes bevyengine#5301 ~~bevyengine#5314 should be merged before this PR.~~
# Objective - Use the `Material` abstraction for the Wireframes - Right now this doesn't have many benefits other than simplifying some of the rendering code - We can reuse the default vertex shader and avoid rendering inconsistencies - The goal is to have a material with a color on each mesh so this approach will make it easier to implement - Originally done in bevyengine#5303 but I decided to split the Material part to it's own PR and then adding per-entity colors and globally configurable colors will be a much simpler diff. ## Solution - Use the new `Material` abstraction for the Wireframes ## Notes It's possible this isn't ideal since this adds a `Handle<WireframeMaterial>` to all the meshes compared to the original approach that didn't need anything. I didn't notice any performance impact on my machine. This might be a surprising usage of `Material` at first, because intuitively you only have one material per mesh, but the way it's implemented you can have as many different types of materials as you want on a mesh. ## Migration Guide `WireframePipeline` was removed. If you were using it directly, please create an issue explaining your use case. --------- Co-authored-by: Alice Cecile <[email protected]>
# Objective - Make the wireframe colors configurable at the global level and the single mesh level - Based on bevyengine#5314 This video shows what happens when playing with various settings from the example https://github.com/bevyengine/bevy/assets/8348954/1ee9aee0-fab7-4da8-bc5d-8d0562bb34e6 ## Solution - Add a `color` field to the `WireframeMaterial` - Use a `WireframeColor` component to configure the color per entity - Add a `default_color` field to `WireframeConfig` for global wireframes or wireframes with no specified color. ## Notes - Most of the docs and the general idea for `WireframeColor` came from [UberLambda](https://github.com/UberLambda) in bevyengine#3677 but the code ended up completely different so I created a separate branch. ~~I'm not sure how to correctly credit them on this PR.~~ (I re-created the commit but I added them as co-author in the commit message) ~~Closes bevyengine#3677 ~~Closes bevyengine#5301 ~~bevyengine#5314 should be merged before this PR.~~
Objective
Material
abstraction for the WireframesSolution
Material
abstraction for the WireframesNotes
It's possible this isn't ideal since this adds a
Handle<WireframeMaterial>
to all the meshes compared to the original approach that didn't need anything. I didn't notice any performance impact on my machine.This might be a surprising usage of
Material
at first, because intuitively you only have one material per mesh, but the way it's implemented you can have as many different types of materials as you want on a mesh.Migration Guide
WireframePipeline
was removed. If you were using it directly, please create an issue explaining your use case.