-
-
Couldn't load subscription status.
- Fork 4.2k
Port bevy_core_pipeline to LinearRgba
#12116
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
Port bevy_core_pipeline to LinearRgba
#12116
Conversation
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.
One really great thing about having this baked into the type system is that we're not paying for the cost of conversion or the branches within the color itself inside the renderer.
…i-cecile/bevy into bevy_core_pipeline_colors
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.
Looks good.
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.
Look good to me! I'm glad we can start being more explicit through the type system around what colour spaces certain areas of Bevy want/need.
| impl From<LinearRgba> for wgpu::Color { | ||
| fn from(color: LinearRgba) -> Self { | ||
| wgpu::Color { | ||
| r: color.red as f64, | ||
| g: color.green as f64, | ||
| b: color.blue as f64, | ||
| a: color.alpha as f64, | ||
| } | ||
| } | ||
| } |
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.
Since bevy_color is our new color management library specifically for Bevy, would it be worth moving to f64 internally to avoid this casting? The extra precision will eat up more memory, but also expose the full precision of wgpu to end users.
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.
That's a good question. I think that should be investigated after migration: then we can get both benchmark results and see if there's meaningfully improved color fidelity or numerical stability.
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.
Probably won't make a big difference on the code-path where wgpu almost immediately casts the color back to a f32 😄
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.
Well, at this rate I guess we're getting bevy_wgpu
# Objective - We should move towards a consistent use of the new `bevy_color` crate. - As discussed in bevyengine#12089, splitting this work up into small pieces makes it easier to review. ## Solution - Port all uses of `LegacyColor` in the `bevy_core_pipeline` to `LinearRgba` - `LinearRgba` is the correct type to use for internal rendering types - Added `LinearRgba::BLACK` and `WHITE` (used during migration) - Add `LinearRgba::grey` to more easily construct balanced grey colors (used during migration) - Add a conversion from `LinearRgba` to `wgpu::Color`. The converse was not done at this time, as this is typically a user error. I did not change the field type of the clear color on the cameras: as this is user-facing, this should be done in concert with the other configurable fields. ## Migration Guide `ColorAttachment` now stores a `LinearRgba` color, rather than a Bevy 0.13 `Color`. `set_blend_constant` now takes a `LinearRgba` argument, rather than a Bevy 0.13 `Color`. --------- Co-authored-by: Alice Cecile <alice.i.cecil@gmail.com>
# Objective - We should move towards a consistent use of the new `bevy_color` crate. - As discussed in bevyengine#12089, splitting this work up into small pieces makes it easier to review. ## Solution - Port all uses of `LegacyColor` in the `bevy_core_pipeline` to `LinearRgba` - `LinearRgba` is the correct type to use for internal rendering types - Added `LinearRgba::BLACK` and `WHITE` (used during migration) - Add `LinearRgba::grey` to more easily construct balanced grey colors (used during migration) - Add a conversion from `LinearRgba` to `wgpu::Color`. The converse was not done at this time, as this is typically a user error. I did not change the field type of the clear color on the cameras: as this is user-facing, this should be done in concert with the other configurable fields. ## Migration Guide `ColorAttachment` now stores a `LinearRgba` color, rather than a Bevy 0.13 `Color`. `set_blend_constant` now takes a `LinearRgba` argument, rather than a Bevy 0.13 `Color`. --------- Co-authored-by: Alice Cecile <alice.i.cecil@gmail.com>
Objective
bevy_colorcrate.Solution
LegacyColorin thebevy_core_pipelinetoLinearRgbaLinearRgbais the correct type to use for internal rendering typesLinearRgba::BLACKandWHITE(used during migration)LinearRgba::greyto more easily construct balanced grey colors (used during migration)LinearRgbatowgpu::Color. The converse was not done at this time, as this is typically a user error.I did not change the field type of the clear color on the cameras: as this is user-facing, this should be done in concert with the other configurable fields.
Migration Guide
ColorAttachmentnow stores aLinearRgbacolor, rather than a Bevy 0.13Color.set_blend_constantnow takes aLinearRgbaargument, rather than a Bevy 0.13Color.