-
-
Notifications
You must be signed in to change notification settings - Fork 4.3k
Contact Shadows #22382
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
base: main
Are you sure you want to change the base?
Contact Shadows #22382
Conversation
tychedelia
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would you mind adding or updating an existing example?
|
Sure, I was going to ask the crowd where it would make sense to add to an example. |
|
It looks like your PR has been selected for a highlight in the next release blog post, but you didn't provide a release note. Please review the instructions for writing release notes, then expand or revise the content in the release notes directory to showcase your changes. |
|
Closes #16164 |
|
Does it make sense to do the raymarching directly in the material shader? It might give better perf to pull it out to its own pass. Also MeshletMesh needs testing with this feature (and in the various forward/deferref/prepass modes). |
|
I have an example for contact shadows that I made in my old branch: https://github.com/pcwalton/bevy/blob/contact-shadows/examples/3d/contact_shadows.rs Feel free to steal it if you want, or not (it's rather old and would need to be updated). Up to you :) |
|
@JMS55 I don't think the raymarching can really be done anywhere else, because in forward you need to know what's in shadow right then. You can't really subtract a light after the fact. (Well, maybe you technically could make it work, but that'd be a huge can of worms.) |
| use_secant: u32, | ||
| }; | ||
|
|
||
| // Settings for contact shadows. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mention the Rust module where the Rust-side equivalent of this can be found in the comment, so folks can easily cross-reference to find out what the settings mean.
| let L = normalize(view_bindings::clusterable_objects.data[light_id].position_radius.xyz - in.world_position.xyz); | ||
|
|
||
| let noise = utils::interleaved_gradient_noise(in.frag_coord.xy, view_bindings::globals.frame_count); | ||
| let normal_bias = in.world_normal * 0.005; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you pull this 0.005 out into a const somewhere? Ideally it'd be adjustable in a uniform, but at least we should put it at the top of a file somewhere so that the tunable settings are in one place.
| shadow *= smoothstep(0.5, 1.0, rm_result.hit_penetration_frac); | ||
| } | ||
| } | ||
| #endif |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there no way you can avoid the duplication by pulling this out into a separate function?
|
|
||
| let rm_result = raymarch::depth_ray_march_march(&rm); | ||
| if rm_result.hit { | ||
| shadow *= smoothstep(0.5, 1.0, rm_result.hit_penetration_frac); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you actually need zero derivatives at 0.5 and 1 or would linstep be more appropriate? I'm not sure what motivates the use of smoothstep here.
Objective
Solution
Showcase
Screen.Recording.2026-01-04.at.7.19.25.PM.mp4
Screen.Recording.2026-01-04.at.7.36.03.PM.mp4