There can be up to 4 channels drawing commands can be associated to.
Channels work like "priorities" except it's the strongest command ordering
key, in particular it takes precedence over the object's blending mode.
blendOrder was used to control the draw order of blended render
primitive within a Renderable. We now have an option to make the
blend order global, in this case those primitives with a global blend
order are always sorted solely using the blend order value (i.e. the
distance from the camera is not take into account).
We can now specify an "instance count" per renderable during creation.
This instance count applies to all render primitives in the
Renderable.
This will simply draw the renderable "instance count" times. A new
method available to vertex shaders, getInstanceIndex(), allows the
material to discriminate the instances and adjust the position/transform
accordingly.
Typically this is used for particle systems.
* Get the morph target count from the renderable
* Set the morph target count by Builder
* Update morph target weights partially
* Remove noexcept at functions could throw exceptions
* Update Java bindings at RenderableManager
* Add missing comments
* Update morph target weights from offset
Co-authored-by: Mathias Agopian <mathias@google.com>
Currently there are 8 light channels, both renderables and lights can
be associated to one or several light channel, lighting occurs when
at least one channel is active on both the light and the renderable.
Fixes#4275
The API now allows to create a standalone SkinningBuffer containing
Bones for skinning. This SkinningBuffer can even be very large and
contain bone data for several renderables.
New APIs on RenderableManager allow to switch to skinning buffer mode
and to set the SkinningBuffer (and window into it) to use.
Fixes#3238
Static JNI lookups were causing issues with multiple libraries.
We now do the lookups when we need them as they are effectively
just hashmap lookups and we do them only in places where the
work we need to perform will be much larger than a simple hash
map lookup anyway.
This chane also manually registers filament-utils JNI bindings
to get rid of unnecessary symboles. We should do the same for
other Filament libraries (the symbols are pretty long and
we now have many of them).
* Add support for screen-space contact shadows
This CL adds support and always enables it.
toggles and setting in the next CL (same PR).
* Plumb settings for screen-space contact shadows
screen-space contact shadows is handled like a shadow option,
parameters (including on/off) are set in the LightManager, using
the existing ShadowOptions API.
Additionally there is a per-renderable toggle.
Both toggles are off by default.
* Allow contact shadows when shadowing is auto-disabled
Shadowing can be auto-disabled when for instance there are no
shadow casters in the scene. We still allow contact shadows in
that case.
This would allow for instance, to make the vegetation on a terrain
not shadow-casting, and still get some shadowing there by using
contact shadows instead.
* apply micro-shadowing after contact shadows
also, don't compute contact shadows when we know we're fully shadowed.
Replace with forward declarations if needed and includes in .cpp that
now need them.
The idea here is to have our headers have the least amount of impact as
possible on our clients (e.g. compilation time).
This works by aliasing CUSTOM0 - CUSTOM7 to morphing attributes, and by
extending our existing skinning variant.
This PR was tested against some upcoming changes to gltfio.
Issue #1149, #1417
Discussed this feature with Mathias, we decided to create
MaterialInstance Java wrappers on the fly, and create Material Java
wrappers lazily. This is simple and avoids caching the wrapper objects,
which might otherwise lead to complexity and bugs.
Note that gltfio creates material instances behind the scenes, so this
feature is particularly useful for gltfio clients.
No need for a proper library, this is just a common location to simplify
JNI bindings in other projects like filamat and gltfio.
There is no need to move the one Java source file (`NioUtils.java`)
since downstream libraries will have a dependency on Filament, and
FindClass should work fine.
