In OpenGL with use glInvalidateFramebuffer() for hinting controlling
the load/store of tiles. However, glInvalidateFramebuffer() conceptually
destroys the content of the framebuffer attachment.
This causes a problem when we want for instance to use a buffer for
reading only (e.g. a depth buffer) in multiple passes. In such
scenario, the attachment will be marked as "discard" (which is a
misnomer for storeOp==DONT_CARE in vulkan parlance), without the
intention of making the buffer invalid.
We fix this by ignoring the discardEnd flags entirely if a buffer
has not been written. In this case, we relying on the driver to not
write the tiles out -- but we don't have any other way to express
this in GL.
This issue cannot be encountered currently because the framegraph
is not aggressive enough setting the discardEnd flags.
As per the spec:
```
vkCmdWriteTimestamp latches the value of the timer when all previous
commands have completed executing as far as the specified pipeline
stage, and writes the timestamp value to memory.
```
the Instance id was off-by-one and didn't match the
given entity.
in gltf_viewer this caused contact shadows to not work
when there was only a single directional light
- Added an extra README file detailing what the scripts are for
- The scripts now display a warning and a prompt before requiring user confirmation to continue
- The system install commands are only executed in CI environments (ninja and cmake being installed as root without checking for the environment was a leftover from a previous non-GitHub based CI setup)
instead of storing two counters for point and spot lights, we now
only have a single counter for both, and the light data structure
has a type, the shader can use to decide what to do -- instead of
using two loops. In practice spot and point light code is very similar
anyways.
This simplify a lot the CPU side (as in make it less complex) and frees
up 8-bits in the per-froxel GPU data structure.
In Vulkan, the arrayness of a texture is an aspect of the "image view",
not the image itself.
In my earlier attempt I used VK_IMAGE_CREATE_2D_ARRAY_COMPATIBLE_BIT on
the image, which MoltenVK does not support. Confusingly, that flag is
actually meant for rendering into a slice of a 3D texture, which we are
not doing.
Vulkan is hard.
we can calculate each plane direction from its clip-space equation
(which is trivial), instead of back-projecting 2 points and computing
the cross-product
This came up when trying to use a very small number of froxels like
1x1x1 (just one!).
Some froxels where not detected as used when scanning horizontally,
this would happen when a sphere was fully inside a froxel (i.e. not
actually intersecting any planes), and this was the very last
column on the right.
Now we use the same code we use for Z and Y (which where working fine)
for the X loop.
this could lead to w/h froxel count to be 0, later leading to
divide-by-zero. There could also be a case where the viewport itself
had w/h of zero, also leading to divide-by-zero exception.
- there was a case where setting a clear color on the Renderer
would clear a blended view with that color instead of transparent
pixels.
- move configuring the ui view into ImGuiHelper
- fix gltf_viewer sidebar so its background is not uninitialized
sometimes this happens because the shader actually doesn't use the
texture (e.g. in a uber shader model), however this is an error in
metal and vulkan.
