This allows us to skip the CPU-side vector-to-color conversion that
occured at the end, and makes the real-time visualization consistent
with the final visualization.
* Add screen and multiply blending modes
This change also fixes a sorting issue: different sorting modes
were sorted in different buckets which is incorrect. We want
to sort only by distance.
* Update release notes and Java API
* Fix build error
- it's now possible to use a level of a texture as an attachment of
a rendertarget in the framegraph, by simply setting the desired level
when specifying an attachment.
- for now, removed the (never used) feature where the framegraph could
resize a resource under-the-hood.
- when requesting the physical renderder target by calling
getRenderTarget(), we now must specify the same level that was used
when the rendertarget was created. This is not ideal, and we hope
to fix that in the future, but it'll require some serious internal
changes (and maybe API changes)
- useRenderTarget() has a helper for simple cases, make it even more
easy to use. It assumes a single color attachment w/ WRITE access,
which is a common case.
- update all useRenderTarget() access flags
This fixes a problem where the min lod of a texture would be set
incorrectly when first drawing into the base level (common case) and
then creating a mipmap chain from it using blits.
Because drawing into the texture doesn't set the base level, after the
blit, the min level would be set to 1 instead of 0.
In fact, there was no way to set the level of a texture by drawing into
it, the only ways were by blitting or uploading data.
This change updates the min/max LOD when a texture level is attached to
a rendertarget, regardless of whether we read or write -- assuming that
we will write to it. The problem is that at that stage we don't know
if we will read or write. That said, if the user attaches an uninitialized
level to read from it, who cares what really happens
Even when hex modifier is used, 'char' should be printed as characters,
this is particularly relevant with 0.
e.g. out << (char)0, should write a nul terminator, not "0".
Since we have a depth buffer, we might as well use it for depth-culling,
this automatically discards the skybox's fragments -- which we can
assume won't participate in SSAO.
- this means that we cannot share the depth pass between ssao and color
passes, so all this code is removed, which simplify things a lot.
- the depth pass code is moved into the ssao codepath since they're now
intimately linked.
- and finals ssao shader can't rely on frameUniform which is set up with
the main buffer's size (instead of 1/4 res).
This replaces the previous "curvature to roughness" method. Both are related
and rely on the screen space variance of geometric normals but this new
solution offers more control (the screen space variance and the clamping
threshold can be controlled).
