* new feature level API for backends
backend can now return a "feature level", each level corresponds to a
"bundle" of features.
Level1: ES3.0 capabilities
Level2: ES3.1 capabilities + 31 textures + cubemap arrays
Currently metal always returns level 1, GL and Vulkan return level 2
if 31 textures or more are supported.
* Add public APIs for feature levels
* Add infrastructure to check feature levels in materials
* validate material feature level on use
The validation is done when creating a renderable. If the engine doesn't
support the material's feature level, an exception is thrown (or assert
if exceptions are not enabled).
* material documentation
* activate ESSL 3.10 for feature level 2
also generate #defines to identify available feature levels
* support for cubemap arrays in the public API
if feature level 2 is supported, cubemap arrays can be used from the
public API.
* add release notes
The main goal is to allow more flexibility, allow cubemap arrays in
the future and better match vk and metal apis.
Main changes:
- remove updateCubeImage
- remove update2DImage
- update3DImage is now the only texture upload backend API
cubemaps are now treated just like a 2D array of 6 layers.
For this reason, Texture::setImage(..., FaceOFfsets) is deprecated.
Additionally, the 2D versions of Texture::setImage() become inline
helpers.
A side effect of this change is that it is now possible to update only
a single face of a cubemap, but also a region of a face (or faces).
- getNear() and getCullingFar() now return doubles
- updated documentation
- all setProjection() calls can now throw (when enabled) and will
do so if preconditions are not met (instead of setting a default
projection).
- Frustum can now be logged on debug builds
auto-instancing can have some overhead, so when it is known that the
scene doesn't have identical primitives, it is better to disable it.
(disabled by default).
Also add some missing bindings for `enableAccurateTranslations`.
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).
I think the most important thing here is that we now let users know that
"offset" is not a byte count. This also fixes some small typos, e.g.
"weights" was used in the docstring instead of "positions".
To avoid making API changes, this does not fix a few weird things I
noticed in the Java API. For example, there is a redundant "count"
argument in methods that take an array. Also some methods do not
provide an "offset" argument, which is not consistent with C++.
The API is the same but there are some minor differences, which include:
- Ordering of fields in AmbientOcclusionOptions
- More @NonNull annotations that we forgot
- Javadoc formatting is different
This moves parser into a subpackage to shield it from the various
emitters (this folder structure is similar to what Rob Pike used for his
text templating library). This also adds a WIP Java code generator,
currently disabled.
This adds a code generator, implemented in Go.
This PR also prepares `Options.h` (the ground truth) by simplifying its
syntax just a bit. The ground truth file must have very simple C++
syntax, which is described in the README:
https://github.com/google/filament/blob/pr/codegen2/tools/codegen-options/README.md
This process revealed a small bug: `Filter.MEDIAN` was bound to the
incorrect value in Java.
The generated code is not yet used, stay tuned.
When the guard band is enabled, the effective rendering area is
increased by a certain amount (currently 16 pixels on each side) so
that screen-space effects (e.g. SSAO, SSR, DoF) behave better around
the edges of the screen. Of course, this comes at a performance and
memory cost.
Currently the guard band is not configurable other than being optional.
Added c++, java and js bindings.
Also deprecate some fields of DisplayInfo this shouldn't be a problem
because they were not actually used.
This change should allow an external-to-filament code to manage
frame pacing (e.g. something like swappy).
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.
This works by first generating a reflection buffer which gets blurred,
then the color pass samples from this buffer according to the roughness
of the surface being rendered.
A lot of the changes here involve utilizing "reserved" variants for
the new "SSR" pass and all the fallout from that.
Support legacy morphing (morphing with targets supplied via VertexAttributes) for older clients. This gives clients more time to transition over to the new MorphTargetBuffer API.
* 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>
* Replace generic tonemap curve with a simpler one
This change removes the shoulder parameter which had inconsistent
behaviors. The new curve is simpler and designed to still match
by default the gray point and the contrast of ACES in a bright
surround.
* Fix build
The version of Texture::setBitmap() that tool an Android bitmap handled
callbacks differently and in certain case caused a "double release" of
the callback object. This didn't actually cause problems though.
We now use the same mechanism used elsewhere (i.e. JniCallback).
Mathias Agopian
Philip Rideout
Ben Doherty
Romain Guy
chubei-oppen
daemyung jang
jeanlemotan