It could happen that values returned by dot() were slightly larger than 1 or less than -1 due to precision errors, but acos() is undefined outside of [-1, 1]. This would lead to NaN values on some GPUs, causing visible artifacts.
This was done because the original "_biasLightWorldViewProjectionMatrix"
relies on renderpath.light, which is problematic when rendering the
deferred light pass and there is a sun and other lights of different
type on the scene. Which would result on the wrong light being picked up
for the calculation of the uniform value.
This was done to undo the hardcoded nature of "receiveShadows", which
doesn't play nice when you have multiple lights of the same type and
one or several have cast_shadow set to false.
By simply "passing" the cast_shadow parameter within the lightArray it
was possible to detect lights that don't cast shadows before actually
wasting gpu cycles to render shadows with garbage data.
Support for deferred desktop and mobile, and forward was added.
This fixes a current problem with lights that occurs when getting too
close to the camera. The issue is related to the clustering algorithm
and cluster near.
Cluster near explanation:
Because of the logarithmic nature of how the Z slice is calculated,
clusters slices get "burned" too quickly at the start of the frustum,
which is not ideal. To aid this, and offset is applied to the start of
the cluster frustum, and that is clusterNear.
Cluster near solves that problem but creates another one: There is a gap
between the near plane and the cluster near offset that gets completely
ignored when calculating. And this results in the visual artifact of
slices not being affected by light whatsoever.
The proposed solution is make the gap resolve to the first slice of Z
clusters.
The same concept for spot lights was applied for point lights;
the difference is that because point lights require to do the projection in the shader, the first inversion was applied in sampleCube() when returning the uv coordinates.
"_FlipY" was added to replace "_InvY" in "PCFFakeCube()" because the inversion is only necessary for shaders and not anything else, otherwise it would break rendering of other parts.
With this it is now possible to enable atlasing of shadow maps, which solves the existing limitation of 4 lights in a scene. This is done by
grouping the rendering of shadow maps, that currently are drawn into their own images for each light, into one or several big textures. This was
done because the openGL and webGL version Armory targets do not support dynamic indexing of shadowMapSamplers, meaning that the index that
access an array of shadow maps has to be know by the compiler before hand so it can be unrolled into if/else branching. By instead simply
using a big shadow map texture and moving the dynamic part to other types of array that are allowed dynamic indexing like vec4 and mat4, this
limitation was solved.
The premise was simple enough for the shader part, but for the Haxe part, managing and solving where lights shadow maps should go in a shadow map
can be tricky. So to keep track and solve this, ShadowMapAtlas and ShadowMapTile were created. These classes have the minimally required logic
to solve the basic features needed for this problem: defining some kind of abstraction to prevent overlapping of shadowmaps, finding available
space, assigning such space efficiently, locking and freeing this space, etc. This functionality it is used by drawShadowMapAtlas(), which is a
modified version of drawShadowMap().
Shadow map atlases are represented with perfectly balanced 4-ary trees, where each tree of the previous definition represents a "tile" or slice
that results from dividing a square that represents the image into 4 slices or sub-images. The root of this "tile" it's a reference to the
tile-slice, and this tile is divided in 4 slices, and the process is repeated depth-times. If depth is 1, slices are kept at just the initial
4 tiles of max size, which is the default size of the shadow map. #arm_shadowmap_atlas_lod allows controlling if code to support more depth
levels is added or not when compiling.
the tiles that populate atlases tile trees are simply a data structure that contains a reference to the light they are linked to, inner
subtiles in case LOD is enabled, coordinates to where this tile starts in the atlas that go from 0 to Shadow Map Size, and a reference to a
linked tile for LOD. This simple definition allows tiles having a theoretically small memory footprint, but in turn this simplicity might make
some functionality that might be responsibility of tiles (for example knowing if they are overlapping) a responsibility of the ones that
utilizes tiles instead. This decision may complicate maintenance so it is to be revised in future iterations of this feature.
Changed how a spot light is detected when sampling light, which caused false positives and produced
that visual artifact when a cluster/pixel was detected incorrectly as being lit with a spot light when maybe none were there.
This issue seems somewhat related to that issue that prevents rendering spotlights and point lights shadow at the same time.
QuantumCoderQC
Moritz Brückner
N8n5h
Lubos Lenco
Alexander Kleemann
onelsonic