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).
- constant bias and normal bias default values in java didn't match
C++ or the documentation
- stable shadows were enabled by default in java
- polygon offset biases were missing from the java API
- document and don't apply polygon offset to VSM
- remove unused code
- move the control code out of FrameInfo and into
View itself. FrameInfo now just gathers information about the
frames instead of also doing part of the control.
- the control code has been refactored into a more formal PIDController.
- a few bugs were fixed in the control loop and default parameters
tuned.
The control loop itself now outputs a relative scale factor instead
of an absolute one. The relative scale factor seems easier to
control and is less jittery, and doesn't have to rely on the "integral"
term of the PID.
It's possible that more tuning is needed, but the scaling is now
more stable.
- defaults to 31 history points instead of 3, this gives a much better
estimate of the frame rate.
- make sure the calculations work for any definition of our internal
duration<> (it's useful to use milliseconds when dealing with
refresh periods).
- don't round to 8 pixels if the scale factor is exactly 1
- fix a few comments and warnings
Mathias Agopian
Philip Rideout
Ben Doherty
Romain Guy
chubei-oppen
daemyung jang
jeanlemotan
Rupert Rawnsley