I have found this code where they use a cubemap for pointlight shadow and they don't need to retrieve the faceindex and the projection matrix. This greatly improve the FPS. I was wondering if this method can be applied to directional shadows.
\$\begingroup\$ \$\endgroup\$
2 - \$\begingroup\$ Transforming a point into directional light space is just three dot products and a vector addition — about as dirt cheap as you can get. It doesn't have the complications of figuring out which side of a cube to sample in the first place, because there's only one side. So this omni light code example sounds like it's solving a problem that just does not exist for directional lights. What specific profiling is telling you that this transformation is the bottleneck in your directional shadow mapping? \$\endgroup\$DMGregory– DMGregory ♦2023-06-23 08:56:45 +00:00Commented Jun 23, 2023 at 8:56
- \$\begingroup\$ Well globally the deferred lighting pass is my bottle neck. It performs better with the code mentionned because it removes a mul matrix and other lines and it is for 4 dynamic pointlights with shadows. So as you said this must be the cheaper way to do directional shadows. \$\endgroup\$philB– philB2023-06-26 08:47:34 +00:00Commented Jun 26, 2023 at 8:47
Add a comment |