Before we were keeping a foreground and background version of the
low resolution source, but in practice it really doesn't make a big
difference and we save a fair amount of bandwidth this way.
The bulk of the change is to remove a texture/target which mostly
affects the downsample and mipmap passes.
Also renamed some variables to be less confusing (MaxMin to MinMax for e.g.)
and fixed a few typos.
there has been a typo in the DoF code a while, but fixing it looks
much worse. we need to understand why. so for now we at least
document the typo in the code.
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
