-
-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
Merge New Renderer #3175
Merge New Renderer #3175
Commits on Jul 24, 2021
-
Configuration menu - View commit details
-
Copy full SHA for 4ac2ed7 - Browse repository at this point
Copy the full SHA 4ac2ed7View commit details -
Configuration menu - View commit details
-
Copy full SHA for cdf06ea - Browse repository at this point
Copy the full SHA cdf06eaView commit details -
Share code between passes for setting bind groups.
Renamed PipelineDescriptor to RenderPipelineDescriptor
Configuration menu - View commit details
-
Copy full SHA for a034719 - Browse repository at this point
Copy the full SHA a034719View commit details -
Configuration menu - View commit details
-
Copy full SHA for 9588bb3 - Browse repository at this point
Copy the full SHA 9588bb3View commit details -
Configuration menu - View commit details
-
Copy full SHA for 3400fb4 - Browse repository at this point
Copy the full SHA 3400fb4View commit details -
Configuration menu - View commit details
-
Copy full SHA for 579c769 - Browse repository at this point
Copy the full SHA 579c769View commit details -
StandardMaterial flat values (#3)
StandardMaterial flat values
Configuration menu - View commit details
-
Copy full SHA for 01116b1 - Browse repository at this point
Copy the full SHA 01116b1View commit details -
Configuration menu - View commit details
-
Copy full SHA for 13ca001 - Browse repository at this point
Copy the full SHA 13ca001View commit details -
Configuration menu - View commit details
-
Copy full SHA for 09043b6 - Browse repository at this point
Copy the full SHA 09043b6View commit details -
Configuration menu - View commit details
-
Copy full SHA for 3ef951d - Browse repository at this point
Copy the full SHA 3ef951dView commit details -
Port Mesh to RenderAsset, add Slab and FrameSlabMap garbage collectio…
…n for Bind Groups
Configuration menu - View commit details
-
Copy full SHA for 25de2d1 - Browse repository at this point
Copy the full SHA 25de2d1View commit details -
bevy_pbr2: Add support for most of the StandardMaterial textures (#4)
* bevy_pbr2: Add support for most of the StandardMaterial textures Normal maps are not included here as they require tangents in a vertex attribute. * bevy_pbr2: Ensure RenderCommandQueue is ready for PbrShaders init * texture_pipelined: Add a light to the scene so we can see stuff * WIP bevy_pbr2: back to front sorting hack * bevy_pbr2: Uniform control flow for texture sampling in pbr.frag From 'fintelia' on the Bevy Render Rework Round 2 discussion: "My understanding is that GPUs these days never use the "execute both branches and select the result" strategy. Rather, what they do is evaluate the branch condition on all threads of a warp, and jump over it if all of them evaluate to false. If even a single thread needs to execute the if statement body, however, then the remaining threads are paused until that is completed." * bevy_pbr2: Simplify texture and sampler names The StandardMaterial_ prefix is no longer needed * bevy_pbr2: Match default 'AmbientColor' of current bevy_pbr for now * bevy_pbr2: Convert from non-linear to linear sRGB for the color uniform * bevy_pbr2: Add pbr_pipelined example * Fix view vector in pbr frag to work in ortho * bevy_pbr2: Use a 90 degree y fov and light range projection for lights * bevy_pbr2: Add AmbientLight resource * bevy_pbr2: Convert PointLight color to linear sRGB for use in fragment shader * bevy_pbr2: pbr.frag: Rename PointLight.projection to view_projection The uniform contains the view_projection matrix so this was incorrect. * bevy_pbr2: PointLight is an OmniLight as it has a radius * bevy_pbr2: Factoring out duplicated code * bevy_pbr2: Implement RenderAsset for StandardMaterial * Remove unnecessary texture and sampler clones * fix comment formatting * remove redundant Buffer:from * Don't extract meshes when their material textures aren't ready * make missing textures in the queue step an error Co-authored-by: Aevyrie <aevyrie@gmail.com> Co-authored-by: Carter Anderson <mcanders1@gmail.com>
Configuration menu - View commit details
-
Copy full SHA for b1a91a8 - Browse repository at this point
Copy the full SHA b1a91a8View commit details -
Configuration menu - View commit details
-
Copy full SHA for 829f723 - Browse repository at this point
Copy the full SHA 829f723View commit details -
Configuration menu - View commit details
-
Copy full SHA for 61c8475 - Browse repository at this point
Copy the full SHA 61c8475View commit details -
Force main thread for prepare_windows system (#11)
Force main thread for prepare_windows system
Configuration menu - View commit details
-
Copy full SHA for 7792b29 - Browse repository at this point
Copy the full SHA 7792b29View commit details -
bevy_pbr2: Fix light uniforms
Configuration menu - View commit details
-
Copy full SHA for 3f70f92 - Browse repository at this point
Copy the full SHA 3f70f92View commit details -
Configuration menu - View commit details
-
Copy full SHA for 7c57725 - Browse repository at this point
Copy the full SHA 7c57725View commit details -
Configuration menu - View commit details
-
Copy full SHA for 5d0655f - Browse repository at this point
Copy the full SHA 5d0655fView commit details -
Configuration menu - View commit details
-
Copy full SHA for e1e4055 - Browse repository at this point
Copy the full SHA e1e4055View commit details -
Configuration menu - View commit details
-
Copy full SHA for a993719 - Browse repository at this point
Copy the full SHA a993719View commit details -
Do not queue sprites/meshes if there are no views (#13)
* bevy_sprite2/_pbr2: Do not queue sprites/meshes if there are no views
Configuration menu - View commit details
-
Copy full SHA for 858065e - Browse repository at this point
Copy the full SHA 858065eView commit details -
Configuration menu - View commit details
-
Copy full SHA for 4099ef6 - Browse repository at this point
Copy the full SHA 4099ef6View commit details -
Configuration menu - View commit details
-
Copy full SHA for bc769d9 - Browse repository at this point
Copy the full SHA bc769d9View commit details -
Configuration menu - View commit details
-
Copy full SHA for ac6b279 - Browse repository at this point
Copy the full SHA ac6b279View commit details -
* Fix writing less than the full capacity to the staging buffer * Add missing TrackedRenderPass::draw command
Configuration menu - View commit details
-
Copy full SHA for a2cac6a - Browse repository at this point
Copy the full SHA a2cac6aView commit details -
Directional light and shadow (#6)
Directional light and shadow
Configuration menu - View commit details
-
Copy full SHA for 326b206 - Browse repository at this point
Copy the full SHA 326b206View commit details -
Configuration menu - View commit details
-
Copy full SHA for 3542ddc - Browse repository at this point
Copy the full SHA 3542ddcView commit details -
Configuration menu - View commit details
-
Copy full SHA for e020501 - Browse repository at this point
Copy the full SHA e020501View commit details -
Configuration menu - View commit details
-
Copy full SHA for be8d67d - Browse repository at this point
Copy the full SHA be8d67dView commit details -
Configuration menu - View commit details
-
Copy full SHA for 7bbeb11 - Browse repository at this point
Copy the full SHA 7bbeb11View commit details -
Configuration menu - View commit details
-
Copy full SHA for 30b8324 - Browse repository at this point
Copy the full SHA 30b8324View commit details -
* 3d_scene_pipelined: Use a shallower directional light angle to provoke acne * cornell_box_pipelined: Remove bias tweaks * bevy_pbr2: Simplify shadow biases by moving them to linear depth
Configuration menu - View commit details
-
Copy full SHA for 44df4c1 - Browse repository at this point
Copy the full SHA 44df4c1View commit details -
Scale normal bias by texel size (#26)
* 3d_scene_pipelined: Use a shallower directional light angle to provoke acne * cornell_box_pipelined: Remove bias tweaks * bevy_pbr2: Simplify shadow biases by moving them to linear depth * bevy_pbr2: Do not use DepthBiasState * bevy_pbr2: Do not use bilinear filtering for sampling depth textures * pbr.wgsl: Remove unnecessary comment * bevy_pbr2: Do manual shadow map depth comparisons for more flexibility * examples: Add shadow_biases_pipelined example This is useful for stress testing biases. * bevy_pbr2: Scale the point light normal bias by the shadow map texel size This allows the normal bias to be small close to the light source where the shadow map texel to screen texel ratio is high, but is appropriately large further away from the light source where the shadow map texel can easily cover multiple screen texels. * shadow_biases_pipelined: Add support for toggling directional / point light * shadow_biases_pipelined: Cleanup * bevy_pbr2: Scale the directional light normal bias by the shadow map texel size * shadow_biases_pipelined: Fit the orthographic projection around the scene * bevy_pbr2: Directional lights should have no shadows outside their projection Before this change, sampling a fragment position from outside the ndc volume would result in the return sample being clamped to the edge in x,y or possibly always casting a shadow for fragment positions past the orthographic projection's far plane. * bevy_pbr2: Fix the default directional light normal bias * Revert "bevy_pbr2: Do manual shadow map depth comparisons for more flexibility" This reverts commit 7df1bab. * shadow_biases_pipelined: Adjust directional light normal bias in 0.1 increments * pbr.wgsl: Add a couple of clarifying comments * Revert "bevy_pbr2: Do not use bilinear filtering for sampling depth textures" This reverts commit f53baab. * shadow_biases_pipelined: Print usage to terminal
Configuration menu - View commit details
-
Copy full SHA for 618c9e9 - Browse repository at this point
Copy the full SHA 618c9e9View commit details -
Configuration menu - View commit details
-
Copy full SHA for 955c79f - Browse repository at this point
Copy the full SHA 955c79fView commit details
Commits on Jul 26, 2021
-
remove .system from pipelined code (bevyengine#2538)
Now that we have main features, lets use them!
Configuration menu - View commit details
-
Copy full SHA for 2e99d84 - Browse repository at this point
Copy the full SHA 2e99d84View commit details
Commits on Jul 28, 2021
-
Add RenderWorld to Extract step (bevyengine#2555)
Makes the "Render App World" directly available to Extract step systems as a `RenderWorld` resource. Prior to this, there was no way to directly read / write render world state during the Extract step. The only way to make changes was through Commands (which were applied at the end of the stage). ```rust // `thing` is an "app world resource". fn extract_thing(thing: Res<Thing>, mut render_world: ResMut<RenderWorld>) { render_world.insert_resource(ExtractedThing::from(thing)); } ``` RenderWorld makes a number of scenarios possible: * When an extract system does big allocations, it is now possible to reuse them across frames by retrieving old values from RenderWorld (at the cost of reduced parallelism from unique RenderWorld borrows). * Enables inserting into the same resource across multiple extract systems * Enables using past RenderWorld state to inform future extract state (this should generally be avoided) Ultimately this is just a subset of the functionality we want. In the future, it would be great to have "multi-world schedules" to enable fine grained parallelism on the render world during the extract step. But that is a research project that almost certainly won't make it into 0.6. This is a good interim solution that should easily port over to multi-world schedules if/when they land.
Configuration menu - View commit details
-
Copy full SHA for 0973d40 - Browse repository at this point
Copy the full SHA 0973d40View commit details -
move bevy_core_pipeline to its own plugin (bevyengine#2552)
This decouples the opinionated "core pipeline" from the new (less opinionated) bevy_render crate. The "core pipeline" is intended to be used by crates like bevy_sprites, bevy_pbr, bevy_ui, and 3rd party crates that extends core rendering functionality.
Configuration menu - View commit details
-
Copy full SHA for 3ec6b3f - Browse repository at this point
Copy the full SHA 3ec6b3fView commit details
Commits on Jul 29, 2021
-
bevy_render2: Log adapter info on initialization (bevyengine#2542)
It is useful to see which adapter is being used and which wgpu backend.
Configuration menu - View commit details
-
Copy full SHA for 6944d38 - Browse repository at this point
Copy the full SHA 6944d38View commit details
Commits on Jul 30, 2021
-
Fix some nightly clippy lints (bevyengine#2522)
on nightly these two clippy lints fail: - [needless_borrow](https://rust-lang.github.io/rust-clippy/master/#needless_borrow) - [unused_unit](https://rust-lang.github.io/rust-clippy/master/#unused_unit)
Configuration menu - View commit details
-
Copy full SHA for 0b800e5 - Browse repository at this point
Copy the full SHA 0b800e5View commit details -
fix nightly clippy lints (bevyengine#2568)
Fix new nightly clippy lints on `pipelined-rendering`
Configuration menu - View commit details
-
Copy full SHA for 7b336fd - Browse repository at this point
Copy the full SHA 7b336fdView commit details -
Port bevy_gltf to pipelined-rendering (bevyengine#2537)
# Objective Port bevy_gltf to the pipelined-rendering branch. ## Solution crates/bevy_gltf has been copied and pasted into pipelined/bevy_gltf2 and modifications were made to work with the pipelined-rendering branch. Notably vertex tangents and vertex colours are not supported. Co-authored-by: Carter Anderson <mcanders1@gmail.com>
Configuration menu - View commit details
-
Copy full SHA for ae4f809 - Browse repository at this point
Copy the full SHA ae4f809View commit details
Commits on Aug 4, 2021
-
Add sprite atlases into the new renderer. (bevyengine#2560)
# Objective Restore the functionality of sprite atlases in the new renderer. ### **Note:** This PR relies on bevyengine#2555 ## Solution Mostly just a copy paste of the existing sprite atlas implementation, however I unified the rendering between sprites and atlases. Co-authored-by: Carter Anderson <mcanders1@gmail.com>
Configuration menu - View commit details
-
Copy full SHA for 115b170 - Browse repository at this point
Copy the full SHA 115b170View commit details
Commits on Aug 8, 2021
-
Added StorageTextureAccess to the exposed wgpu API (bevyengine#2614)
# Objective This fixes not having access to StorageTextureAccess in the API, which is needed for using storage textures ## Solution Added it to the use in render_resource module Co-authored-by: Dimas <skythedragon@outlook.com>
Configuration menu - View commit details
-
Copy full SHA for 2f32a2a - Browse repository at this point
Copy the full SHA 2f32a2aView commit details
Commits on Aug 10, 2021
-
Add missing bytemuck feature (bevyengine#2625)
# Objective - Allow you to compile Bevy with the `bevy_sprite2` feature, but without the `bevy_pbr2` feature. - This currently fails because the `bevy_sprite2` crate does not require the `derive` feature of the `bytemuck` crate in its `Cargo.toml`, even though it is required to compile. ## Solution - Add the `derive` feature of `bytemuck` to the `bevy_sprite2` crate
Configuration menu - View commit details
-
Copy full SHA for b5b9a95 - Browse repository at this point
Copy the full SHA b5b9a95View commit details -
Re-implement Automatic Sprite Sizing (bevyengine#2613)
# Objective - Prevent the need to specify a sprite size when using the pipelined sprite renderer ## Solution - Re-introduce the sprite auto resize system from the old renderer
Configuration menu - View commit details
-
Copy full SHA for c833003 - Browse repository at this point
Copy the full SHA c833003View commit details
Commits on Aug 11, 2021
-
Added ComputePipelineDescriptor (bevyengine#2628)
# Objective Fix ComputePipelineDescriptor missing from WGPU exports ## Solution Added it to the pub use wgpu::{ ... } Co-authored-by: Dimas <skythedragon@outlook.com>
Configuration menu - View commit details
-
Copy full SHA for 5fa0b5b - Browse repository at this point
Copy the full SHA 5fa0b5bView commit details
Commits on Aug 19, 2021
-
Add ClearColor Resource to Pipelined Renderer (bevyengine#2631)
# Objective - Allow the user to set the clear color when using the pipelined renderer ## Solution - Add a `ClearColor` resource that can be added to the world to configure the clear color ## Remaining Issues Currently the `ClearColor` resource is cloned from the app world to the render world every frame. There are two ways I can think of around this: 1. Figure out why `app_world.is_resource_changed::<ClearColor>()` always returns `true` in the `extract` step and fix it so that we are only updating the resource when it changes 2. Require the users to add the `ClearColor` resource to the render sub-app instead of the parent app. This is currently sub-optimal until we have labled sub-apps, and probably a helper funciton on `App` such as `app.with_sub_app(RenderApp, |app| { ... })`. Even if we had that, I think it would be more than we want the user to have to think about. They shouldn't have to know about the render sub-app I don't think. I think the first option is the best, but I could really use some help figuring out the nuance of why `is_resource_changed` is always returning true in that context.
Configuration menu - View commit details
-
Copy full SHA for 3faca93 - Browse repository at this point
Copy the full SHA 3faca93View commit details
Commits on Aug 23, 2021
-
bevy_render2: Make default near plane more sensible at 0.1 (bevyengin…
…e#2703) # Objective The default perspective projection near plane being at 1 unit feels very far away if one considers units to directly map to real world units such as metres. Not being able to see anything that is closer than 1m is unnecessarily limiting. Using a default of 0.1 makes more sense as it is difficult to even focus on things closer than 10cm in the real world. ## Solution - Changed the default perspective projection near plane to 0.1.
Configuration menu - View commit details
-
Copy full SHA for 993ce84 - Browse repository at this point
Copy the full SHA 993ce84View commit details -
bevy_pbr2: Improve lighting units and documentation (bevyengine#2704)
# Objective A question was raised on Discord about the units of the `PointLight` `intensity` member. After digging around in the bevy_pbr2 source code and [Google Filament documentation](https://google.github.io/filament/Filament.html#mjx-eqn-pointLightLuminousPower) I discovered that the intention by Filament was that the 'intensity' value for point lights would be in lumens. This makes a lot of sense as these are quite relatable units given basically all light bulbs I've seen sold over the past years are rated in lumens as people move away from thinking about how bright a bulb is relative to a non-halogen incandescent bulb. However, it seems that the derivation of the conversion between luminous power (lumens, denoted `Φ` in the Filament formulae) and luminous intensity (lumens per steradian, `I` in the Filament formulae) was missed and I can see why as it is tucked right under equation 58 at the link above. As such, while the formula states that for a point light, `I = Φ / 4 π` we have been using `intensity` as if it were luminous intensity `I`. Before this PR, the intensity field is luminous intensity in lumens per steradian. After this PR, the intensity field is luminous power in lumens, [as suggested by Filament](https://google.github.io/filament/Filament.html#table_lighttypesunits) (unfortunately the link jumps to the table's caption so scroll up to see the actual table). I appreciate that it may be confusing to call this an intensity, but I think this is intended as more of a non-scientific, human-relatable general term with a bit of hand waving so that most light types can just have an intensity field and for most of them it works in the same way or at least with some relatable value. I'm inclined to think this is reasonable rather than throwing terms like luminous power, luminous intensity, blah at users. ## Solution - Documented the `PointLight` `intensity` member as 'luminous power' in units of lumens. - Added a table of examples relating from various types of household lighting to lumen values. - Added in the mapping from luminous power to luminous intensity when premultiplying the intensity into the colour before it is made into a graphics uniform. - Updated the documentation in `pbr.wgsl` to clarify the earlier confusion about the missing `/ 4 π`. - Bumped the intensity of the point lights in `3d_scene_pipelined` to 1600 lumens. Co-authored-by: Carter Anderson <mcanders1@gmail.com>
Configuration menu - View commit details
-
Copy full SHA for c3d3ae7 - Browse repository at this point
Copy the full SHA c3d3ae7View commit details
Commits on Aug 24, 2021
-
Implement Sub-App Labels (bevyengine#2695)
This is a rather simple but wide change, and it involves adding a new `bevy_app_macros` crate. Let me know if there is a better way to do any of this! --- # Objective - Allow adding and accessing sub-apps by using a label instead of an index ## Solution - Migrate the bevy label implementation and derive code to the `bevy_utils` and `bevy_macro_utils` crates and then add a new `SubAppLabel` trait to the `bevy_app` crate that is used when adding or getting a sub-app from an app.
Configuration menu - View commit details
-
Copy full SHA for e290a7e - Browse repository at this point
Copy the full SHA e290a7eView commit details -
Sub app label changes (bevyengine#2717)
Makes some tweaks to the SubApp labeling introduced in bevyengine#2695: * Ergonomics improvements * Removes unnecessary allocation when retrieving subapp label * Removes the newly added "app macros" crate in favor of bevy_derive * renamed RenderSubApp to RenderApp @zicklag (for reference)
Configuration menu - View commit details
-
Copy full SHA for 9898469 - Browse repository at this point
Copy the full SHA 9898469View commit details
Commits on Aug 25, 2021
-
bevy_pbr2: Add support for configurable shadow map sizes (bevyengine#…
…2700) # Objective Add support for configurable shadow map sizes ## Solution - Add `DirectionalLightShadowMap` and `PointLightShadowMap` resources, which just have size members, to the app world, and add `Extracted*` counterparts to the render world - Use the configured sizes when rendering shadow maps - Default sizes remain the same - 4096 for directional light shadow maps, 1024 for point light shadow maps (which are cube maps so 6 faces at 1024x1024 per light)
Configuration menu - View commit details
-
Copy full SHA for f368bf7 - Browse repository at this point
Copy the full SHA f368bf7View commit details -
bevy_pbr2: Add support for not casting/receiving shadows (bevyengine#…
…2726) # Objective Allow marking meshes as not casting / receiving shadows. ## Solution - Added `NotShadowCaster` and `NotShadowReceiver` zero-sized type components. - Extract these components into `bool`s in `ExtractedMesh` - Only generate `DrawShadowMesh` `Drawable`s for meshes _without_ `NotShadowCaster` - Add a `u32` bit `flags` member to `MeshUniform` with one flag indicating whether the mesh is a shadow receiver - If a mesh does _not_ have the `NotShadowReceiver` component, then it is a shadow receiver, and so the bit in the `MeshUniform` is set, otherwise it is not set. - Added an example illustrating the functionality. NOTE: I wanted to have the default state of a mesh as being a shadow caster and shadow receiver, hence the `Not*` components. However, I am on the fence about this. I don't want to have a negative performance impact, nor have people wondering why their custom meshes don't have shadows because they forgot to add `ShadowCaster` and `ShadowReceiver` components, but I also really don't like the double negatives the `Not*` approach incurs. What do you think? Co-authored-by: Carter Anderson <mcanders1@gmail.com>
Configuration menu - View commit details
-
Copy full SHA for f4aa328 - Browse repository at this point
Copy the full SHA f4aa328View commit details -
Pipelined separate shadow vertex shader (bevyengine#2727)
# Objective - Avoid unnecessary work in the vertex shader of the numerous shadow passes - Have the natural order of bind groups in the pbr shader: view, material, mesh ## Solution - Separate out the vertex stage of pbr.wgsl into depth.wgsl - Remove the unnecessary calculation of uv and normal, as well as removing the unnecessary vertex inputs and outputs - Use the depth.wgsl for shadow passes - Reorder the bind groups in pbr.wgsl and PbrShaders to be 0 - view, 1 - material, 2 - mesh in decreasing order of rebind frequency
Configuration menu - View commit details
-
Copy full SHA for dd32cd0 - Browse repository at this point
Copy the full SHA dd32cd0View commit details
Commits on Aug 26, 2021
-
Remove Need for Sprite Size Sync System (bevyengine#2632)
# Objective - Prevent the need to have a system that synchronizes sprite sizes with their images ## Solution - Read the sprite size from the image asset when rendering the sprite - Replace the `size` and `resize_mode` fields of `Sprite` with a `custom_size: Option<Vec2>` that will modify the sprite's rendered size to be different than the image size, but only if it is `Some(Vec2)`
Configuration menu - View commit details
-
Copy full SHA for cea7db1 - Browse repository at this point
Copy the full SHA cea7db1View commit details
Commits on Aug 27, 2021
-
Use the infinite reverse right-handed perspective projection (bevyeng…
…ine#2543) # Objective Forward perspective projections have poor floating point precision distribution over the depth range. Reverse projections fair much better, and instead of having to have a far plane, with the reverse projection, using an infinite far plane is not a problem. The infinite reverse perspective projection has become the industry standard. The renderer rework is a great time to migrate to it. ## Solution All perspective projections, including point lights, have been moved to using `glam::Mat4::perspective_infinite_reverse_rh()` and so have no far plane. As various depth textures are shared between orthographic and perspective projections, a quirk of this PR is that the near and far planes of the orthographic projection are swapped when the Mat4 is computed. This has no impact on 2D/3D orthographic projection usage, and provides consistency in shaders, texture clear values, etc. throughout the codebase. ## Known issues For some reason, when looking along -Z, all geometry is black. The camera can be translated up/down / strafed left/right and geometry will still be black. Moving forward/backward or rotating the camera away from looking exactly along -Z causes everything to work as expected. I have tried to debug this issue but both in macOS and Windows I get crashes when doing pixel debugging. If anyone could reproduce this and debug it I would be very grateful. Otherwise I will have to try to debug it further without pixel debugging, though the projections and such all looked fine to me.
Configuration menu - View commit details
-
Copy full SHA for 045f324 - Browse repository at this point
Copy the full SHA 045f324View commit details
Commits on Aug 31, 2021
-
Add Deref implementation for ComputePipeline (bevyengine#2759)
# Objective Fixes a usability problem where the user is unable to use their reference to a ComputePipeline in their compute pass. ## Solution Implements Deref, allowing the user to obtain the reference to the underlying wgpu::ComputePipeline
Configuration menu - View commit details
-
Copy full SHA for 59bfbd3 - Browse repository at this point
Copy the full SHA 59bfbd3View commit details
Commits on Sep 14, 2021
-
Add upstream bevy_ecs and prepare for custom-shaders merge (bevyengin…
…e#2815) This updates the `pipelined-rendering` branch to use the latest `bevy_ecs` from `main`. This accomplishes a couple of goals: 1. prepares for upcoming `custom-shaders` branch changes, which were what drove many of the recent bevy_ecs changes on `main` 2. prepares for the soon-to-happen merge of `pipelined-rendering` into `main`. By including bevy_ecs changes now, we make that merge simpler / easier to review. I split this up into 3 commits: 1. **add upstream bevy_ecs**: please don't bother reviewing this content. it has already received thorough review on `main` and is a literal copy/paste of the relevant folders (the old folders were deleted so the directories are literally exactly the same as `main`). 2. **support manual buffer application in stages**: this is used to enable the Extract step. we've already reviewed this once on the `pipelined-rendering` branch, but its worth looking at one more time in the new context of (1). 3. **support manual archetype updates in QueryState**: same situation as (2).
Configuration menu - View commit details
-
Copy full SHA for 11b4120 - Browse repository at this point
Copy the full SHA 11b4120View commit details
Commits on Sep 16, 2021
-
Expose wgpu's StencilOperation with bevy (bevyengine#2819)
# Objective Bevy should expose all wgpu types needed for building rendering pipelines. Closes bevyengine#2818 ## Solution Add wgpu's StencilOperation to bevy_render2::render_resource's export.
Configuration menu - View commit details
-
Copy full SHA for 52fd626 - Browse repository at this point
Copy the full SHA 52fd626View commit details -
fix
Default
implementation ofImage
so that size and data match (b……evyengine#2833) Before using this image resulted in an `Error in Queue::write_texture: copy of 0..4 would end up overrunning the bounds of the Source buffer of size 0`
Configuration menu - View commit details
-
Copy full SHA for 1e03a97 - Browse repository at this point
Copy the full SHA 1e03a97View commit details
Commits on Sep 23, 2021
-
Modular Rendering (bevyengine#2831)
This changes how render logic is composed to make it much more modular. Previously, all extraction logic was centralized for a given "type" of rendered thing. For example, we extracted meshes into a vector of ExtractedMesh, which contained the mesh and material asset handles, the transform, etc. We looked up bindings for "drawn things" using their index in the `Vec<ExtractedMesh>`. This worked fine for built in rendering, but made it hard to reuse logic for "custom" rendering. It also prevented us from reusing things like "extracted transforms" across contexts. To make rendering more modular, I made a number of changes: * Entities now drive rendering: * We extract "render components" from "app components" and store them _on_ entities. No more centralized uber lists! We now have true "ECS-driven rendering" * To make this perform well, I implemented bevyengine#2673 in upstream Bevy for fast batch insertions into specific entities. This was merged into the `pipelined-rendering` branch here: bevyengine#2815 * Reworked the `Draw` abstraction: * Generic `PhaseItems`: each draw phase can define its own type of "rendered thing", which can define its own "sort key" * Ported the 2d, 3d, and shadow phases to the new PhaseItem impl (currently Transparent2d, Transparent3d, and Shadow PhaseItems) * `Draw` trait and and `DrawFunctions` are now generic on PhaseItem * Modular / Ergonomic `DrawFunctions` via `RenderCommands` * RenderCommand is a trait that runs an ECS query and produces one or more RenderPass calls. Types implementing this trait can be composed to create a final DrawFunction. For example the DrawPbr DrawFunction is created from the following DrawCommand tuple. Const generics are used to set specific bind group locations: ```rust pub type DrawPbr = ( SetPbrPipeline, SetMeshViewBindGroup<0>, SetStandardMaterialBindGroup<1>, SetTransformBindGroup<2>, DrawMesh, ); ``` * The new `custom_shader_pipelined` example illustrates how the commands above can be reused to create a custom draw function: ```rust type DrawCustom = ( SetCustomMaterialPipeline, SetMeshViewBindGroup<0>, SetTransformBindGroup<2>, DrawMesh, ); ``` * ExtractComponentPlugin and UniformComponentPlugin: * Simple, standardized ways to easily extract individual components and write them to GPU buffers * Ported PBR and Sprite rendering to the new primitives above. * Removed staging buffer from UniformVec in favor of direct Queue usage * Makes UniformVec much easier to use and more ergonomic. Completely removes the need for custom render graph nodes in these contexts (see the PbrNode and view Node removals and the much simpler call patterns in the relevant Prepare systems). * Added a many_cubes_pipelined example to benchmark baseline 3d rendering performance and ensure there were no major regressions during this port. Avoiding regressions was challenging given that the old approach of extracting into centralized vectors is basically the "optimal" approach. However thanks to a various ECS optimizations and render logic rephrasing, we pretty much break even on this benchmark! * Lifetimeless SystemParams: this will be a bit divisive, but as we continue to embrace "trait driven systems" (ex: ExtractComponentPlugin, UniformComponentPlugin, DrawCommand), the ergonomics of `(Query<'static, 'static, (&'static A, &'static B, &'static)>, Res<'static, C>)` were getting very hard to bear. As a compromise, I added "static type aliases" for the relevant SystemParams. The previous example can now be expressed like this: `(SQuery<(Read<A>, Read<B>)>, SRes<C>)`. If anyone has better ideas / conflicting opinions, please let me know! * RunSystem trait: a way to define Systems via a trait with a SystemParam associated type. This is used to implement the various plugins mentioned above. I also added SystemParamItem and QueryItem type aliases to make "trait stye" ecs interactions nicer on the eyes (and fingers). * RenderAsset retrying: ensures that render assets are only created when they are "ready" and allows us to create bind groups directly inside render assets (which significantly simplified the StandardMaterial code). I think ultimately we should swap this out on "asset dependency" events to wait for dependencies to load, but this will require significant asset system changes. * Updated some built in shaders to account for missing MeshUniform fields
Configuration menu - View commit details
-
Copy full SHA for 08969a2 - Browse repository at this point
Copy the full SHA 08969a2View commit details -
Fix window size change panic (bevyengine#2858)
# Objective Using fullscreen or trying to resize a window caused a panic. Fix that. ## Solution - Don't wholesale overwrite the ExtractedWindows resource when extracting windows - This could cause an accumulation of unused windows that are holding onto swap chain frames? - Check the if width and/or height changed since the last frame - If the size changed, recreate the swap chain - Ensure dimensions are >= 1 to avoid panics due to any dimension being 0
Configuration menu - View commit details
-
Copy full SHA for fb33d59 - Browse repository at this point
Copy the full SHA fb33d59View commit details
Commits on Sep 28, 2021
-
Add set_stencil_reference to TrackedRenderPass (bevyengine#2885)
`TrackedRenderPass` is a wrapper around wgpu's `RenderPass` and should expose needed methods such as `set_stencil_reference`.
Configuration menu - View commit details
-
Copy full SHA for d2bba8c - Browse repository at this point
Copy the full SHA d2bba8cView commit details
Commits on Oct 2, 2021
-
bevy_render2: Add tracing spans around render subapp and stages (bevy…
…engine#2907) Add tracing spans around the renderer subapp and render stages in bevy_render2 to allow profiling / visualisation of stages. From: <img width="1181" alt="Screenshot 2021-10-02 122336" src="https://user-images.githubusercontent.com/302146/135712361-8aec28ae-0f1e-4c27-9b6e-ca5e5f45d6b9.png"> To: <img width="1229" alt="Screenshot 2021-10-02 122509" src="https://user-images.githubusercontent.com/302146/135712365-6414d424-4e15-4265-9952-483876da9f9a.png">
Configuration menu - View commit details
-
Copy full SHA for 44ed7e3 - Browse repository at this point
Copy the full SHA 44ed7e3View commit details
Commits on Oct 3, 2021
-
Apply labels to wgpu resources for improved debugging/profiling (bevy…
…engine#2912) # Objective $subj. All of these names show up in external tools when debugging/profiling frames, which is super useful.
Configuration menu - View commit details
-
Copy full SHA for 0eb11df - Browse repository at this point
Copy the full SHA 0eb11dfView commit details
Commits on Oct 6, 2021
-
removed unused RenderResourceId and SwapChainFrame (bevyengine#2890)
# Objective - removed unused RenderResourceId and SwapChainFrame (already unified with TextureView) - added deref to BindGroup, this makes conversion to wgpu::BindGroup easier ## Solution - cleans up the API
Kurt Kühnert committedOct 6, 2021 Configuration menu - View commit details
-
Copy full SHA for bf19ddf - Browse repository at this point
Copy the full SHA bf19ddfView commit details
Commits on Oct 7, 2021
-
Use RenderQueue in BufferVec (bevyengine#2847)
Using RenderQueue in BufferVec allows removal of the staging buffer entirely, as well as removal of the SpriteNode. Co-authored-by: Carter Anderson <mcanders1@gmail.com>
Configuration menu - View commit details
-
Copy full SHA for 40fccd2 - Browse repository at this point
Copy the full SHA 40fccd2View commit details
Commits on Oct 8, 2021
-
Upgrade to wgpu 0.11 (bevyengine#2933)
Upgrades both the old and new renderer to wgpu 0.11 (and naga 0.7). This builds on @zicklag's work here bevyengine#2556. Co-authored-by: Carter Anderson <mcanders1@gmail.com>
Configuration menu - View commit details
-
Copy full SHA for 43e8a15 - Browse repository at this point
Copy the full SHA 43e8a15View commit details
Commits on Oct 15, 2021
-
Fix CI for android (bevyengine#2971)
# Objective The update to wgpu 0.11 broke CI for android. This was due to a confusion between `bevy::render::ShaderStage` and `wgpu::ShaderStage`. ## Solution Revert the incorrect change
Configuration menu - View commit details
-
Copy full SHA for b13357e - Browse repository at this point
Copy the full SHA b13357eView commit details -
fix window resize after wgpu 0.11 upgrade (bevyengine#2953)
The fix originally got introduced in [bevyengine#2858](https://github.com/bevyengine/bevy/pull/2858/files#diff-0f34eeda7ac2fe1f9e9b27de92d9290e0b360ffa6f032770aff22b5fef4eaa63R137-R143) but got lost in the upgrade to wgpu 0.11 at bevyengine#2933
Configuration menu - View commit details
-
Copy full SHA for 432ce72 - Browse repository at this point
Copy the full SHA 432ce72View commit details
Commits on Oct 25, 2021
-
Update for edition 2021 (bevyengine#2997)
# Objective - update for Edition 2021 ## Solution - remove the `resolver = "2"` - update for https://doc.rust-lang.org/edition-guide/rust-2021/reserving-syntax.html by adding a few ` `
Configuration menu - View commit details
-
Copy full SHA for 2f4bcc5 - Browse repository at this point
Copy the full SHA 2f4bcc5View commit details -
Fix custom_shader_pipelined example shader (bevyengine#2992)
## Objective Looking though the new pipelined example I stumbled on an issue with the example shader : ``` Oct 20 12:38:44.891 INFO bevy_render2::renderer: AdapterInfo { name: "Intel(R) UHD Graphics 620 (KBL GT2)", vendor: 32902, device: 22807, device_type: IntegratedGpu, backend: Vulkan } Oct 20 12:38:44.894 INFO naga::back::spv::writer: Skip function Some("fetch_point_shadow") Oct 20 12:38:44.894 INFO naga::back::spv::writer: Skip function Some("fetch_directional_shadow") Oct 20 12:38:44.898 ERROR wgpu::backend::direct: Handling wgpu errors as fatal by default thread 'main' panicked at 'wgpu error: Validation Error Caused by: In Device::create_shader_module Global variable [1] 'view' is invalid Type isn't compatible with the storage class ``` ## Solution added `<uniform>` here and there. Note : my current mastery of shaders is about 2 days old, so this still kinda look likes wizardry
Nibor62 committedOct 25, 2021 Configuration menu - View commit details
-
Copy full SHA for 7b686b5 - Browse repository at this point
Copy the full SHA 7b686b5View commit details -
Switched the TODO comment in image_texture_conversion.rs (bevyengine#…
…2981) # Objective The current TODO comment is out of date ## Solution I switched up the comment Co-authored-by: William Batista <45850508+billyb2@users.noreply.github.com>
Configuration menu - View commit details
-
Copy full SHA for 9f47697 - Browse repository at this point
Copy the full SHA 9f47697View commit details
Commits on Oct 28, 2021
-
Pipeline Specialization, Shader Assets, and Shader Preprocessing (bev…
…yengine#3031) ## New Features This adds the following to the new renderer: * **Shader Assets** * Shaders are assets again! Users no longer need to call `include_str!` for their shaders * Shader hot-reloading * **Shader Defs / Shader Preprocessing** * Shaders now support `# ifdef NAME`, `# ifndef NAME`, and `# endif` preprocessor directives * **Bevy RenderPipelineDescriptor and RenderPipelineCache** * Bevy now provides its own `RenderPipelineDescriptor` and the wgpu version is now exported as `RawRenderPipelineDescriptor`. This allows users to define pipelines with `Handle<Shader>` instead of needing to manually compile and reference `ShaderModules`, enables passing in shader defs to configure the shader preprocessor, makes hot reloading possible (because the descriptor can be owned and used to create new pipelines when a shader changes), and opens the doors to pipeline specialization. * The `RenderPipelineCache` now handles compiling and re-compiling Bevy RenderPipelineDescriptors. It has internal PipelineLayout and ShaderModule caches. Users receive a `CachedPipelineId`, which can be used to look up the actual `&RenderPipeline` during rendering. * **Pipeline Specialization** * This enables defining per-entity-configurable pipelines that specialize on arbitrary custom keys. In practice this will involve specializing based on things like MSAA values, Shader Defs, Bind Group existence, and Vertex Layouts. * Adds a `SpecializedPipeline` trait and `SpecializedPipelines<MyPipeline>` resource. This is a simple layer that generates Bevy RenderPipelineDescriptors based on a custom key defined for the pipeline. * Specialized pipelines are also hot-reloadable. * This was the result of experimentation with two different approaches: 1. **"generic immediate mode multi-key hash pipeline specialization"** * breaks up the pipeline into multiple "identities" (the core pipeline definition, shader defs, mesh layout, bind group layout). each of these identities has its own key. looking up / compiling a specific version of a pipeline requires composing all of these keys together * the benefit of this approach is that it works for all pipelines / the pipeline is fully identified by the keys. the multiple keys allow pre-hashing parts of the pipeline identity where possible (ex: pre compute the mesh identity for all meshes) * the downside is that any per-entity data that informs the values of these keys could require expensive re-hashes. computing each key for each sprite tanked bevymark performance (sprites don't actually need this level of specialization yet ... but things like pbr and future sprite scenarios might). * this is the approach rafx used last time i checked 2. **"custom key specialization"** * Pipelines by default are not specialized * Pipelines that need specialization implement a SpecializedPipeline trait with a custom key associated type * This allows specialization keys to encode exactly the amount of information required (instead of needing to be a combined hash of the entire pipeline). Generally this should fit in a small number of bytes. Per-entity specialization barely registers anymore on things like bevymark. It also makes things like "shader defs" way cheaper to hash because we can use context specific bitflags instead of strings. * Despite the extra trait, it actually generally makes pipeline definitions + lookups simpler: managing multiple keys (and making the appropriate calls to manage these keys) was way more complicated. * I opted for custom key specialization. It performs better generally and in my opinion is better UX. Fortunately the way this is implemented also allows for custom caches as this all builds on a common abstraction: the RenderPipelineCache. The built in custom key trait is just a simple / pre-defined way to interact with the cache ## Callouts * The SpecializedPipeline trait makes it easy to inherit pipeline configuration in custom pipelines. The changes to `custom_shader_pipelined` and the new `shader_defs_pipelined` example illustrate how much simpler it is to define custom pipelines based on the PbrPipeline. * The shader preprocessor is currently pretty naive (it just uses regexes to process each line). Ultimately we might want to build a more custom parser for more performance + better error handling, but for now I'm happy to optimize for "easy to implement and understand". ## Next Steps * Port compute pipelines to the new system * Add more preprocessor directives (else, elif, import) * More flexible vertex attribute specialization / enable cheaply specializing on specific mesh vertex layouts
Configuration menu - View commit details
-
Copy full SHA for 015617a - Browse repository at this point
Copy the full SHA 015617aView commit details -
Add support for IndexFormat::Uint16 (bevyengine#2990)
# Objective while testing wgpu/WebGL on mobile GPU I've noticed bevy always forces vertex index format to 32bit (and ignores mesh settings). ## Solution the solution is to pass proper vertex index format in GpuIndexInfo to render_pass
Configuration menu - View commit details
-
Copy full SHA for dacc9d0 - Browse repository at this point
Copy the full SHA dacc9d0View commit details -
use correct size of pixel instead of 4 (bevyengine#2977)
# Objective - Fixes bevyengine#2919 - Initial pixel was hard coded and not dependent on texture format - Replace bevyengine#2920 as I noticed this needed to be done also on pipeline rendering branch ## Solution - Replace the hard coded pixel with one using the texture pixel size
Configuration menu - View commit details
-
Copy full SHA for a2ea927 - Browse repository at this point
Copy the full SHA a2ea927View commit details
Commits on Oct 29, 2021
-
WebGL2 support (bevyengine#3039)
# Objective Make possible to use wgpu gles backend on in the browser (wasm32 + WebGL2). ## Solution It is built on top of old @cart patch initializing windows before wgpu. Also: - initializes wgpu with `Backends::GL` and proper `wgpu::Limits` on wasm32 - changes default texture format to `wgpu::TextureFormat::Rgba8UnormSrgb` Co-authored-by: Mariusz Kryński <mrk@sed.pl>
Configuration menu - View commit details
-
Copy full SHA for 7d932ac - Browse repository at this point
Copy the full SHA 7d932acView commit details -
Add MSAA to new renderer (bevyengine#3042)
Adds support for MSAA to the new renderer. This is done using the new [pipeline specialization](bevyengine#3031) support to specialize on sample count. This is an alternative implementation to bevyengine#2541 that cuts out the need for complicated render graph edge management by moving the relevant target information into View entities. This reuses @superdump's clever MSAA bitflag range code from bevyengine#2541. Note that wgpu currently only supports 1 or 4 samples due to those being the values supported by WebGPU. However they do plan on exposing ways to [enable/query for natively supported sample counts](gfx-rs/wgpu#1832). When this happens we should integrate
Configuration menu - View commit details
-
Copy full SHA for c5af133 - Browse repository at this point
Copy the full SHA c5af133View commit details
Commits on Nov 1, 2021
-
change texture atlas sprite indexing to usize (bevyengine#2887)
Per this comment bevyengine#2864 (comment), I have done a pass at changing all the public facing indexes for `TextureAtlas` to usize.
Configuration menu - View commit details
-
Copy full SHA for 95032a3 - Browse repository at this point
Copy the full SHA 95032a3View commit details
Commits on Nov 3, 2021
-
MSAA example (bevyengine#3049)
Add an example that demonstrates the difference between no MSAA and MSAA 4x. This is also useful for testing panics when resizing the window using MSAA. This is on top of bevyengine#3042 . Co-authored-by: Carter Anderson <mcanders1@gmail.com>
Configuration menu - View commit details
-
Copy full SHA for 2f22f5c - Browse repository at this point
Copy the full SHA 2f22f5cView commit details
Commits on Nov 4, 2021
-
Sprite Batching (bevyengine#3060)
This implements the following: * **Sprite Batching**: Collects sprites in a vertex buffer to draw many sprites with a single draw call. Sprites are batched by their `Handle<Image>` within a specific z-level. When possible, sprites are opportunistically batched _across_ z-levels (when no sprites with a different texture exist between two sprites with the same texture on different z levels). With these changes, I can now get ~130,000 sprites at 60fps on the `bevymark_pipelined` example. * **Sprite Color Tints**: The `Sprite` type now has a `color` field. Non-white color tints result in a specialized render pipeline that passes the color in as a vertex attribute. I chose to specialize this because passing vertex colors has a measurable price (without colors I get ~130,000 sprites on bevymark, with colors I get ~100,000 sprites). "Colored" sprites cannot be batched with "uncolored" sprites, but I think this is fine because the chance of a "colored" sprite needing to batch with other "colored" sprites is generally probably way higher than an "uncolored" sprite needing to batch with a "colored" sprite. * **Sprite Flipping**: Sprites can be flipped on their x or y axis using `Sprite::flip_x` and `Sprite::flip_y`. This is also true for `TextureAtlasSprite`. * **Simpler BufferVec/UniformVec/DynamicUniformVec Clearing**: improved the clearing interface by removing the need to know the size of the final buffer at the initial clear. ![image](https://user-images.githubusercontent.com/2694663/140001821-99be0d96-025d-489e-9bfa-ba19c1dc9548.png) Note that this moves sprites away from entity-driven rendering and back to extracted lists. We _could_ use entities here, but it necessitates that an intermediate list is allocated / populated to collect and sort extracted sprites. This redundant copy, combined with the normal overhead of spawning extracted sprite entities, brings bevymark down to ~80,000 sprites at 60fps. I think making sprites a bit more fixed (by default) is worth it. I view this as acceptable because batching makes normal entity-driven rendering pretty useless anyway (and we would want to batch most custom materials too). We can still support custom shaders with custom bindings, we'll just need to define a specific interface for it.
Configuration menu - View commit details
-
Copy full SHA for 8548770 - Browse repository at this point
Copy the full SHA 8548770View commit details -
Support for normal maps including from glTF models (bevyengine#2741)
# Objective - Support tangent vertex attributes, and normal maps - Support loading these from glTF models ## Solution - Make two pipelines in both the shadow and pbr passes, one for without normal maps, one for with normal maps - Select the correct pipeline to bind based on the presence of the normal map texture - Share the vertex attribute layout between shadow and pbr passes - Refactored pbr.wgsl to share a bunch of common code between the normal map and non-normal map entry points. I tried to do this in a way that will allow custom shader reuse. Co-authored-by: Carter Anderson <mcanders1@gmail.com>
Configuration menu - View commit details
-
Copy full SHA for 09706cd - Browse repository at this point
Copy the full SHA 09706cdView commit details
Commits on Nov 6, 2021
-
Add System Command apply and RenderGraph node spans (bevyengine#3069)
This fills in most of the gaps in tracing visualizations and should help with discovering bottlenecks.
Configuration menu - View commit details
-
Copy full SHA for fde5d2f - Browse repository at this point
Copy the full SHA fde5d2fView commit details
Commits on Nov 7, 2021
-
Frustum culling (bevyengine#2861)
# Objective Implement frustum culling for much better performance on more complex scenes. With the Amazon Lumberyard Bistro scene, I was getting roughly 15fps without frustum culling and 60+fps with frustum culling on a MacBook Pro 16 with i9 9980HK 8c/16t CPU and Radeon Pro 5500M. macOS does weird things with vsync so even though vsync was off, it really looked like sometimes other applications or the desktop window compositor were interfering, but the difference could be even more as I even saw up to 90+fps sometimes. ## Solution - Until the bevyengine/rfcs#12 RFC is completed, I wanted to implement at least some of the bounding volume functionality we needed to be able to unblock a bunch of rendering features and optimisations such as frustum culling, fitting the directional light orthographic projection to the relevant meshes in the view, clustered forward rendering, etc. - I have added `Aabb`, `Frustum`, and `Sphere` types with only the necessary intersection tests for the algorithms used. I also added `CubemapFrusta` which contains a `[Frustum; 6]` and can be used by cube maps such as environment maps, and point light shadow maps. - I did do a bit of benchmarking and optimisation on the intersection tests. I compared the [rafx parallel-comparison bitmask approach](https://github.com/aclysma/rafx/blob/c91bd5fcfdfa3f4d1b43507c32d84b94ffdf1b2e/rafx-visibility/src/geometry/frustum.rs#L64-L92) with a naïve loop that has an early-out in case of a bounding volume being outside of any one of the `Frustum` planes and found them to be very similar, so I chose the simpler and more readable option. I also compared using Vec3 and Vec3A and it turned out that promoting Vec3s to Vec3A improved performance of the culling significantly due to Vec3A operations using SIMD optimisations where Vec3 uses plain scalar operations. - When loading glTF models, the vertex attribute accessors generally store the minimum and maximum values, which allows for adding AABBs to meshes loaded from glTF for free. - For meshes without an AABB (`PbrBundle` deliberately does not have an AABB by default), a system is executed that scans over the vertex positions to find the minimum and maximum values along each axis. This is used to construct the AABB. - The `Frustum::intersects_obb` and `Sphere::insersects_obb` algorithm is from Foundations of Game Engine Development 2: Rendering by Eric Lengyel. There is no OBB type, yet, rather an AABB and the model matrix are passed in as arguments. This calculates a 'relative radius' of the AABB with respect to the plane normal (the plane normal in the Sphere case being something I came up with as the direction pointing from the centre of the sphere to the centre of the AABB) such that it can then do a sphere-sphere intersection test in practice. - `RenderLayers` were copied over from the current renderer. - `VisibleEntities` was copied over from the current renderer and a `CubemapVisibleEntities` was added to support `PointLight`s for now. `VisibleEntities` are added to views (cameras and lights) and contain a `Vec<Entity>` that is populated by culling/visibility systems that run in PostUpdate of the app world, and are iterated over in the render world for, for example, queuing up meshes to be drawn by lights for shadow maps and the main pass for cameras. - `Visibility` and `ComputedVisibility` components were added. The `Visibility` component is user-facing so that, for example, the entity can be marked as not visible in an editor. `ComputedVisibility` on the other hand is the result of the culling/visibility systems and takes `Visibility` into account. So if an entity is marked as not being visible in its `Visibility` component, that will skip culling/visibility intersection tests and just mark the `ComputedVisibility` as false. - The `ComputedVisibility` is used to decide which meshes to extract. - I had to add a way to get the far plane from the `CameraProjection` in order to define an explicit far frustum plane for culling. This should perhaps be optional as it is not always desired and in that case, testing 5 planes instead of 6 is a performance win. I think that's about all. I discussed some of the design with @cart on Discord already so hopefully it's not too far from being mergeable. It works well at least. 😄
Configuration menu - View commit details
-
Copy full SHA for bc5916c - Browse repository at this point
Copy the full SHA bc5916cView commit details
Commits on Nov 10, 2021
-
fix tracing dependencies to before 0.3 update (bevyengine#3103)
same as bevyengine#3102 on branch pipelined-rendering
Configuration menu - View commit details
-
Copy full SHA for db35ffb - Browse repository at this point
Copy the full SHA db35ffbView commit details
Commits on Nov 11, 2021
-
Fix MIME type support for glTF buffer Data URIs (pipelined) (bevyengi…
…ne#3106) Apply bevyengine#3101 on top of the `pipelined-rendering` branch, as requested by @cart in bevyengine#3101 (comment) # Objective - The glTF 2.0 spec requires that Data URIs use one of two valid MIME types. `bevy_gltf2` only supports one of these. - See: - https://www.khronos.org/registry/glTF/specs/2.0/glTF-2.0.html#_media_type_registrations - https://www.khronos.org/registry/glTF/specs/2.0/glTF-2.0.html#file-extensions-and-media-types - https://www.khronos.org/registry/glTF/specs/2.0/glTF-2.0.html#binary-data-storage > Buffer data **MAY** alternatively be embedded in the glTF file via `data:` URI with base64 encoding. When `data:` URI is used for buffer storage, its mediatype field **MUST** be set to `application/octet-stream` or `application/gltf-buffer`. (Emphasis in original.) ## Solution - Check for both MIME types.
Configuration menu - View commit details
-
Copy full SHA for e375add - Browse repository at this point
Copy the full SHA e375addView commit details
Commits on Nov 12, 2021
-
Update vendored Crevice to 0.8.0 + PR for arrays (bevyengine#3059)
# Objective - Update vendor crevice to have the latest update from crevice 0.8.0 - Using https://github.com/ElectronicRU/crevice/tree/arrays which has the changes to make arrays work ## Solution - Also updated glam and hexasphere to only have one version of glam - From the original PR, using crevice to write GLSL code containing arrays would probably not work but it's not something used by Bevy
Configuration menu - View commit details
-
Copy full SHA for 290b7dd - Browse repository at this point
Copy the full SHA 290b7ddView commit details -
EntityRenderCommand and PhaseItemRenderCommand (bevyengine#3111)
Adds new `EntityRenderCommand`, `EntityPhaseItem`, and `CachedPipelinePhaseItem` traits to make it possible to reuse RenderCommands across phases. This should be helpful for features like bevyengine#3072 . It also makes the trait impls slightly less generic-ey in the common cases. This also fixes the custom shader examples to account for the recent Frustum Culling and MSAA changes (the UX for these things will be improved later).
Configuration menu - View commit details
-
Copy full SHA for 9a4cc42 - Browse repository at this point
Copy the full SHA 9a4cc42View commit details
Commits on Nov 13, 2021
-
replace matrix swizzles in pbr shader with index accesses (bevyengine…
…#3122) Matrix swizzles like `mat.x.xyz` are not supported in WGSL and accepted in naga by accident: <https://gpuweb.github.io/gpuweb/wgsl/#matrix-access-expr>
Configuration menu - View commit details
-
Copy full SHA for 029a7c0 - Browse repository at this point
Copy the full SHA 029a7c0View commit details
Commits on Nov 16, 2021
-
Add support for opaque, alpha mask, and alpha blend modes (bevyengine…
…#3072) # Objective Add depth prepass and support for opaque, alpha mask, and alpha blend modes for the 3D PBR target. ## Solution NOTE: This is based on top of bevyengine#2861 frustum culling. Just lining it up to keep @cart loaded with the review train. 🚂 There are a lot of important details here. Big thanks to @cwfitzgerald of wgpu, naga, and rend3 fame for explaining how to do it properly! * An `AlphaMode` component is added that defines whether a material should be considered opaque, an alpha mask (with a cutoff value that defaults to 0.5, the same as glTF), or transparent and should be alpha blended * Two depth prepasses are added: * Opaque does a plain vertex stage * Alpha mask does the vertex stage but also a fragment stage that samples the colour for the fragment and discards if its alpha value is below the cutoff value * Both are sorted front to back, not that it matters for these passes. (Maybe there should be a way to skip sorting?) * Three main passes are added: * Opaque and alpha mask passes use a depth comparison function of Equal such that only the geometry that was closest is processed further, due to early-z testing * The transparent pass uses the Greater depth comparison function so that only transparent objects that are closer than anything opaque are rendered * The opaque fragment shading is as before except that alpha is explicitly set to 1.0 * Alpha mask fragment shading sets the alpha value to 1.0 if it is equal to or above the cutoff, as defined by glTF * Opaque and alpha mask are sorted front to back (again not that it matters as we will skip anything that is not equal... maybe sorting is no longer needed here?) * Transparent is sorted back to front. Transparent fragment shading uses the alpha blending over operator Co-authored-by: Carter Anderson <mcanders1@gmail.com>
Configuration menu - View commit details
-
Copy full SHA for 213839f - Browse repository at this point
Copy the full SHA 213839fView commit details -
bevy_render2: Support nested shader defs (bevyengine#3113)
# Objective Fix nested shader defs. For example, in: ```rust #ifdef A #ifdef B some code here #endif #endif ``` ...before this PR, if `A` *is not* defined, and `B` *is* defined, then `some code here` will be output. ## Solution - Combine the logic of whether the parent and child scope guards are defined and use that as the resulting child scope guard boolean value
Configuration menu - View commit details
-
Copy full SHA for 14ce281 - Browse repository at this point
Copy the full SHA 14ce281View commit details -
Document the new pipelined renderer (bevyengine#3094)
This is a squash-and-rebase of @Ku95's documentation of the new renderer onto the latest `pipelined-rendering` branch. Original PR is bevyengine#2884. Co-authored-by: dataphract <dataphract@gmail.com> Co-authored-by: Carter Anderson <mcanders1@gmail.com>
Configuration menu - View commit details
-
Copy full SHA for 1076a8f - Browse repository at this point
Copy the full SHA 1076a8fView commit details
Commits on Nov 18, 2021
-
Shader Imports. Decouple Mesh logic from PBR (bevyengine#3137)
## Shader Imports This adds "whole file" shader imports. These come in two flavors: ### Asset Path Imports ```rust // /assets/shaders/custom.wgsl #import "shaders/custom_material.wgsl" [[stage(fragment)]] fn fragment() -> [[location(0)]] vec4<f32> { return get_color(); } ``` ```rust // /assets/shaders/custom_material.wgsl [[block]] struct CustomMaterial { color: vec4<f32>; }; [[group(1), binding(0)]] var<uniform> material: CustomMaterial; ``` ### Custom Path Imports Enables defining custom import paths. These are intended to be used by crates to export shader functionality: ```rust // bevy_pbr2/src/render/pbr.wgsl #import bevy_pbr::mesh_view_bind_group #import bevy_pbr::mesh_bind_group [[block]] struct StandardMaterial { base_color: vec4<f32>; emissive: vec4<f32>; perceptual_roughness: f32; metallic: f32; reflectance: f32; flags: u32; }; /* rest of PBR fragment shader here */ ``` ```rust impl Plugin for MeshRenderPlugin { fn build(&self, app: &mut bevy_app::App) { let mut shaders = app.world.get_resource_mut::<Assets<Shader>>().unwrap(); shaders.set_untracked( MESH_BIND_GROUP_HANDLE, Shader::from_wgsl(include_str!("mesh_bind_group.wgsl")) .with_import_path("bevy_pbr::mesh_bind_group"), ); shaders.set_untracked( MESH_VIEW_BIND_GROUP_HANDLE, Shader::from_wgsl(include_str!("mesh_view_bind_group.wgsl")) .with_import_path("bevy_pbr::mesh_view_bind_group"), ); ``` By convention these should use rust-style module paths that start with the crate name. Ultimately we might enforce this convention. Note that this feature implements _run time_ import resolution. Ultimately we should move the import logic into an asset preprocessor once Bevy gets support for that. ## Decouple Mesh Logic from PBR Logic via MeshRenderPlugin This breaks out mesh rendering code from PBR material code, which improves the legibility of the code, decouples mesh logic from PBR logic, and opens the door for a future `MaterialPlugin<T: Material>` that handles all of the pipeline setup for arbitrary shader materials. ## Removed `RenderAsset<Shader>` in favor of extracting shaders into RenderPipelineCache This simplifies the shader import implementation and removes the need to pass around `RenderAssets<Shader>`. ## RenderCommands are now fallible This allows us to cleanly handle pipelines+shaders not being ready yet. We can abort a render command early in these cases, preventing bevy from trying to bind group / do draw calls for pipelines that couldn't be bound. This could also be used in the future for things like "components not existing on entities yet". # Next Steps * Investigate using Naga for "partial typed imports" (ex: `#import bevy_pbr::material::StandardMaterial`, which would import only the StandardMaterial struct) * Implement `MaterialPlugin<T: Material>` for low-boilerplate custom material shaders * Move shader import logic into the asset preprocessor once bevy gets support for that. Fixes bevyengine#3132
Configuration menu - View commit details
-
Copy full SHA for 2e79951 - Browse repository at this point
Copy the full SHA 2e79951View commit details
Commits on Nov 19, 2021
-
Per-light toggleable shadow mapping (bevyengine#3126)
# Objective Allow shadow mapping to be enabled/disabled per-light. ## Solution - NOTE: This PR is on top of bevyengine#3072 - Add `shadows_enabled` boolean property to `PointLight` and `DirectionalLight` components. - Do not update the frusta for the light if shadows are disabled. - Do not check for visible entities for the light if shadows are disabled. - Do not fetch shadows for lights with shadows disabled. - I reworked a few types for clarity: `ViewLight` -> `ShadowView`, the bulk of `ViewLights` members -> `ViewShadowBindings`, the entities Vec in `ViewLights` -> `ViewLightEntities`, the uniform offset in `ViewLights` for `GpuLights` -> `ViewLightsUniformOffset` Co-authored-by: Carter Anderson <mcanders1@gmail.com>
Configuration menu - View commit details
-
Copy full SHA for a772931 - Browse repository at this point
Copy the full SHA a772931View commit details
Commits on Nov 22, 2021
-
Added missing wgpu image render resources. (bevyengine#3171)
# Objective I need to queue my own textures up for font rendering(texture arrays) and I noticed a bunch of `ImageX`, like `ImageDataLayout`, were missing from the render resources exports. ## Solution Add new exports to render resources.
Configuration menu - View commit details
-
Copy full SHA for 900acc6 - Browse repository at this point
Copy the full SHA 900acc6View commit details -
Use crevice std140_size_static everywhere (bevyengine#3168)
# Objective - Use `std140_size_static()` everywhere instead of manual sizes as the crevice rewrite appears to have fixed all the problems as it claimed to do. I've tested `3d_scene_pipelined`, `bevymark_pipelined`, and `load_gltf_pipelined` and all three look fine.
Configuration menu - View commit details
-
Copy full SHA for 65e834c - Browse repository at this point
Copy the full SHA 65e834cView commit details
Commits on Nov 23, 2021
-
Configuration menu - View commit details
-
Copy full SHA for 8009af3 - Browse repository at this point
Copy the full SHA 8009af3View commit details