Directional light and shadow

[superdump]

No description provided.

[superdump]

Updated, note that it depends on #18.

[cart]

Can we decouple this from #18? I'd like to hold off on taking dependencies on the crevice changes until we're certain they are the right path forward.

[superdump]

Can we decouple this from #18? I'd like to hold off on taking dependencies on the crevice changes until we're certain they are the right path forward.

I don’t have much time now as I am back at work. If I do this then I will not use crevice at all for problematic structs and will instead just use manual padding, manual sizes, and bytemuck. Is this ok?

[superdump]

Can we decouple this from #18? I'd like to hold off on taking dependencies on the crevice changes until we're certain they are the right path forward.

I don’t have much time now as I am back at work. If I do this then I will not use crevice at all for problematic structs and will instead just use manual padding, manual sizes, and bytemuck. Is this ok?

Never mind, I can't even take this approach because GpuLights is stored in a DynamicUniformVec which depends on the AsStd140 trait.

[superdump]

Oddly this now seems to work without any changes to crevice from what we're already using.

[cart]

Pushed a few superficial changes:

1. Transform::rotate had the wrong order (and i wanted to use it in the examples so i fixed it)
2. Manually specifying the light direction instead of using the Transform felt wrong, so I changed it. People will want to use the existing editor rotate/translate gizmos to mess with lights. All engines I'm aware of do it this way. This also has the benefit of removing the need to keep direction normalized, which allows us to use ..Default::default() for directional lights.
3. Moved bias default constants into PointLight and DirectionalLight types. This makes the constant more easily discoverable / self documenting. And it decouples PointLight and DirectionalLight biases, which shouldn't necessarily be the same.
4. Simplified the logic in the examples (because I want them to be as minimal as possible). I'd love to remove the manual light matrix construction too. We should give users simpler tools for this (although we can consider waiting until we adopt cascaded shadow maps or something similar).

[cart]

I doubt these changes will be particularly contentious, so I'm merging in the interest of moving forward. But feel free to contest anything. These changes are easy to revert.

Great work here!

[superdump]

Pushed a few superficial changes:
1. Transform::rotate had the wrong order (and i wanted to use it in the examples so i fixed it)

Ok. :)

2. Manually specifying the light direction instead of using the Transform felt wrong, so I changed it. People will want to use the existing editor rotate/translate gizmos to mess with lights. All engines I'm aware of do it this way. This also has the benefit of removing the need to keep direction normalized, which allows us to use `..Default::default()` for directional lights.

Yeah, I had the same thought with wanting to use transforms and visible gizmos for tweaking them, I just didn't change it from how it was done in current bevy. I had made the direction pub on the perspective-infinite-reverse-rh branch updates because the inability to use our standard ..Default::default() pattern was very irritating. I prefer this. Thank you!

3. Moved bias default constants into PointLight and DirectionalLight types. This makes the constant more easily discoverable / self documenting. And it decouples PointLight and DirectionalLight biases, which shouldn't necessarily be the same.

I agree. I did this in the perspective-infinite-reverse-rh branch as well.

4. Simplified the logic in the examples (because I want them to be as minimal as possible). I'd love to remove the manual light matrix construction too. We should give users simpler tools for this (although we can consider waiting until we adopt cascaded shadow maps or something similar).

Yes, I agree. When we have the bounding volumes types internally, we can do this. I could do it already with bevy_mod_bounding but that's an external plugin. 🙂