* 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
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".
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).
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.
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.
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.
* Introduce AssetPipeline for performing glTF manipulations.
AssetPipeline offers a place for doing things like scene flattening,
transform baking, and optimization of glTF assets. These types of scene
manipulations will allow us to tackle lightmap baking in the upcoming
atlasgen tool.
This initial PR includes support for scene flattening, which is fairly
non-trivial. Support for parameterization via xatlas will be added in a
subsequent PR.
In a glTF asset, a single mesh can be referenced by several nodes, and
each reference can have a unique transform. AssetPipeline can flatten
the asset such that each instanced mesh has its own vertex data, and the
node transform gets baked into the vertex data.
Recall that gltfio is composed of two libraries: the core library (no
filamat) and the full library. This adds to the size of the full library
but leaves the core library as is.
* Fix various Windows build issues.
The cgltf "base path" that gets passed to cgltf_load_buffers should
actually be the path to original glTF file, otherwise bin filepaths
are resolved incorrectly.
