* 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.
Fixes the "triangle count is zero" assertion with the big car model.
We do have nominal support for points and lines, but we should not
attempt to compute tangents for these.
As a reminder, glTF also supports loops, strips, and fans; this is the
only way in which Filament is non-conformant.
This reverts commit cc6201b0db.
On Android the loggers are not always initialized when several .so are
used, leading to crashes. It's not completely clear what is exactly
happening.
- libutil's slog, cout, cerr, cwarn and cinfo were not thread safe
at all.
- they are now thread_local
- for that reason the log buffer (which now exists per thread) is not
allocated until it's needed and is aggressively shrunk.
- removed our thread_local emulation which was incomplete.
- don't expose LogStream publicly.
This is (almost) drop-in replacement for std::vector, the main
difference is that FixedCapacityVector has a fixed (at runtime)
capacity, which makes it a lot more efficient and small for operations
like push_back();
The capacity can be set (and re-set) as usual with reserve(),
but exceeding the capacity when adding items will throw.
The capacity is also set when creating the vector with a size.
In addition a FixedCapacityVector<> instance is only 16 bytes instead
of 24 for std::vector<>.
The aim here is to reduce code bloat.