Skip to content

Conversation

@lhog
Copy link
Collaborator

@lhog lhog commented Dec 26, 2025

  • Use industry standard shader formulas to calculate the shadow depth. Remove NIH Spring-isms. Also now it looks sane, previously it was weirdly reversed away from the light. This unfortunately requires update from the games using the shadows code as well. Maybe this one will be amended by some bigger changes like CSM to make all needed changes in one go.
  • Calculate more or less tight shadow cube volume. Making it even tighter is possible, but very expensive. This should hopefully resolve cases when shadows suddenly disappear for a part of the rendered scene at funny camera angles.
  • Improve shadow cube debug code: /debugshadowfrustum in conjunction with new /freezeshadowfrustum allow to freeze all shadow cube related calculations/updates and view the frozen state in the world space.
  • Replace weird and inconsistent shadow bias calculations with the fixed function PolygonOffset, the values of which I hand-tuned to work better in most of the cases
  • Some changes to ROAM?
  • ShadowProjectionMode and ShadowColorMode are now deprecated. I don't think anyone used it ever.
  • Other misc changes

lhog added 8 commits January 3, 2026 14:41
…e cost of breaking custom shaders compatibility

* Work on tighter shadow box
* Remove custom in-shader bias formulas and use standard OpenGL Polygon Offsets instead
* Switch to front face culling for terrain rendering to combat weird ROAM artifacts. Many years ago that caused issues, but perhaps it won't anymore
…center to be pixel perfect on the shadow map texture
…ding to the shadow cuboid w/o the extraShadowCamHeight adjustments

const float t = -(plane.dot(p0) + plane.w) / denom;
if (t < 0.0f || t > 1.0f)
if (t < 0.0f/* || t > 1.0f*/) // we only care abut the case when the intersection is behind p0
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we? The function seems only used in some shadow debug code currently, but this is a generic math function that takes a definite endpoint argument for the ray. Maybe there should be a separate "infinite ray towards a direction" function, or maybe the caller in this case can just put p1 like 1000x further away to guarantee a hit?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I think you're right, I'm making massive changes to this branch now in order to implement shadow cascades, once done I will make another function for ray vs plane.

Comment on lines +102 to +105
float mapPolygonOffsetScale = 10.0f;
float mapPolygonOffsetUnits = 10000.0f;
float objPolygonOffsetScale = 5.0f;
float objPolygonOffsetUnits = 1000.0f;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What happens if somebody tweaks the values? Could use a "larger means X, current value chosen via Y" comment

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it controls the absolute and slope dependent shadow depth offsets. It's pretty hard to explain the exact effects though, so I mostly got to these values by experiment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants