Depth prepass #19
Closed
Depth prepass #19
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# Objective - Remove a warning when building for wasm ## Solution - Do not import the dependency when building for wasm
# Objective - Fixes early return when viewport is not set. This now matches the description of the function. ## Solution - Remove errant try `?`.
- changed `EntityCountDiagnosticsPlugin` to not use an exclusive system to get its entity count - removed mention of `WgpuResourceDiagnosticsPlugin` in example `log_diagnostics` as it doesn't exist anymore - added ability to enable, disable ~~or toggle~~ a diagnostic (fix bevyengine#3767) - made diagnostic values lazy, so they are only computed if the diagnostic is enabled - do not log an average for diagnostics with only one value - removed `sum` function from diagnostic as it isn't really useful - ~~do not keep an average of the FPS diagnostic. it is already an average on the last 20 frames, so the average FPS was an average of the last 20 frames over the last 20 frames~~ - do not compute the FPS value as an average over the last 20 frames but give the actual "instant FPS" - updated log format to use variable capture - added some doc - the frame counter diagnostic value can be reseted to 0
…bevyengine#4782) builds on top of bevyengine#4780 # Objective `Reflect` and `Serialize` are currently very tied together because `Reflect` has a `fn serialize(&self) -> Option<Serializable<'_>>` method. Because of that, we can either implement `Reflect` for types like `Option<T>` with `T: Serialize` and have `fn serialize` be implemented, or without the bound but having `fn serialize` return `None`. By separating `ReflectSerialize` into a separate type (like how it already is for `ReflectDeserialize`, `ReflectDefault`), we could separately `.register::<Option<T>>()` and `.register_data::<Option<T>, ReflectSerialize>()` only if the type `T: Serialize`. This PR does not change the registration but allows it to be changed in a future PR. ## Solution - add the type ```rust struct ReflectSerialize { .. } impl<T: Reflect + Serialize> FromType<T> for ReflectSerialize { .. } ``` - remove `#[reflect(Serialize)]` special casing. - when serializing reflect value types, look for `ReflectSerialize` in the `TypeRegistry` instead of calling `value.serialize()`
# Objective - Add benchmarks to test the performance of `Schedule`'s system dependency resolution. ## Solution - Do a series of benchmarks while increasing the number of systems in the schedule to see how the run-time scales. - Split the benchmarks into a group with no dependencies, and a group with many dependencies.
# Objective - Fixes bevyengine#4996 ## Solution - Panicking on the global task pool is probably bad. This changes the panicking test to use a single threaded stage to run the test instead. - I checked the other #[should_panic] - I also added explicit ordering between the transform propagate system and the parent update system. The ambiguous ordering didn't seem to be causing problems, but the tests are probably more correct this way. The plugins that add these systems have an explicit ordering. I can remove this if necessary. ## Note I don't have a 100% mental model of why panicking is causing intermittent failures. It probably has to do with a task for one of the other tests landing on the panicking thread when it actually panics. Why this causes a problem I'm not sure, but this PR seems to fix things. ## Open questions - there are some other #[should_panic] tests that run on the task pool in stage.rs. I don't think we restart panicked threads, so this might be killing most of the threads on the pool. But since they're not causing test failures, we should probably decide what to do about that separately. The solution in this PR won't work since those tests are explicitly testing parallelism.
Adds a `release_all` function to `Input` that releases all of the currently pressed inputs and marks them as just released.
**Why?** The `value_parser` `clap` attribute was added in [version 3.2.0][0]. With the current version of `3.1.12` users can get errors like: ``` error: unexpected attribute: value_parser --> tools/spancmp/src/main.rs:18:25 | 18 | #[clap(short, long, value_parser, default_value_t = 0.0)] | ^^^^^^^^^^^^ ``` See bevyengine#4944 (comment) for more details. [0]: https://github.com/clap-rs/clap/blob/master/CHANGELOG.md#320---2022-06-13
**This Commit** 1. Makes it so the sentence doesn't read "are contributors who have Have actively ..." 2. Makes it so all three bullet points end in punctuation **Notes** Could also remove the leading "Have" from all bullet points and leave it on the previous sentence. That's the least redundant but I guess this is more flexible if we want to add a sentence that doesn't start with "Have" later.
Adds a `reset_all` method to reset `pressed`, `just_pressed`, and `just_released` on the `Input`. Fixes bevyengine#3383
# Objective `nix-shell` reported: ```error: 'x11' has been renamed to/replaced by 'xlibsWrapper'```. ## Solution Replacing `x11` with `xlibsWrapper` in the Nix section of linux_dependencies.md fixes the problem on my system, and bevy projects build fine.
# Objective `bevy_ui` doesn't support correctly touch inputs because of two problems in the focus system: - It attempts to retrieve touch input with a specific `0` id - It doesn't retrieve touch positions and bases its focus solely on mouse position, absent from mobile devices ## Solution I added a few methods to the `Touches` resource, allowing to check if **any** touch input was pressed, released or cancelled and to retrieve the *position* of the first pressed touch input and adapted the focus system. I added a test button to the *iOS* example and it works correclty on emulator. I did not test on a real touch device as: - Android is not working (bevyengine#3249) - I don't have an iOS device
# Objective The descriptions included in the API docs of `entity` module, `Entity` struct, and `Component` trait have some issues: 1. the concept of entity is not clearly defined, 2. descriptions are a little bit out of place, 3. in a case the description leak too many details about the implementation, 4. some descriptions are not exhaustive, 5. there are not enough examples, 6. the content can be formatted in a much better way. ## Solution 1. ~~Stress the fact that entity is an abstract and elementary concept. Abstract because the concept of entity is not hardcoded into the library but emerges from the interaction of `Entity` with every other part of `bevy_ecs`, like components and world methods. Elementary because it is a fundamental concept that cannot be defined with other terms (like point in euclidean geometry, or time in classical physics).~~ We decided to omit the definition of entity in the API docs ([see why]). It is only described in its relationship with components. 2. Information has been moved to relevant places and links are used instead in the other places. 3. Implementation details about `Entity` have been reduced. 4. Descriptions have been made more exhaustive by stating how to obtain and use items. Entity operations are enriched with `World` methods. 5. Examples have been added or enriched. 6. Sections have been added to organize content. Entity operations are now laid out in a table. ### Todo list - [x] Break lines at sentence-level. ## For reviewers - ~~I added a TODO over `Component` docs, make sure to check it out and discuss it if necessary.~~ ([Resolved]) - You can easily check the rendered documentation by doing `cargo doc -p bevy_ecs --no-deps --open`. [see why]: bevyengine#4767 (comment) [Resolved]: bevyengine#4767 (comment)
…el (bevyengine#4663) # Objective Further speed up visibility checking by removing the main sources of contention for the system. ## Solution - ~~Make `ComputedVisibility` a resource wrapping a `FixedBitset`.~~ - ~~Remove `ComputedVisibility` as a component.~~ ~~This adds a one-bit overhead to every entity in the app world. For a game with 100,000 entities, this is 12.5KB of memory. This is still small enough to fit entirely in most L1 caches. Also removes the need for a per-Entity change detection tick. This reduces the memory footprint of ComputedVisibility 72x.~~ ~~The decreased memory usage and less fragmented memory locality should provide significant performance benefits.~~ ~~Clearing visible entities should be significantly faster than before:~~ - ~~Setting one `u32` to 0 clears 32 entities per cycle.~~ - ~~No archetype fragmentation to contend with.~~ - ~~Change detection is applied to the resource, so there is no per-Entity update tick requirement.~~ ~~The side benefit of this design is that it removes one more "computed component" from userspace. Though accessing the values within it are now less ergonomic.~~ This PR changes `crossbeam_channel` in `check_visibility` to use a `Local<ThreadLocal<Cell<Vec<Entity>>>` to mark down visible entities instead. Co-Authored-By: TheRawMeatball <therawmeatball@gmail.com> Co-Authored-By: Aevyrie <aevyrie@gmail.com>
# Objective Closes bevyengine#1557. Partially addresses bevyengine#3362. Cleanup the public facing API for storage types. Most of these APIs are difficult to use safely when directly interfacing with these types, and is also currently impossible to interact with in normal ECS use as there is no `World::storages_mut`. The majority of these types should be easy enough to read, and perhaps mutate the contents, but never structurally altered without the same checks in the rest of bevy_ecs code. This both cleans up the public facing types and helps use unused code detection to remove a few of the APIs we're not using internally. ## Solution - Mark all APIs that take `&mut T` under `bevy_ecs::storage` as `pub(crate)` or `pub(super)` - Cleanup after it all. Entire type visibility changes: - `BlobVec` is `pub(super)`, only storage code should be directly interacting with it. - `SparseArray` is now `pub(crate)` for the entire type. It's an implementation detail for `Table` and `(Component)SparseSet`. - `TableMoveResult` is now `pub(crate) --- ## Changelog TODO ## Migration Guide Dear God, I hope not.
# Objective - Builds on top of bevyengine#4938 - Make clustered-forward PBR lighting/shadows functionality callable - See bevyengine#3969 for details ## Solution - Add `PbrInput` struct type containing a `StandardMaterial`, occlusion, world_position, world_normal, and frag_coord - Split functionality to calculate the unit view vector, and normal-mapped normal into `bevy_pbr::pbr_functions` - Split high-level shading flow into `pbr(in: PbrInput, N: vec3<f32>, V: vec3<f32>, is_orthographic: bool)` function in `bevy_pbr::pbr_functions` - Rework `pbr.wgsl` fragment stage entry point to make use of the new functions - This has been benchmarked on an M1 Max using `many_cubes -- sphere`. `main` had a median frame time of 15.88ms, this PR 15.99ms, which is a 0.69% frame time increase, which is within noise in my opinion. --- ## Changelog - Added: PBR shading code is now callable. Import `bevy_pbr::pbr_functions` and its dependencies, create a `PbrInput`, calculate the unit view and normal-mapped normal vectors and whether the projection is orthographic, and call `pbr()`!
…gine#4716) # Objective DioxusLabs and Bevy have taken over maintaining what was our abandoned ui layout dependency [stretch](https://github.com/vislyhq/stretch). Dioxus' fork has had a lot of work done on it by @alice-i-cecile, @Weibye , @jkelleyrtp, @mockersf, @HackerFoo, @TimJentzsch and a dozen other contributors and now is in much better shape than stretch was. The updated crate is called taffy and is available on github [here](https://github.com/DioxusLabs/taffy) ([taffy](https://crates.io/crates/taffy) on crates.io). The goal of this PR is to replace stretch v0.3.2 with taffy v0.1.0. ## Solution I changed the bevy_ui Cargo.toml to depend on taffy instead of stretch and fixed all the errors rustc complained about. --- ## Changelog Changed bevy_ui layout dependency from stretch to taffy (the maintained fork of stretch). fixes bevyengine#677 ## Migration Guide The public api of taffy is different from that of stretch so please advise me on what to do here @alice-i-cecile.
# Objective - When changing animation, all the foxes didn't play the same animation ## Solution - Update the animation index only once
# Objective Partially addresses bevyengine#4291. Speed up the sort phase for unbatched render phases. ## Solution Split out one of the optimizations in bevyengine#4899 and allow implementors of `PhaseItem` to change what kind of sort is used when sorting the items in the phase. This currently includes Stable, Unstable, and Unsorted. Each of these corresponds to `Vec::sort_by_key`, `Vec::sort_unstable_by_key`, and no sorting at all. The default is `Unstable`. The last one can be used as a default if users introduce a preliminary depth prepass. ## Performance This will not impact the performance of any batched phases, as it is still using a stable sort. 2D's only phase is unchanged. All 3D phases are unbatched currently, and will benefit from this change. On `many_cubes`, where the primary phase is opaque, this change sees a speed up from 907.02us -> 477.62us, a 47.35% reduction.  ## Future Work There were prior discussions to add support for faster radix sorts in bevyengine#4291, which in theory should be a `O(n)` instead of a `O(nlog(n))` time. [`voracious`](https://crates.io/crates/voracious_radix_sort) has been proposed, but it seems to be optimize for use cases with more than 30,000 items, which may be atypical for most systems. Another optimization included in bevyengine#4899 is to reduce the size of a few of the IDs commonly used in `PhaseItem` implementations to shrink the types to make swapping/sorting faster. Both `CachedPipelineId` and `DrawFunctionId` could be reduced to `u32` instead of `usize`. Ideally, this should automatically change to use stable sorts when `BatchedPhaseItem` is implemented on the same phase item type, but this requires specialization, which may not land in stable Rust for a short while. --- ## Changelog Added: `PhaseItem::sort` ## Migration Guide RenderPhases now default to a unstable sort (via `slice::sort_unstable_by_key`). This can typically improve sort phase performance, but may produce incorrect batching results when implementing `BatchedPhaseItem`. To revert to the older stable sort, manually implement `PhaseItem::sort` to implement a stable sort (i.e. via `slice::sort_by_key`). Co-authored-by: Federico Rinaldi <gisquerin@gmail.com> Co-authored-by: Robert Swain <robert.swain@gmail.com> Co-authored-by: colepoirier <colepoirier@gmail.com>
Fixed a typo, removed unused component, normalized comments added a touch more detail.
# Objective Small cleanup to NixOS dependencies. Switched `clang` and `lld` to `bintools` because of [this](https://matklad.github.io/2022/03/14/rpath-or-why-lld-doesnt-work-on-nixos.html).
# Objective - The android example icon doesn't show up ## Solution - I fixed the android metadata to match `cargo-apk` manifest
# Objective Update pbr mesh shader to use correct normals for skinned meshes. ## Solution Only use `mesh_normal_local_to_world` for normals if `SKINNED` is not defined.
# Objective - When experimenting with rendering on lowspec machines I've run into some non-obvious things (huge thanks [superdump](https://github.com/superdump), [alice-i-cecile](https://github.com/alice-i-cecile), [mockersf](https://github.com/mockersf) and others for help) and so volunteered to document them. - Is a follow-up of https://discordapp.com/channels/691052431525675048/989137552919375902 ## Solution - I added docs about necessity of `ANGLE` to use `Backends::GL` on Windows. - Also documented why `prepare_windows` can be long to execute and some causes.
# Objective - Have information about examples only in one place that can be used for the repo and for the website (and remove the need to keep a list of example to build for wasm in the website https://github.com/bevyengine/bevy-website/blob/75acb730406ef9c5928d37daf8bb32e4dbeb8b13/generate-wasm-examples/generate_wasm_examples.sh#L92-L99) ## Solution - Add metadata about examples in `Cargo.toml` - Build the `examples/README.md` from a template using those metadata. I used tera as the template engine to use the same tech as the website. - Make CI fail if an example is missing metadata, or if the readme file needs to be updated (the command to update it is displayed in the failed step in CI) ## Remaining To Do - After the next release with this merged in, the website will be able to be updated to use those metadata too - I would like to build the examples in wasm and make them available at http://dev-docs.bevyengine.org/ but that will require more design - bevyengine/bevy-website#299 for other ToDos Co-authored-by: Readme <github-actions@github.com>
# Objective - Simplify the process of obtaining a `ComponentId` instance corresponding to a `Component`. - Resolves bevyengine#5060. ## Solution - Add a `component_id::<T: Component>(&self)` function to both `World` and `Components` to retrieve the `ComponentId` associated with `T` from a immutable reference. --- ## Changelog - Added `World::component_id::<C>()` and `Components::component_id::<C>()` to retrieve a `Component`'s corresponding `ComponentId` if it exists.
# Objective - Allow custom shaders to reuse the HDR results of PBR. ## Solution - Separate `pbr()` and `tone_mapping()` into 2 functions in `pbr_functions.wgsl`.
# Objective Attempt to more clearly document `ImageSettings` and setting a default sampler for new images, as per bevyengine#5046 ## Changelog - Moved ImageSettings into image.rs, image::* is already exported. Makes it simpler for linking docs. - Renamed "DefaultImageSampler" to "RenderDefaultImageSampler". Not a great name, but more consistent with other render resources. - Added/updated related docs
# Objective - Fixes bevyengine#5083 ## Solution I looked at the implementation of those events. I noticed that they both are adaptations of `winit`'s `DeviceEvent`/`WindowEvent` enum variants. Therefore I based the description of the items on the documentation provided by the upstream crate. I also added a link to `CursorMoved`, just like `MouseMotion` already has. ## Observations - Looking at the implementation of `MouseMotion`, I noticed the `DeviceId` field of the `winit` event is discarded by `bevy_input`. This means that in the case a machine has multiple pointing devices, it is impossible to distinguish to which one the event is referring to. **EDIT:** just tested, `MouseMotion` events are emitted for movement of both mice.
# Objective - Small bug in the example game given in examples/ecs/ecs_guide Currently, if there are 2 players in this example game, the function exclusive_player_system can add a player with the name "Player 2". However, the name should be "Player 3". This PR fixes this. I also add a message to inform that a new player has arrived in the mock game. Co-authored-by: Dilyan Kostov <dilyanks@amazon.com>
# Objective - Fix a typo on `SystemParam` docs ## Solution - added 'be'. - Hurray my first OSS PR! ---
…ne#5626) # Objective - The `Display` impl for `ReflectPathError` is pretty unspecific (e.g. `the current struct doesn't have a field with the given name` - it has info for better messages available ## Solution - make the display impl more descriptive by including values from the type
# Objective While trying out the lint `unsafe_op_in_unsafe_fn` I noticed that `insert_resource_by_id` didn't drop the old value if it already existed, and reimplemented `Column::replace` manually for no apparent reason. ## Solution - use `Column::replace` and add a test expecting the correct drop count --- ## Changelog - `World::insert_resource_by_id` will now correctly drop the old resource value, if one already existed
…e#5665) # Objective Make CI pass on bevy main. Update to rust-1.63, updated clippy to 1.63 which introduced the following enhancements: - [undocumented_unsafe_blocks](https://rust-lang.github.io/rust-clippy/master/index.html#undocumented_unsafe_blocks): Now also lints on unsafe trait implementations This caught two incorrectly written ( but existing) safety comments for unsafe traits. ## Solution Fix the comment to use `SAFETY:`
# Objective Fixing some grammar in the rustdoc for RenderGraph
# Objective Fixes bevyengine#5668. The Rust version used in the CI `build` step previously depended on the default Rust version defined by GitHub in the Ubuntu image: <https://github.com/actions/runner-images/blob/main/images/linux/Ubuntu2004-Readme.md#rust-tools> This currently doesn't allow us to use Rust 1.63 features until this version is updated. ## Solution We now use the `actions-rs/toolchain@v1` action to always use the latest stable Rust version. This is already used for other CI jobs that we have.
…#5678) # Objective The `deny.toml` file defines some crates that are skipped for duplicate dependency detection, because the issues are deeper in the dependency tree and not easily fixable. However, two of those exceptions are no longer necessary. ## Solution Remove `hashbrown` and `mio` from the skipped crates, according to `cargo deny check` this is no longer needed.
# Objective Remove unused `enum DepthCalculation` and its usages. This was used to compute visible entities in the [old renderer](https://github.com/bevyengine/bevy/blob/db665b96c07084f081b0c9ab367e67297fe35132/crates/bevy_render/src/camera/visible_entities.rs), but is now unused. ## Solution `sed 's/DepthCalculation//g'` --- ## Changelog ### Changed Removed `bevy_render::camera::DepthCalculation`. ## Migration Guide Remove references to `bevy_render::camera::DepthCalculation`, such as `use bevy_render::camera::DepthCalculation`. Remove `depth_calculation` fields from Projections.
# Objective When an invalid attribute is inserted and the LogPlugin is not enabled the full error is not printed which means makes it hard to diagnose. ## Solution - Always print the full message in the panic. ## Notes I originally had a separate error log because I wanted to make it clearer for users, but this is probably causing more issues than necessary.
# Objective While poking around the hierarchy code, I wondered why some asserts in tests were duplicated. Some git blame later, I found out that commit ( bevyengine@8eb0440 ) added already existing asserts while removing others. ## Solution Remove the duplicated asserts.
## Objective Fixed some typos I came across while reading examples.
# Objective Fixes bevyengine#5597 ## Solution Registered type at suggested place.
) # Objective This PR changes it possible to use vertex colors without a texture using the bevy_sprite ColorMaterial. Fixes bevyengine#5679 ## Solution - Made multiplication of the output color independent of the COLOR_MATERIAL_FLAGS_TEXTURE_BIT bit - Extended mesh2d_vertex_color_texture example to show off both vertex colors and tinting Not sure if extending the existing example was the right call but it seems to be reasonable to me. I couldn't find any tests for the shaders and I think adding shader testing would be beyond the scope of this PR. So no tests in this PR. 😬 Co-authored-by: Jonas Wagner <jonas@29a.ch>
# Objective - fix a typo on RendGraph Docs ## Solution - fixed typo --- Co-authored-by: Carter Anderson <mcanders1@gmail.com>
# Objective - Replace the square with a circle in the breakout example. - Fixes bevyengine#4324, adopted from bevyengine#4682 by @shaderduck. ## Solution - Uses the Mesh2D APIs to draw a circle. The collision still uses the AABB algorithm, but it seems to be working fine, and I haven't seen any odd looking cases.
# Objective Rust 1.63 resolved [an issue](rust-lang/rust#83701) that prevents you from combining explicit generic arguments with `impl Trait` arguments. Now, we no longer need to use dynamic dispatch to work around this. ## Migration Guide The methods `Schedule::get_stage` and `get_stage_mut` now accept `impl StageLabel` instead of `&dyn StageLabel`. ### Before ```rust let stage = schedule.get_stage_mut::<SystemStage>(&MyLabel)?; ``` ### After ```rust let stage = schedule.get_stage_mut::<SystemStage>(MyLabel)?; ```
# Objective The reflection impls on `Option<T>` have the bound `T: Reflect + Clone`. This means that using `FromReflect` requires `Clone` even though we can normally get away with just `FromReflect`. ## Solution Update the bounds on `Option<T>` to match that of `Vec<T>`, where `T: FromReflect`. This helps remove a `Clone` implementation that may be undesired but added for the sole purpose of getting the code to compile. --- ## Changelog * Reflection on `Option<T>` now has `T` bound by `FromReflect` rather than `Reflect + Clone` * Added a `FromReflect` impl for `Instant` ## Migration Guide If using `Option<T>` with Bevy's reflection API, `T` now needs to implement `FromReflect` rather than just `Clone`. This can be achieved easily by simply deriving `FromReflect`: ```rust // OLD #[derive(Reflect, Clone)] struct Foo; let reflected: Box<dyn Reflect> = Box::new(Some(Foo)); // NEW #[derive(Reflect, FromReflect)] struct Foo; let reflected: Box<dyn Reflect> = Box::new(Some(Foo)); ``` > Note: You can still derive `Clone`, but it's not required in order to compile.
…evyengine#5543 (bevyengine#5546) Probably a copy-paste error, but `Add<Color>` and `AddAssign<Color>` should use `rhs.as_hlsa_f32()` instead of `rhs.as_linear_rgba_f32()` when the LHS is a `Color::Hsla`. Fixes bevyengine#5543. Co-authored-by: Verte <105466627+vertesians@users.noreply.github.com>
…ne#5731) # Objective - Similar to `SystemChangeTick`, probably somewhat useful for debugging messages. --- ## Changelog - Added `SystemName` which copies the `SystemMeta::name` field so it can be accessed within a system.
# Objective `FromReflect` is a commonly used component to the Reflect API. It's required as a bound for reflecting things like `Vec<T>` and `HashMap<K, V>` and is generally useful (if not necessary) to derive on most structs or enums. Currently, however, it is not exported in `bevy_reflect`'s prelude. This means a module that uses `bevy_reflect` might have the following two lines: ```rust use bevy_reflect::prelude::*; use bevy_reflect::FromReflect; ``` Additionally, users of the full engine might need to put: ```rust use bevy::prelude::*; use bevy::reflect::FromReflect; ``` ## Solution Add `FromReflect` to the prelude of `bevy_reflect`. --- ## Changelog - Added `FromReflect` to the prelude of `bevy_reflect`
# Objective - Fixes bevyengine#5365 - The `assert!()` when the resource from `World::resource_scope` is inserted into the world is not descriptive. ## Solution - Add more context to the assert inside of `World::resource_scope` when the `FnOnce` param inserts the resource.
# Objective - Fixes bevyengine#5707 ## Solution - Used `splitn` instead of `split` to collect the rest of the string into the label after the first '#'. ---
# Objective - Morten Mikkelsen clarified that the world normal and tangent must be normalized in the vertex stage and the interpolated values must not be normalized in the fragment stage. This is in order to match the mikktspace approach exactly. - Fixes bevyengine#5514 by ensuring the tangent basis matrix (TBN) is orthonormal ## Solution - Normalize the world normal in the vertex stage and not the fragment stage - Normalize the world tangent xyz in the vertex stage - Take into account the sign of the determinant of the local to world matrix when calculating the bitangent --- ## Changelog - Fixed - scaling a model that uses normal mapping now has correct lighting again
…m the logs (bevyengine#5751) # Objective - Fixes bevyengine#5745. ## Solution - Changes the Vec3 and Quat types.
…evyengine#4452) # Objective - Fixes bevyengine#4451 ## Solution - Conditionally compile entity ID cursor as `AtomicI32` when compiling on a platform that does not support 64-bit atomics. - This effectively raises the MSRV to 1.60 as it uses a `#[cfg]` that was only just stabilized there. (should this be noted in changelog?) --- ## Changelog - Added `bevy_ecs` support for platforms without 64-bit atomic ints ## Migration Guide N/A
# Objective Very small convenience constructors added to `Size`. Does not change current examples too much but I'm working on a rather complex UI use-case where this cuts down on some extra typing :)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
still todo: use custom material vertex shader
done:
add bindable depth texture output
bind to mesh view
tested for msaa on/off, depth prepass on/off. not tested changing msaa at runtime, should be fine though.