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.
Both SSAO and SAO are available, but currently only
SSAO can be used.
SAO is more correct and produces less "halos", but
SSAO is sometimes more pleasant.
Note that this doesn't implement all the SAO optimizations
yet.
* Add micro-shadowing based on ambient occlusion
* Prevent crash when IBL is turned off
* Apply micro-shadows to baked AO only
* Remove debug code
* Add opacity control
* Fix opacity term
* Switch to micro-shadowing from Chan 2018
The AO baking procedure consists of the following steps:
1. Flatten the glTF hierarchy.
2. Generate a single 2D parameterization for the entire scene.
3. Embree Pass 1: Create G-Buffer using the above UVs as vert positions.
4. Embree Pass 2: Cast rays from the positions embedded in the G-Buffer.
The `gltf_baker` tool is not ready for general use but already
produces reasonable results for certain well-formed models.
Normals reconstructed from derivatives at an edge are invalid and
Cause dark spots in the final AO. We try to detect this case and
Assume no AO, which could be wrong too, but looks better more often.
I don’t think it’ll have an impact on performance because the normals
for the whole quad should be wrong together.
AssetPipeline now has a path tracer and optionally uses embree. For now,
the path tracer only sends out visibility rays and generates a simple
hit-or-miss monochrome bitmap. It splits the render target into tiles
and invokes a JobSystem task for each tile.
Filament developers can optionally install embree using homebrew or a
debian package. This avoids bloating third_party and increasing our
build time. If embree is not installed, a friendly run-time error will
occur when attempting to invoke the rendering functionality in
AssetPipeline.
The AO code is not yet implemented, but this PR sets up the
infrastructure, API, and camera rays.
This feature consumes a flattened glTF asset and produces a glTF asset
with new topology and an additional set of UV coordinates suitable for
baking light maps.
I verified with a couple glTF models that the generated assets are
visually equivalent to the source assets, even though the topology and
scene hierarchy is different.
The actual light baking is not yet implemented, but this is a major step
towards that goal.