It was from zero to one instead of minus one to one.

It's still a poisson disk if you only sample the beginning of it.

Generated with https://github.com/bartwronski/PoissonSamplingGenerator

Technically not initial as I've had this uncommitted since Friday, but it was awful until I made the poisson disk progressive.

This one preserves its properties when combined with rotated versions of itself, reducing banding.

Its predecessor was overfitted as I'd got a parameter set far too high, which meant that each point was too close to being the most isolated one available when it was inserted instead of being random.
This meant that there was a lot of clustering if the radii were plotted, and in particular, the fifth point was nearly exactly at the centre, which made it invariant under rotation, causing a really pronounced band until there were loads of samples to outweigh it.

The new disk looks ridiculously much better at low sample counts, and still significantly better at higher ones.

It was generated with the same tool, but more settings were left at their default values, and it was in rotated disk mode with rotations as repetitions set to two.
As we really care about the distribution of radii, we don't want a higher value or it'd be too scared to put points close to the centre of the disk and too keen to put them near the outside.

It looks much, much better, and uses the same licence as the VSG so is okay to copy.

Requires upstream VSG changes to make the view dependent data descriptor set expose the shadow map as separate samplers and a texture instead of a single combined image sampler.
This is so the shadow map can be used both to access depth values and use hardware PCF via different samplers.

The blocker search is fairly standard and fairly straightforward.
Hopefully the code's fairly self-explanatory if you've got a vague idea of what PCSS is.

The penumbra radius calculation is a little less standard and less straightforward.
It prioritises correctness in the face of obstacles like light-space perspective shadow mapping or lights so large that the small angle approximation doesn't hold.
That means converting the average blocker back into eye space, which should definitely be Euclidean, using the inverse of the light-space matrix, computing the vector distance from the eye-space position, and actually calling tan on the angle.

This means that without any extra data passed from the CPU, we get a physically plausible penumbra size that's consistent between different shadow maps of different resolutions and scales.

On the other hand, larger penumbras make the pre-existing issue where shadow map boundaries are prominent even more visible.

Otherwise, the penumbra used to sample the tightest shadow map will be calculated without awareness of blockers just outside its bounds.

Also retune some parameters.

One metre is a more reliable blocker search radius now the above problems are fixed.
If it's too small, then the outer edges of penumbras could be lost.
If it's bigger, more samples are required to actually notice blockers, so samples ending up trustworthy helps.

The viable sample ratio seems mainly to optimise the cases where it's not safe to, so while it's not been removed yet, it's been set to one.

…ples into soft-shadows

Rebase accounted for migration to separate texture and sampler

Rebase accounted for migration to separate sampler and texture

It was from zero to one instead of minus one to one.

It's still a poisson disk if you only sample the beginning of it.

Generated with https://github.com/bartwronski/PoissonSamplingGenerator

Technically not initial as I've had this uncommitted since Friday, but it was awful until I made the poisson disk progressive.

Rebase accounted for migration to separate sampler and texture.

This one preserves its properties when combined with rotated versions of itself, reducing banding.

Its predecessor was overfitted as I'd got a parameter set far too high, which meant that each point was too close to being the most isolated one available when it was inserted instead of being random.
This meant that there was a lot of clustering if the radii were plotted, and in particular, the fifth point was nearly exactly at the centre, which made it invariant under rotation, causing a really pronounced band until there were loads of samples to outweigh it.

The new disk looks ridiculously much better at low sample counts, and still significantly better at higher ones.

It was generated with the same tool, but more settings were left at their default values, and it was in rotated disk mode with rotations as repetitions set to two.
As we really care about the distribution of radii, we don't want a higher value or it'd be too scared to put points close to the centre of the disk and too keen to put them near the outside.

It looks much, much better, and uses the same licence as the VSG so is okay to copy.

Rebase accounted for migration to separate sampler and texture

Requires upstream VSG changes to make the view dependent data descriptor set expose the shadow map as separate samplers and a texture instead of a single combined image sampler.
This is so the shadow map can be used both to access depth values and use hardware PCF via different samplers.

The blocker search is fairly standard and fairly straightforward.
Hopefully the code's fairly self-explanatory if you've got a vague idea of what PCSS is.

The penumbra radius calculation is a little less standard and less straightforward.
It prioritises correctness in the face of obstacles like light-space perspective shadow mapping or lights so large that the small angle approximation doesn't hold.
That means converting the average blocker back into eye space, which should definitely be Euclidean, using the inverse of the light-space matrix, computing the vector distance from the eye-space position, and actually calling tan on the angle.

This means that without any extra data passed from the CPU, we get a physically plausible penumbra size that's consistent between different shadow maps of different resolutions and scales.

On the other hand, larger penumbras make the pre-existing issue where shadow map boundaries are prominent even more visible.

IMPORTANT NOTE:
A rebase makes the already extensive changes here even less extensive
than they originally were.
Please look at 0edaf19 to see what
really happened.

The gist is that this was really the commit that switched from a single
sampler2DArrayShadow to a separate texture2DArray and two samplers.
The true version of this tale never had the intermediate stage where
there was a texture2DArray and a single sampler.
That's obviously more sensible than the rebased commit history's version
of events, as there's no point in separating out the sampler if you're
not also going to use another texture/sampler combination built from one
of the same inputs.

Otherwise, the penumbra used to sample the tightest shadow map will be calculated without awareness of blockers just outside its bounds.

Also retune some parameters.

One metre is a more reliable blocker search radius now the above problems are fixed.
If it's too small, then the outer edges of penumbras could be lost.
If it's bigger, more samples are required to actually notice blockers, so samples ending up trustworthy helps.

The viable sample ratio seems mainly to optimise the cases where it's not safe to, so while it's not been removed yet, it's been set to one.

Rebase accounted for migration to separate sampler and texture

…ples into AnyOldName3-soft-shadows

A couple of soft shadow fixes

…packing is the same

…zed and simpler.

…he number of checks.

…t done once per loop to avoid different code paths doing different increments

…y/less cryptic.

…ng and pbr ShaderSet.

…ith latest shadow.glsl etc. shaders