The gist of it is that we can't always accumulate samples naively, and
we have to use different strategies with different tile types.
For the fast tiles it seems enough to reorder the sum, accumulating each
ring first, and then accumulating that into the output, because all
samples have the same weight.
For the foreground tiles, for some reason I couldn't find any major
issue and I'm not sure why.
For the background tiles, we need to use highp intermediates because
every sample has different magnitudes (weights)
* move the focus distance from DofOptions to Camera
The DofOption parameter is now deprecated, but will still work if the
focus distance is not set on Camera.
* A few new helper APIs on Camera
- getFocalLength() which returns the focal length used internally for
DoF computations.
- computeEffectiveFov() and computeEffectiveFocalLength() which can be
used to better simulate a real camera's FOV changes with the
focus distance.
Modified gltf_viewer so it uses the effective fov/focallendth when
DoF is active.
* simplify setLensProjection
We can call setProjection directly instead of converting to a fov
first, which ends up performing atan(tan(x)).
Also improve parameters names.
This adjustment is conservative, i.e. we limit the number of rings in
the kernel based on the kernel size in a way that it won't impact the
result. For instance, if the kernel size is 2 or lower, we don't need 4
rings.
This improves performance significantly, especially with large maximum
right counts.
As far as I can tell, there is no need for the `enabledAttributes`
argument in `setRenderPrimitiveBuffer`. This helps pave the way for
the upcoming BufferObject API.
- setImage() used the width of the texture for calculating the required
user buffer size, but this was too large when only updating a
portion of the texture. It would result in a BufferOverFlowException.
- setImage3D() had the opposite problem where it didn't take into
account the depth of the texture.
- the offset in the user buffer was called "bottom" on the C++ JNI side,
but it is called "top" on the java and filament side.
Fixes#3685
Currently the only NONE and MEDIAN are available options, at some
point we may add a "MAX" option which is cheaper.
There is no real practical uses for this option with these only two
choices, other than for debugging.
This is mostly used for debugging and having somewhat of a reference.
Change to the shader are minimal because all CoC values were always
treated as full-resolution. We just need to replace the downsampling
shader by one that just calculates the CoC. And we need to introduce
a CoC scale factor to compute the LOD to use (this was hardcoded
before).
On the C++ side, it's mostly a matter of replacing hardcoded buffer size
scales by a runtime or compile time variable.
* CString can construct from a string_view
(string_views lack a null terminator)
* Update libs/utils/src/CString.cpp
Co-authored-by: Mathias Agopian <pixelflinger@gmail.com>
We're implementing the two-layer technique described in
Jimenez DoF paper, where the foreground field is split in two layers, front
and back. In addition we compute accurately the foreground field alpha.
From a performance standpoint, most of the extra work is increased
register pressure and a bit of ALU.
Always store min CoC in the red channel and max Coc in the green
channel for both the CoC and Tiles textures.
(The tiles texture was doing the opposite).
this would happen only when a fast tile had a CoC < 2, because it
would then have an opacity, but we were ignoring it. It's color then
didn't match the color of the surrounding layer and the median filter
would spread a pixel from the surrounding layer into the fast tile.
we simply fix this by (1) generating the alpha/color for fast tiles,
which is easy to do and on the combine pass, skip the fast tile
combine when the tile has a an opacity.
before we were not doing that because it caused some aliasing
artifacts with mipmapping, however it turns out that there are artifacts
anyways, and using the proper weights actually reduces the most severe
ones.
the artifacts are due -- it seems -- to the low density of the kernel.
* Fix blanking windows not being drawn into on macOS
* Refactored to create swap chain info object; added fixes for resizing; added sample.
* CocoaGLSwapChain should inherit from Platform::SwapChain
* Link to SDL directly for multiple_windows example
* SDL apparently redefines main to SDL_main and requires C++ linkage
* Fix main to have SDL-approved signature
* gltfio: Add internal MorphHelper, enable up to 255 targets.
Previously, gltfio could not animate models with more than 4 morph
targets. Now we can handle up to 255 targets, as long as no more than
4 targets are ever used simultaneously. This allows us to handle
many more models, such as those exported by Modo, and the horse model
in #1852.
We do this by picking the highest 4 weights. The indices for these
weights are called the "primary indices", and we construct a new
VertexBuffer for each unique set of primary indices.
In the near future this will be made more efficient by adding a new
VertexBuffer API to the Filament core.
Fixes#1487.
* Code review fixups.
The hang was caused by a subtle race. When a job is completed, its
thread must signal all the threads that might be waiting on this job.
The signaling code was attempting to signal only the minimum number
of threads -- this was important especially in the case where no threads
were waiting, then the call to notify() could be avoided.
Unfortunately, for performance reasons we're not calling notify() with
the condition lock held, this meant that between the time the number of
waiting threads was latched and the time of the notify() call, more
threads could enter their condition variable wait(), and it would
then be possible for these threads to wake up, instead of the thread
we were trying to wake up (the one waiting on the job).
It would then get stuck forever.
This bug was introduced in 2df639133b
Also add some debugging code for this kind of failure (disabled)
we can't use a projection with infinite far as a custom
projection matrix, because this is not suited for culling.
recently a new version of setCustomProjection was added which allows
to specify both the rendering and culling projections.