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

automatic depth/shadow shaders for arbitrary materials #5896

Draft
wants to merge 17 commits into
base: main
Choose a base branch
from

Conversation

robtfm
Copy link
Contributor

@robtfm robtfm commented Sep 6, 2022

Objective

allow depth to be correctly calculated for all materials, including StandardMaterials with AlphaMode::Mask and materials with custom vertex/fragment shaders.

Solution

builds on #5703

  • add ShaderSource::Naga variant to support loading shaders from naga directly
  • add DepthPipelineBuilder<M: Material> struct which uses naga_oil's prune module to strip the material's shaders down to the minimum required to output @builtin(position) and any discards, then returns a suitable pipeline using the new shaders
  • move queue_shadows from light.rs into queue_material_shadows in material.rs, use the depth pipeline builder to generate the pipeline

note:

  • writing a frag shader that uses bindings not available in the ShadowViewGroup (e.g. shadow maps) on the critical path to a discard, will cause the depth pipeline builder to fail
    - using atomics will fail as i haven't really thought about what they mean for pruning yet - do people ever use atomics outside of compute shaders? yes, people use atomics. added an initial prune implementation, not tested though

todo:

  • consider making this generic for mesh pipelines / maybe any pipeline (?), not just material pipelines. i guess as long as the specialization key is passed into the builder this would work
  • consider an escape hatch so people can author their own depth shaders if required (maybe just push an extra shader_def when deriving the depth shaders)
  • try and avoid rebinding materials when they are not required

@alice-i-cecile alice-i-cecile added A-Rendering Drawing game state to the screen C-Usability A simple quality-of-life change that makes Bevy easier to use labels Sep 6, 2022
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 C-Usability A simple quality-of-life change that makes Bevy easier to use
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants