This can have a dramatic effect on SSAO and needs
to be adjusted based on the scene's scale/units.
The default value used to be about 6cm, and has
been changed to 5mm.
* WIP New tone mapper API
* Implement tone mapper constructors and destructors
* Add new genertic tone mapper
* Make the generic tone mapper available in our sample UIs
* Fix warnings and crashes
* Fix generic tone mapper and graph mappers in the UI
* Add Java APIs for ToneMapper
* Implement copy/move operators for GenericToneMapper
This lets you see highly readable GLSL when transpiling the generated
SPIRV back to GLSL, with the original variable names preserved.
For now this is only useful when using `matinfo`, but it will soon be
useful in `matdbg` too.
* Generalize luminance scaling in color grading
Previously the luminance scaling step was tied to a specific tone
mapping operator, called "EVILS" in the API. This was however
somewhat misleading as EVILS really is a color handling system
that's independent of what we call tone mapping.
This change splits the luminance scaling step from the tone mapping
step, allowing the use of luminance scaling (the LICH part of EVILS)
with any tone mapping operator.
As a result, the operator known as EVILS is currently mapped to the
linear operator and renamed to "RESERVED" until it is replaced by
a proper — configurable — operator.
* Update release notes
* Fix web build
Saturation and vibrance were using the wrong luminance weights,
and this change switches EVILS to HK weighted luminance weights
to give better results.
* Add new sample app: image_viewer
This app shows how to load and visualize images. It's also useful to work
on color grading and other post-processing effects by just loading an HDR
or EXR image as a reference.
This change also adds a new exposure setting to the color grading LUT.
* Fix comments and build
* Fix Metal
* Use high precision for the UV coordinates
* Fix refactoring issue
* Add support for KHR_materials_volume
* Add ubershader support for KHR_materials_volume
* Update readmes
* User highp on anything that affects UVs
* Add missing precision qualifiers
* Fix transmission
* gltfio: fix precision in KHR_texture_transform
Fixes#4253.
* Update to the new order of parameters
Co-authored-by: Romain Guy <romainguy@curious-creature.com>
* API CHANGE: honor user-defined precision, rename SamplerPrecision.
matc now honors 'precision' on non-samplers in mat files, and
the filamat API now allows clients to specify precision for
non-samplers.
This involved flattening a union that is internal to filamat.
* MaterialBuilder: Add Java bindings for precision.
* Add support for transparent shadows
This solution uses an 8x8 Bayer matrix. We could find a better
noise. We also need better filtering of the shadow maps. A PCF
is barely enough and VSM fails without blurring.
* Use a fixed Bayer matrix, fix pre-caching of depth shaders
* Use gradient noise instead of fixed bayer pattern
* Update docs
This is a trivial change since we moved the lightspace computation
in the fragment shader. The limitation to 6 is due to how we're storing
the culling result.
Instead of managing a GrowingSlice<> more or less shared between
several RenderPass, RenderPass now works directly with an Arena which
owns the commands. We do this so RenderPass can be copiable, which is
useful for creating a RenderPass from a "template" RenderPass
(usually empty, but with some scene parameters set).
RenderPass is now a lot more self contained.
Execution of the commands is now done with a RenderPass::Execcutor
which can be obtained from a RenderPass.
This change led to some code clean-up as well.
We also had to improve Arena<> to be able to take a custom Area.
This adds some significant JNI glue in order to make the Java API for
gltfio materials much more consistent with C++, and create feature
parity between the two languages.
The motivation is to allow Java clients to provide their own
ubershader-based solution or filamat-based solution.
- The `MaterialProvider` Java class is now an interface.
- The `UbershaderLoader` Java class is now a concrete implementation.
- Users can now write their own provider class using Java / Kotlin.
To streamline the amount of JNI work that occurs at run time, the
MaterialProvider Java interface uses ints in a couple spots instead
of enums. This sacrafices some readability for Java clients who wish
to write their own provider, but makes the JNI much simpler.
This replaces #3975.
We have a limited number of interpolants, and 2 were used for spotlights,
but this is a fairly uncommon case, so we move the calculation to the
fragment shader. A side effect of this is that we are not limited to
two spot-light anymore from the shader's point of view.
This essentially adds a vector transform per fragment, but on the other
hand, it removes communication between the vertex and fragment shader,
as well as interpolation of the position.
This is still somewhat work-in-progress, but good enough to be useful.
Some caveats:
- large blurs don't work well with cascades
- the implementation uses more memory than it could
This allows clients to obtain the extras strings for the asset and
for individual nodes. Note that extras for buffer views, accessors, etc
are not supported, although C++ clients can access the raw cgltf data
directly if they need to.
Filament uses a handful of known UBO, the code for creating their
interface block is not needed in filament (via filabridge), so
reorganize things so that we can move that code to filamat.
On the other hand, filament needs the C structure corresponding to
the UBO, to find the fields offset and ubo size and name.
We now have a UibStructs.h in filabridge which only defines C struct
with a static name for the interface block's.
This should slightly reduce the size of filament proper.
We also now have a new helper TypedUniformBuffer<> which simply holds
one of these structs (or an array), and allows to set the fields
directly and more naturally from C++. std140 alignment is now left to
the caller, when going through that class.
- use EVSM (exponential VSM), helps a lot with light bleeding
- don't apply shadow biases with VSM
- improve VSM user settings: added more controls, expose to java
- minor code cleanups:
- rename some structures
- remove unused parameters
- remove unused uniforms
- OpenGL ES on Android
- Metal on MacOS/iOS
- Vulkan everywhere else (Linux/Windows)
The main change here is that OpenGL is no longer the default on
desktop.
Most of our samples have a `-a` option that can be use to specify the
desired backend.
* Materials can now provide custom lighting/shading
When a material uses the "lit" shading model, customSurfaceShading can
be enabled to replace Filament's lighting implementation. When this
feature is enabled, the material *must* provide the following function
in the fragment shader block:
vec3 surfaceShading(
const MaterialInputs materialInputs,
const ShadingData shadingData,
const LightData lightData
) {
return vec3(1.0); // custom lighting here
}
Please refer to the docs in Materials.html for more information about
this feature and the different values provided by the data structures
passed to the function.
* Update docs
* Update docs/Materials.md.html
Co-authored-by: Philip Rideout <philiprideout@gmail.com>
Co-authored-by: Philip Rideout <philiprideout@gmail.com>
We reuse the current job for the right side instead of spawning a new
job, which has overhead. This also cuts in half the number of times we
need to copy the user functor.
A side effect of this flag was that we had to always use notify_all
when starting a job, instead of notify_one -- in practice, we found
experimentally that more calls to notify_one is cheaper than fewer
calls to notify_all.
std::allocator::deallocate() expects the same value that was given
during allocate().
Interestingly, this bug did not manifest any issues (even with ASAN) on
some platforms.