97a5059535
8 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Lynn
|
97a5059535
|
Gizmo line styles (#12394)
# Objective - Adds line styles to bevy gizmos, suggestion of #9400 - Currently solid and dotted lines are implemented but this can easily be extended to support dashed lines as well if that is wanted. ## Solution - Adds the enum `GizmoLineStyle` and uses it in each `GizmoConfig` to configure the style of the line. - Each "dot" in a dotted line has the same width and height as the `line_width` of the corresponding line. --- ## Changelog - Added `GizmoLineStyle` to `bevy_gizmos` - Added a `line_style: GizmoLineStyle ` attribute to `GizmoConfig` - Updated the `lines.wgsl` shader and the pipelines accordingly. ## Migration Guide - Any manually created `GizmoConfig` must now include the `line_style` attribute ## Additional information Some pretty pictures :) This is the 3d_gizmos example with/without `line_perspective`: <img width="1440" alt="Screenshot 2024-03-09 at 23 25 53" src="https://github.com/bevyengine/bevy/assets/62256001/b1b97311-e78d-4de3-8dfe-9e48a35bb27d"> <img width="1440" alt="Screenshot 2024-03-09 at 23 25 39" src="https://github.com/bevyengine/bevy/assets/62256001/50ee8ecb-5290-484d-ba36-7fd028374f7f"> And the 2d example: <img width="1440" alt="Screenshot 2024-03-09 at 23 25 06" src="https://github.com/bevyengine/bevy/assets/62256001/4452168f-d605-4333-bfa5-5461d268b132"> --------- Co-authored-by: BD103 <59022059+BD103@users.noreply.github.com> |
||
|
Lynn
|
27215b79b0
|
Gizmo line joints (#12252)
# Objective - Adds gizmo line joints, suggestion of #9400 ## Solution - Adds `line_joints: GizmoLineJoint` to `GizmoConfig`. Currently the following values are supported: - `GizmoLineJoint::None`: does not draw line joints, same behaviour as previously - `GizmoLineJoint::Bevel`: draws a single triangle between the lines - `GizmoLineJoint::Miter` / 'spiky joints': draws two triangles between the lines extending them until they meet at a (miter) point. - NOTE: for very small angles between the lines, which happens frequently in 3d, the miter point will be very far away from the point at which the lines meet. - `GizmoLineJoint::Round(resolution)`: Draw a circle arc between the lines. The circle is a triangle fan of `resolution` triangles. --- ## Changelog - Added `GizmoLineJoint`, use that in `GizmoConfig` and added necessary pipelines and draw commands. - Added a new `line_joints.wgsl` shader containing three vertex shaders `vertex_bevel`, `vertex_miter` and `vertex_round` as well as a basic `fragment` shader. ## Migration Guide Any manually created `GizmoConfig`s must now set the `.line_joints` field. ## Known issues - The way we currently create basic closed shapes like rectangles, circles, triangles or really any closed 2d shape means that one of the corners will not be drawn with joints, although that would probably be expected. (see the triangle in the 2d image) - This could be somewhat mitigated by introducing line caps or fixed by adding another segment overlapping the first of the strip. (Maybe in a followup PR?) - 3d shapes can look 'off' with line joints (especially bevel) because wherever 3 or more lines meet one of them may stick out beyond the joint drawn between the other 2. - Adding additional lines so that there is a joint between every line at a corner would fix this but would probably be too computationally expensive. - Miter joints are 'unreasonably long' for very small angles between the lines (the angle is the angle between the lines in screen space). This is technically correct but distracting and does not feel right, especially in 3d contexts. I think limiting the length of the miter to the point at which the lines meet might be a good idea. - The joints may be drawn with a different gizmo in-between them and their corresponding lines in 2d. Some sort of z-ordering would probably be good here, but I believe this may be out of scope for this PR. ## Additional information Some pretty images :) <img width="1175" alt="Screenshot 2024-03-02 at 04 53 50" src="https://github.com/bevyengine/bevy/assets/62256001/58df7e63-9376-4430-8871-32adba0cb53b"> - Note that the top vertex does not have a joint drawn. <img width="1440" alt="Screenshot 2024-03-02 at 05 03 55" src="https://github.com/bevyengine/bevy/assets/62256001/137a00cf-cbd4-48c2-a46f-4b47492d4fd9"> Now for a weird video: https://github.com/bevyengine/bevy/assets/62256001/93026f48-f1d6-46fe-9163-5ab548a3fce4 - The black lines shooting out from the cube are miter joints that get very long because the lines between which they are drawn are (almost) collinear in screen space. --------- Co-authored-by: Pablo Reinhardt <126117294+pablo-lua@users.noreply.github.com> |
||
|
Rob Parrett
|
0746b8eb4c
|
Fix green colors becoming darker in various examples (#12328)
# Objective Fixes #12225 Prior to the `bevy_color` port, `GREEN` used to mean "full green." But it is now a much darker color matching the css1 spec. ## Solution Change usages of `basic::GREEN` or `css::GREEN` to `LIME` to restore the examples to their former colors. This also removes the duplicate definition of `GREEN` from `css`. (it was already re-exported from `basic`) ## Note A lot of these examples could use nicer colors. I'm not trying to do that here. "Dark Grey" will be tackled separately and has its own tracking issue. |
||
|
Alice Cecile
|
599e5e4e76
|
Migrate from LegacyColor to bevy_color::Color (#12163)
# Objective - As part of the migration process we need to a) see the end effect of the migration on user ergonomics b) check for serious perf regressions c) actually migrate the code - To accomplish this, I'm going to attempt to migrate all of the remaining user-facing usages of `LegacyColor` in one PR, being careful to keep a clean commit history. - Fixes #12056. ## Solution I've chosen to use the polymorphic `Color` type as our standard user-facing API. - [x] Migrate `bevy_gizmos`. - [x] Take `impl Into<Color>` in all `bevy_gizmos` APIs - [x] Migrate sprites - [x] Migrate UI - [x] Migrate `ColorMaterial` - [x] Migrate `MaterialMesh2D` - [x] Migrate fog - [x] Migrate lights - [x] Migrate StandardMaterial - [x] Migrate wireframes - [x] Migrate clear color - [x] Migrate text - [x] Migrate gltf loader - [x] Register color types for reflection - [x] Remove `LegacyColor` - [x] Make sure CI passes Incidental improvements to ease migration: - added `Color::srgba_u8`, `Color::srgba_from_array` and friends - added `set_alpha`, `is_fully_transparent` and `is_fully_opaque` to the `Alpha` trait - add and immediately deprecate (lol) `Color::rgb` and friends in favor of more explicit and consistent `Color::srgb` - standardized on white and black for most example text colors - added vector field traits to `LinearRgba`: ~~`Add`, `Sub`, `AddAssign`, `SubAssign`,~~ `Mul<f32>` and `Div<f32>`. Multiplications and divisions do not scale alpha. `Add` and `Sub` have been cut from this PR. - added `LinearRgba` and `Srgba` `RED/GREEN/BLUE` - added `LinearRgba_to_f32_array` and `LinearRgba::to_u32` ## Migration Guide Bevy's color types have changed! Wherever you used a `bevy::render::Color`, a `bevy::color::Color` is used instead. These are quite similar! Both are enums storing a color in a specific color space (or to be more precise, using a specific color model). However, each of the different color models now has its own type. TODO... - `Color::rgba`, `Color::rgb`, `Color::rbga_u8`, `Color::rgb_u8`, `Color::rgb_from_array` are now `Color::srgba`, `Color::srgb`, `Color::srgba_u8`, `Color::srgb_u8` and `Color::srgb_from_array`. - `Color::set_a` and `Color::a` is now `Color::set_alpha` and `Color::alpha`. These are part of the `Alpha` trait in `bevy_color`. - `Color::is_fully_transparent` is now part of the `Alpha` trait in `bevy_color` - `Color::r`, `Color::set_r`, `Color::with_r` and the equivalents for `g`, `b` `h`, `s` and `l` have been removed due to causing silent relatively expensive conversions. Convert your `Color` into the desired color space, perform your operations there, and then convert it back into a polymorphic `Color` enum. - `Color::hex` is now `Srgba::hex`. Call `.into` or construct a `Color::Srgba` variant manually to convert it. - `WireframeMaterial`, `ExtractedUiNode`, `ExtractedDirectionalLight`, `ExtractedPointLight`, `ExtractedSpotLight` and `ExtractedSprite` now store a `LinearRgba`, rather than a polymorphic `Color` - `Color::rgb_linear` and `Color::rgba_linear` are now `Color::linear_rgb` and `Color::linear_rgba` - The various CSS color constants are no longer stored directly on `Color`. Instead, they're defined in the `Srgba` color space, and accessed via `bevy::color::palettes::css`. Call `.into()` on them to convert them into a `Color` for quick debugging use, and consider using the much prettier `tailwind` palette for prototyping. - The `LIME_GREEN` color has been renamed to `LIMEGREEN` to comply with the standard naming. - Vector field arithmetic operations on `Color` (add, subtract, multiply and divide by a f32) have been removed. Instead, convert your colors into `LinearRgba` space, and perform your operations explicitly there. This is particularly relevant when working with emissive or HDR colors, whose color channel values are routinely outside of the ordinary 0 to 1 range. - `Color::as_linear_rgba_f32` has been removed. Call `LinearRgba::to_f32_array` instead, converting if needed. - `Color::as_linear_rgba_u32` has been removed. Call `LinearRgba::to_u32` instead, converting if needed. - Several other color conversion methods to transform LCH or HSL colors into float arrays or `Vec` types have been removed. Please reimplement these externally or open a PR to re-add them if you found them particularly useful. - Various methods on `Color` such as `rgb` or `hsl` to convert the color into a specific color space have been removed. Convert into `LinearRgba`, then to the color space of your choice. - Various implicitly-converting color value methods on `Color` such as `r`, `g`, `b` or `h` have been removed. Please convert it into the color space of your choice, then check these properties. - `Color` no longer implements `AsBindGroup`. Store a `LinearRgba` internally instead to avoid conversion costs. --------- Co-authored-by: Alice Cecile <alice.i.cecil@gmail.com> Co-authored-by: Afonso Lage <lage.afonso@gmail.com> Co-authored-by: Rob Parrett <robparrett@gmail.com> Co-authored-by: Zachary Harrold <zac@harrold.com.au> |
||
|
Joona Aalto
|
f418de8eb6
|
Rename Direction2d/3d to Dir2/3 (#12189)
# Objective Split up from #12017, rename Bevy's direction types. Currently, Bevy has the `Direction2d`, `Direction3d`, and `Direction3dA` types, which provide a type-level guarantee that their contained vectors remain normalized. They can be very useful for a lot of APIs for safety, explicitness, and in some cases performance, as they can sometimes avoid unnecessary normalizations. However, many consider them to be inconvenient to use, and opt for standard vector types like `Vec3` because of this. One reason is that the direction type names are a bit long and can be annoying to write (of course you can use autocomplete, but just typing `Vec3` is still nicer), and in some intances, the extra characters can make formatting worse. The naming is also inconsistent with Glam's shorter type names, and results in names like `Direction3dA`, which (in my opinion) are difficult to read and even a bit ugly. This PR proposes renaming the types to `Dir2`, `Dir3`, and `Dir3A`. These names are nice and easy to write, consistent with Glam, and work well for variants like the SIMD aligned `Dir3A`. As a bonus, it can also result in nicer formatting in a lot of cases, which can be seen from the diff of this PR. Some examples of what it looks like: (copied from #12017) ```rust // Before let ray_cast = RayCast2d::new(Vec2::ZERO, Direction2d::X, 5.0); // After let ray_cast = RayCast2d::new(Vec2::ZERO, Dir2::X, 5.0); ``` ```rust // Before (an example using Bevy XPBD) let hit = spatial_query.cast_ray( Vec3::ZERO, Direction3d::X, f32::MAX, true, SpatialQueryFilter::default(), ); // After let hit = spatial_query.cast_ray( Vec3::ZERO, Dir3::X, f32::MAX, true, SpatialQueryFilter::default(), ); ``` ```rust // Before self.circle( Vec3::new(0.0, -2.0, 0.0), Direction3d::Y, 5.0, Color::TURQUOISE, ); // After (formatting is collapsed in this case) self.circle(Vec3::new(0.0, -2.0, 0.0), Dir3::Y, 5.0, Color::TURQUOISE); ``` ## Solution Rename `Direction2d`, `Direction3d`, and `Direction3dA` to `Dir2`, `Dir3`, and `Dir3A`. --- ## Migration Guide The `Direction2d` and `Direction3d` types have been renamed to `Dir2` and `Dir3`. ## Additional Context This has been brought up on the Discord a few times, and we had a small [poll](https://discord.com/channels/691052431525675048/1203087353850364004/1212465038711984158) on this. `Dir2`/`Dir3`/`Dir3A` was quite unanimously chosen as the best option, but of course it was a very small poll and inconclusive, so other opinions are certainly welcome too. --------- Co-authored-by: IceSentry <c.giguere42@gmail.com> |
||
|
Lynn
|
35cec8bd3a
|
Add Grid gizmos (#11988)
# Objective - Implement grid gizmos, suggestion of #9400 ## Solution - Added `gizmos.grid(...) ` and `gizmos.grid_2d(...)` - The grids may be configured using `.outer_edges(...)` to specify whether to draw the outer border/edges of the grid and `.skew(...)`to specify the skew of the grid along the x or y directions. --- ## Changelog - Added a `grid` module to `bevy_gizmos` containing `gizmos.grid(...) ` and `gizmos.grid_2d(...)` as well as assorted items. - Updated the `2d_gizmos` and `3d_gizmos` examples to use grids. ## Additional The 2D and 3D examples now look like this: <img width="1440" alt="Screenshot 2024-02-20 at 15 09 40" src="https://github.com/bevyengine/bevy/assets/62256001/ce04191e-d839-4faf-a6e3-49b6bb4b922b"> <img width="1440" alt="Screenshot 2024-02-20 at 15 10 07" src="https://github.com/bevyengine/bevy/assets/62256001/317459ba-d452-42eb-ae95-7c84cdbd569b"> |
||
|
Alice Cecile
|
de004da8d5
|
Rename bevy_render::Color to LegacyColor (#12069)
# Objective The migration process for `bevy_color` (#12013) will be fairly involved: there will be hundreds of affected files, and a large number of APIs. ## Solution To allow us to proceed granularly, we're going to keep both `bevy_color::Color` (new) and `bevy_render::Color` (old) around until the migration is complete. However, simply doing this directly is confusing! They're both called `Color`, making it very hard to tell when a portion of the code has been ported. As discussed in #12056, by renaming the old `Color` type, we can make it easier to gradually migrate over, one API at a time. ## Migration Guide THIS MIGRATION GUIDE INTENTIONALLY LEFT BLANK. This change should not be shipped to end users: delete this section in the final migration guide! --------- Co-authored-by: Alice Cecile <alice.i.cecil@gmail.com> |
||
|
Evgeny Kropotin
|
d3e839a8e5
|
Move gizmos examples in the separate folder (#11916)
# Objective Move Gizmo examples into the separate directory Fixes #11899 --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com> Co-authored-by: Joona Aalto <jondolf.dev@gmail.com> |