Configurable colors for wireframe#5303
Conversation
aa8b88c to
f93e37e
Compare
|
Could you restructure the code to follow the order of the original so that the diff is cleaner? It’s a bit all over the place removing and inserting lines that are from practically the same code in different places in the file which makes it difficult to see what actually changed and so, difficult to review. |
|
Done. It's still a bit noisy because the approach is so different, but it's much better now and that also made me realize I removed the Reflect stuff by mistake. |
|
@superdump should I make a PR with only the update to the material system and make another PR that adds per-entity colors after that? It would probably make it easier to review, but it felt like the PR was small enough to review all in one go. It would help make the diffs less noisy though. |
alice-i-cecile
left a comment
There was a problem hiding this comment.
Minor feedback, mostly on docs, but looking good!
JMS55
left a comment
There was a problem hiding this comment.
I'm a bit confused on the different components. Can you explain the structure of how things work? Why is WireframeColor a separate component, instead of an optional field of Wireframe?
|
I somewhat forgot about this PR, I'll try to update it. For the WireframeColor component, I don't remember the detaisl, but I believe this was discussed in this PR #3677 Also, I originally wanted us to merge, #5314 first and then add color support just to make the PRs easier to review and merge. Looking back on the changes now, I think they are simple enough to just be done in one PR. |
|
Right, so the WireframeColor component makes it way easier to use change detection to detect when/if the color changed |
323b3b3 to
84c5d44
Compare
c407f7b to
df3d127
Compare
Material for wireframes and configurable colors
mogambro
left a comment
There was a problem hiding this comment.
I don't know about the finished conversation https://github.com/bevyengine/bevy/pull/5303/files?diff=split&w=0#r1025198770
but apart from that, I reviewed it and I approve the changes.
I am not sure about potential performance pitfalls or such, but the code changes look clean and understandable.
|
@nerdachse the main blocker is waiting on #5314 the issue is that most rendering devs are currently working on other bigger reviews but once those are done both wireframe PRs should be merged fairly quickly. |
# 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 #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 <alice.i.cecile@gmail.com>
|
@IceSentry the prerequisite PR has been merged now; can you clean up merge conflicts when you get a chance? |
18e4e3d to
4e076ac
Compare
|
Thanks :) FYI, I'm going to wait to merge this until #9258 is through: Rob's asked me to hold off on merging rendering PRs until that's done to avoid generating complex conflicts for the author. |
|
I don't think there would be any conflict with this PR, but I'm in no hurry to merge this PR either. |
|
If deferred rendering for some reason doesn't make it into 0.12 it would still be awesome to have this. I am highly anticipating this feature and would hate to wait another 3 months. Also, while I understand that there are PRs that warrant holding off other work, I argue that they should be sparse and not hold too much other valuable work "hostage" so to speak. Just my 0.05 of course. I am very grateful for both, deferred rendering and this, actually most that's happening in bevy! So please don't take this the wrong way! |
|
Yep, this will be in 0.12 one way or another :) Definitely agree that blocking work to get specific PRs through should be very rare: I think the only other time we've done that this cycle is for Assets v2. |
# 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 <alice.i.cecile@gmail.com>
# 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 <alice.i.cecile@gmail.com>
# 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 <alice.i.cecile@gmail.com>
# 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
Materialfor wireframes #5314This video shows what happens when playing with various settings from the example
wireframe_5FP7z78Faz.mp4
Solution
colorfield to theWireframeMaterialWireframeColorcomponent to configure the color per entitydefault_colorfield toWireframeConfigfor global wireframes or wireframes with no specified color.Notes
WireframeColorcame from UberLambda in Add per-entity colored wireframes #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 #3677Closes #5301#5314 should be merged before this PR.