Skip to content
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

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

Conversation

superdump
Copy link
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
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
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 <mcanders1@gmail.com>
@bors
Copy link
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