- 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).
It's now possible to set if a render target's attachment is accessed
for read and/or write -- instead of always being hardcoded to both.
We just add an "access" field to Attachment, which is still set to
RW by default, but can be set in useRenderTarget().
The access mode only affects building the graph -- in the end it's just
a regular render target.
There are now only 2 main commandTypeFlags, COLOR and DEPTH,
indicating if we need to generate respectively COLOR and DEPTH commands.
The command generation code, only has 3 implementations: DEPTH, COLOR and
DEPTH + COLOR.
We also add "options" flags that get passed along, used to control what
goes into the the depth pass -- this because sometimes we don't want
translucent or alpha masked objects. e.g. when rendering the shadow pass,
we want the DEPTH + shadow casters regardless of if they're translucent.
With this, we can fix a SSAO problem where alpha-masked objects where
not participating when the depth pre-pass was used. Now, we add those
objects to the DEPTH if SSAO is active and MSAA is not.
This adds some new functions to libimage for computing distance fields
and coordinate fields. This runs on the CPU but uses an efficient
algorithm. This will initially be leveraged by the baking pipeline to
dilate charts, but could be useful in other applications.
Filament references a few classes from native code and by reflections,
so when proguarding binaries we typically had to add an exception for
filament to make it run:
-keep class com.google.android.filament.** {*;}
In a compiled .dex file, the filament namespace takes about 120kb
(before compression), even if the classes aren't used.
To enable proguarding and stripping out unused filament classes,
introduce a UsedByNative and UsedByReflection annotation to explicitly
mark classes that need to be kept in the dex, so that the rest can be
potentially stripped out.
In my testing, this reduces the filament namespace in the .dex from
120kb->40kb, which translates to about 30kb apk size savings after
compression.
If A and B are equal keys, then hash(A) and hash(B) should be equal, but
xatlas was violating this constraint.
This bug was not present in Thekla's original code, it was introduced
later by the xatlas project.
