Skip to content

[Merged by Bors] - bevy_pbr2: Add support for not casting/receiving shadows#2726

Closed
superdump wants to merge 2 commits intobevyengine:pipelined-renderingfrom
superdump:pipelined-dont-cast-dont-receive
Closed

[Merged by Bors] - bevy_pbr2: Add support for not casting/receiving shadows#2726
superdump wants to merge 2 commits intobevyengine:pipelined-renderingfrom
superdump:pipelined-dont-cast-dont-receive

Conversation

@superdump
Copy link
Copy Markdown
Contributor

Objective

Allow marking meshes as not casting / receiving shadows.

Solution

  • Added NotShadowCaster and NotShadowReceiver zero-sized type components.
  • Extract these components into bools in ExtractedMesh
  • Only generate DrawShadowMesh Drawables 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?

@superdump superdump force-pushed the pipelined-dont-cast-dont-receive branch from 4f8292d to a1a5b01 Compare August 25, 2021 11:40
Having to add a zero-sized type component to every entity to mark it as a
shadow caster or shadow receiver by default feels quite unnecessary. As such, I
have added NotShadowCaster and NotShadowReceiver components. This introduces
double-negatives like Without<NotShadowReceiver>, etc but it means that only
the exceptions have to be specified in user code.

I also added an example to illustrate the effect.
@superdump superdump force-pushed the pipelined-dont-cast-dont-receive branch from a1a5b01 to 1de89e7 Compare August 25, 2021 12:11
@cart
Copy link
Copy Markdown
Member

cart commented Aug 25, 2021

This looks good to me / I think its worth merging as-is for now. My biggest questions are around "ideal user facing apis". There are lots of options here. Some engines make "shadow receiving" a material property, which might make sense here. I also want to consider something like:

struct ShadowCaster {
  enabled: bool,
}

To avoid the need for adding removing components / make the settings more discoverable.

But yeah this impl looks solid and I'd rather integrate it sooner than later. I removed the camera controls from the new example because they make it bigger / more complicated and I dont think the example benefits from freedom of movement.

@cart
Copy link
Copy Markdown
Member

cart commented Aug 25, 2021

bors r+

bors bot pushed a commit that referenced this pull request Aug 25, 2021
# 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 <[email protected]>
@bors
Copy link
Copy Markdown
Contributor

bors bot commented Aug 25, 2021

@bors bors bot changed the title bevy_pbr2: Add support for not casting/receiving shadows [Merged by Bors] - bevy_pbr2: Add support for not casting/receiving shadows Aug 25, 2021
@bors bors bot closed this Aug 25, 2021
@cart cart added the A-Rendering Drawing game state to the screen label Aug 25, 2021
@cart cart added this to the Bevy 0.6 milestone Aug 25, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-Rendering Drawing game state to the screen

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants