When HandleArena is full, we now revert to a slower system-heap
based mechanism. The problem is logged once. This allows the
system to continue to run.
This means it can easily be used by our other backend.
HandleAllocator uses 3 pool (which currently can't be configured),
and is very efficient in terms of memory overhead and handle to
pointer conversion.
A Handle<> is just an offset into a large heap managed by the 3 pools.
* Add simple ReadPixels performance test.
This simply lets the gtest framework report the total test time, which
includes startup and teardown. However we perform 100 runs of the
render+readback code to reduce the run-to-run variance. For 100 runs of
a 2000x2000 buffer, I see the following results on my mac:
- Vulkan: 1881 ms
- Metal: 1625 ms
- OpenGL: 978 ms
The test can be built & invoked like this:
```
./build.sh release backend_test_mac && \
./out/cmake-release/filament/backend/backend_test_mac -a opengl --gtest_filter="*ReadPixelsPerformance"
```
See also issue #4246.
* ReadPixels test: minor refactor.
The operator!= in std::array compares SPLIT_COUNT elements, which
is potentially greater than cascadeCount, which was the number of
initialized elements in splitPercentages.
- the ShadowMap cache is now inline and doesn't use unique_ptr<>
- reduced the size of ShadowMap significantly, it used some temporary
storage as member, but now that we have many of those, we shouldn't
do that.
- removed some duplication of fields
- fixed some headers inclusion
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 basically expresses the fact that we won't need an "auto-resolve",
indeed the temporary depth buffer is always discarded. In the GLES
backend, this is likely (if MSRTT is supported) to take a less
complicated code path.
Improve some comments.
- the clear color was broken since we switched dot EVSM
- use the scissor instead of the viewport, it makes it easier to compute
the uv-scale.
- the min/max lod level wasn't reset properly
- also clamp the minimum shadowmap size to 8, and document it.
We make better use of the framegraph, by using a pass per shadowmap,
instead of generating all shadowmaps in a single framegraph pass.
This allows us to use less temporary memory when blurring, but also
simplifies the code.
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.
