* Add the ability to modify clip space coordinates in the vertex shader
This introduces MaterialVertexInputs.clipSpaceTransform, a mat4 that
is applied to gl_Position before exiting the vertex stage.
* Address code review comments
* Lower limit from API 21 to API 19
This was requested by an internal application. API 19 is when OpenGL
ES 3.0 support was added so there is no good reason for us to not
support this API level. The only trick is to avoid referring to the
glTexStorage2DMultisample symbol directly as it only exists in 3.1.
* Compile out code we never use
* Use reflection to handle shared EGL contexts pre-API 21.
* Remove comment
* More fixes required to run on API level 19
- dlym() fails for ashmem on API 19, so we only try on API 26+ instead.
- Older emulation for OpenGL ES 3.0 returns error states for valid API calls so we need to clear the GL error bit before we create the GL driver.
- Activity lifecycle changes since API 19 would cause animations to keep running and to reference destroyed objects.
- EGLContext.getNativeHandle() is new in API 21, we need to use reflection on API 19. The new code path uses the class loading trick to avoid a bytecode verification error on API 19.
* Filament now runs properly on API level 19
This commit adds a new api_level() API to libutils which can be used to
query the platform's API level. On Android it works as expected, other
platforms currently return 0.
This is to allow designated aggregate initialization in C++20.
We do this because we have been relying on C99 designated
initialization, which is only supported by clang, other compilers need
c++20 to get a similar functionality. Therefore, we now try to limit
Ourselves to C++20 rules.
This could break existing code, since now SamplerParams needs to be
zero-initialized:
SamplerParams p{};
This is generally not an issue because the intended use is:
doSomethingWithSamplerParams({
.filterMag = LINEAR,
});
the C++ standard says:
if T is a class type with a default constructor that is neither
user-provided nor deleted (that is, it may be a class with an
implicitly-defined or defaulted default constructor), the object
is zero-initialized and then it is default-initialized if it has a
non-trivial default constructor
Unfortunately, MSVC always calls the default constructor, even if it
is trivial, which breaks constexpr-ness.
To workaround this, we're always zero-initializing TVecN<>
Also removed constexpr from default constructors, since they never can
be constexpr as they're not initializing the vector.
* Add new setExposure(float) API on Camera
This API can be used to set a specific exposure value. For instance:
camera.setExposure(1.0)
Will set the exposure to 1.0 (or ISO 100, apeture 1.0 and shutter speed 1.2s).
This can be useful to match the lighting setup of other engines/tools. Setting
the exposure to 1.0 can for instance be used to treat lights as being unitless
(a directional light could have a strength of 2.0 for instance).
Fixes#1667
* Update release notes
* Fix Java build error
* Fix Web bindings
We need to document the backend headers that are public.
Added documentation for:
- DriverEnums.h
- BufferDescriptor.h
- PixelBufferDescriptor.h
Disabled doxygen for public headers of backend that don't need to
be public for filament's API.
Also improved documentation for:
- LightManager.h
- RenderTarget.h
- TextureSampler.h
This is a similar fix to the previous vector fix. Commutative
operations now always return the same type and the operations are
carried out in the precision resulting from following traditional
C++ rules.
It used to be that operations e.g. like:
float3{} + double{} would be computed as
float3{} + float3{double{}} instead of
float3{} + double3{double{}}
I other words, when an implicit conversion was involved on the right
it would be converted to the left side’s type, possibly losing
precision.
Another problem was that swiping the operands could produce different
Results, e.g.:
float3{1} * 5.0 -> float3{5.0f}
5.0 * float3{1} -> double3{5.0}
This is no longer the case, now both expressions would return a double3.
Note:
float3 r{};
r *= 5;
Is now equivalent to:
r[0] *= 5;
r[1] *= 5;
r[2] *= 5;
Instead of before:
r[0] *= 5.0f;
r[1] *= 5.0f;
r[2] *= 5.0f;
We now follow the same rules than for basic types, when performing
mixed-precision operations, e.g.:
float3 + double3 -> double3
double3 + float3 -> double3
dot(float3, double3) -> double
In particular, e.g. swapping the arguments to arithmetic operations
now always yields to the same result type (before, float3 + double3
would not return the same type than double3 + float3).
To prevent an excess of variants, sometimes our vertex shaders declare
inputs that they never read from. For example, our skin-and-morph
variant might never read from the skinning attribute, but still declares
the input.
This PR is a sister to #1663, which is a fix for #1525.
See also #1279.
