We use a hashmap instead, which won't change the behavior of the
HandleAllocator (due to the increased size of the handles) between
debug and release modes.
We always may need to discard lights because we have a limited
number we can use in the shader. We now do this earlier, in particular
before we set up the shadowmaps.
Because we also have a limited (smaller) number of shadowmap, this
allows us to automatically select the ones that are closer to the
camera, which gives better results.
The most recently loaded model is now automatically re-loaded if you
re-start the sampler-gltf-viewer app.
Super useful in my case for `rgb-lights.glb` :)
* 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.
* Remove support for Java/desktop builds
These builds are never tested nor used on our end. We cannot
guarantee their proper support. It should also be possible
for an app to handle this itself.
* Remove Tungsten since it cannot be compiled anymore
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.
Benjamin Doherty
Mathias Agopian
Philip Rideout
Romain Guy
xjdkc