- deprecate blit(), renamed to blitDEPRECATED. It's only used in one
place in copyFrame() now. We can't void it because we don't have
access to the texture from the RenderTarget.
- add a new blit() api that works with textures instead of render
targets.
- add a new resolve() api that works with textures instead of render
targets. doesn't support scaling.
- always use a shader when scaling in the framegraph
(there was only one place where we used blit)
- use the new blit() for:
- for mipmap generation on vk (fixme)
- copying the depth buffer to avoid ssao feedback loop
- use the new resolve() for:
- manually resolving MSAA color/depth
- Simplify the resolve APIs on the filament side
- implement generateMipmaps for the vulkan backend
simplify MetalBlitter
- remove metal blit workarounds
- don't issue a blit from a renderpass, this only affect Renderer::copyFrame
- We only handle a single texture now (instead of color+depth), so we
can simplify the code a lot.
Didn't touch the "slowpath" much, but it now assumes it blits color or
depth, not both.
In addition to the new getters, this change fixes the duplication of
a MaterialInstance, which didn't carry along the following states:
- alpha mask threshold
- specular AA threshold
- specular AA variance
- double sidedness
TODO: stencil state, polygon offset and scissor are stil not queryable
* new feature level API for backends
backend can now return a "feature level", each level corresponds to a
"bundle" of features.
Level1: ES3.0 capabilities
Level2: ES3.1 capabilities + 31 textures + cubemap arrays
Currently metal always returns level 1, GL and Vulkan return level 2
if 31 textures or more are supported.
* Add public APIs for feature levels
* Add infrastructure to check feature levels in materials
* validate material feature level on use
The validation is done when creating a renderable. If the engine doesn't
support the material's feature level, an exception is thrown (or assert
if exceptions are not enabled).
* material documentation
* activate ESSL 3.10 for feature level 2
also generate #defines to identify available feature levels
* support for cubemap arrays in the public API
if feature level 2 is supported, cubemap arrays can be used from the
public API.
* add release notes
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.
mipgen can now emit basis-encoded KTX2 files. Both the desktop and
web "suzanne" samples use this as a test for compressed textures.
This PR does not add KTX2 support to glTF, but it's on the way.
`BasisEncoder` has a builder style API that calls the basis encoder to
create KTX2 files. This hides some low-level BasisU features that we are
not using, like file I/O and mipmap generation.
`Ktx2Reader` is an easy-to-use API for creating Filament textures from
KTX2 files. Its API primarily consists of these two methods:
bool requestFormat(Texture::InternalFormat format);
Filament::Texture* load(const uint8_t* data, size_t size);
The first method is used to build an ordered list of formats that are
supported by your hardware. The second method consumes the contents of a
basis-encoded KTX2 file and attempts to produce a Filament texture with
a preferred format.
IMPORTANT: Our tools still let you use KTX1 for non-compressed images
because it is useful for HDR, but you can no longer use KTX1 for
block-compressed data.
Partial fix for #4771.
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.
* WIP New tone mapper API
* Implement tone mapper constructors and destructors
* Add new genertic tone mapper
* Make the generic tone mapper available in our sample UIs
* Fix warnings and crashes
* Fix generic tone mapper and graph mappers in the UI
* Add Java APIs for ToneMapper
* Implement copy/move operators for GenericToneMapper
* Generalize luminance scaling in color grading
Previously the luminance scaling step was tied to a specific tone
mapping operator, called "EVILS" in the API. This was however
somewhat misleading as EVILS really is a color handling system
that's independent of what we call tone mapping.
This change splits the luminance scaling step from the tone mapping
step, allowing the use of luminance scaling (the LICH part of EVILS)
with any tone mapping operator.
As a result, the operator known as EVILS is currently mapped to the
linear operator and renamed to "RESERVED" until it is replaced by
a proper — configurable — operator.
* Update release notes
* Fix web build
* New experimental tone mapper
The new tone mapper proposed in this change replaces Uchimura (see
below) and is composed of two distinct algorithms:
- The first is the customizable compression curve from Timothy Lotte
(from GDC 2015). The curve's default parameters were chosen to
match the overall appearance (contrast) of the ACES curves used
as our current default tone mapper. This was done to provide a
good migration path to making this new solution the default in
a future version of Filament.
The compression curve can be customized via its contrast, shoulder,
input middle gray, output middle gray, and maximum "HDR value"
(scene referred).
It is important to note that the compression is only applied to
the luminance of the input scene referred value.
- The second is a novel approach by Troy Sobotka called Exposure
Value Invariant Luminance Scaling (or EVILS). This solution works
on the largest chromatic channel of the input value as opposed
to mapping all RGB channels as we do in our other tone mappers.
The algorithm effectively scales all channel by a ratio that
depends on both the compressed luminance from the first stage
and the luminance of input value normalized by the largest
channel.
This new solution offers important benefits as it manages to
preserve chromaticity for high input values. It is also designed
to provide a desirable rolloff to white on overexposure. This
means that even without gamut mapping, this solution avoids many
hue skews (red to orange, blue to purple, etc.). The results
provided by this solution are much more natural and make using
other color grading tools much easier.
* Use std::pow instead of pow
* Fix Web builds
NOTE: after Metal and Vulkan support lands, we can potentially simplify
the Driver API by removing some of the old VertexBuffer entry points.
This introduces a new API-level object called `BufferObject`, and a new
backend-level object called `HwBufferObject`. This encapsulates a single
VBO. It's especially useful when clients need to share data between
multiple VertexBuffer objects. (e.g. for morphing).
In the future, buffer objects could perhaps be used for non-vertex data
(e.g. for compute).
The existing `VertexBuffer` class can now be configured to use buffer
objects by calling `enableBufferObjects` on the builder. By default its
API is unchanged. If buffer objects are enabled, then clients should use
`setBufferObjectAt` (which takes a buffer object) rather than
`setBufferAt` (which takes CPU data).
OpenGL is the trickiest backend for this, due to existence of VAOs.
The implementation in this PR uses a version-tracking scheme to
figure out when to update the VAO.
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.
Replace with forward declarations if needed and includes in .cpp that
now need them.
The idea here is to have our headers have the least amount of impact as
possible on our clients (e.g. compilation time).
This works by aliasing CUSTOM0 - CUSTOM7 to morphing attributes, and by
extending our existing skinning variant.
This PR was tested against some upcoming changes to gltfio.
Issue #1149, #1417
This is a prep step for the upcoming morph feature and does not require
a bump to our material version number.
Stay tuned for a new sample app that demonstrates this feature.
The following type bindings are now complete:
- RenderableManager
- RenderableManager$Builder
- RenderableManager$Bone
- TransformManager
- Box, Camera, Frustum
Note that we need to allow clients to find out if compressed textures
are supported BEFORE the engine is created, so that they can start
downloading the correct set of texture files. To allow this, we now
expose a getSupportedFormats function that creates a throw-away canvas
in order to query extensions (creating a temporary canvas is a technique
that we also used in the old PNG decoder that we removed in 7b36ed4)
