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.
We can now use for e.g. vec4<float> instead of float4, this is
useful for templated code. The existing solution was to reach
out to the math::detail::TVec<> class.
- switched the frustum/box intersection code to double. With large
scenes, we were getting very wrong intersection points (up to 1m off).
This doesn't seem to happen with doubles.
- reject points that end-up outside the frustum
- made LiSPSM code more robust against the problem above. When points
were falsely placed behind the near plane (due to bad intersections),
we could end-up with NaN (sqrt of negative numbers).
* Add new shading model to Filament for specularGlossiness.
This adds a shading model based on KHR_materials_pbrSpecularGlossiness.
The corollary gltfio change will be in an upcoming PR.
* Improve documentation for specular-glossiness
* MaterialInstance now has setMaskThreshold for convenience.
* Materials now support dynamic doubleSided property.
This does not change the format of material packages because they
already have both getDoubleSided() and getDoubleSidedSet().
The only way in which this change could impact existing applications is
that materials that explicity set doubleSided to "false" will now
respect the material's culling mode, rather than forcing it to NONE.
Fixes gltf_viewer with littlest_tokyo in ubershader mode.
Fixes#963.
* JNI for dynamic material properties.
* Add underscore prefix to internal material params.
* Remove un-needed mat info field.
This is our first ImGui extension, it draws a draggable 3D arrow for
manipulating a unit vector. This is especially useful for tweaking the
light direction.
