The old version that doesn't take a timeout now always waits forever;
before it waited for a few seconds on Android debug builds.
The new version has an explicit timeout that works on all platforms and
returns success status.
FIXES=[384043020]
Feature flags are intended to be used when a new feature is added to
filament and have generally two purposes:
1) during feature development, the feature can be implemented but
disabled which can help developing large features. This way the
feature can be tested by stakeholders while it's being developed
without impacting other clients.
2) once a feature is ready, its flag can be enabled by default, but
in case the feature breaks something or has unintended consequence,
clients have the option to turn it off.
Feature flags are intended to have a relatively short life span, i.e.
once a feature is stable, the flag fill be removed.
There two types of feature flags. Constant feature flags can only be
set during Engine initialization via Engine::Builder. Non-constant
feature flags can be set at any time.
Feature flags SHOULD NOT be used as configuration or settings.
Feature flags are designed with a few ideas in mind:
- they are very cheap to check inside the engine
- non-constant flags can easily be toggled using ImGUI
We are seeing a cluster of crashes that could be due to using an
EGLSurface whose ANativeWindow has become invalid. This could happen if
we continued to use (i.e. draw with) an EGLSurface after
SurfaceHolder::onSurfaceDestroyed() has returned.
This new flag enables an assertion that the native window is valid at
the time of makeCurrent(), which happens early in the frame.
BUG=[330392256]
* Add an Engine debug setting to force GLES 2.0
This setting is only meaningful on GLES backends, it's otherwise
ignored. When set to true, the backend will try to force a ES2 context
if supported. If not supported by the platform,
the backend will pretend it's a ES2 context.
This setting is currently only taken into account by the EGL platform.
* Update filament/backend/include/backend/Platform.h
Co-authored-by: Powei Feng <powei@google.com>
---------
Co-authored-by: Powei Feng <powei@google.com>
This PR adds a new `pause()` option to the `Engine` `Builder` and a new function
`setPaused()` to the `Engine`. While paused, the rendering thread will pause
indefinitely for commands as if none are available. As soon as the rendering
thread is unpaused, the commands are immediately executed.
* Add Material.compile() Java binding.
* Add Engine.flush() java binding
* Add Scene.forEach java binding
update the Android gltf-viewer sample to precompile all variants of all
materials in the scene, similarly to the desktop sample.
This change does three main things. First, it adds an option to the Engine
Builder to pick the feature level at which to instantiate Filament. The only
real practical purpose of allowing this is to be able to instantiate at feature
level 0. Secondly, it allows feature level 0 to properly work on non-ES2
devices. Thirdly, it changes both Android and desktop hellotriangle samples to
explicitly opt-in to feature level 0.
Unfortunately, feature levels are used in two different, somewhat contradictory
ways presently in Filament, which can make reasoning about this change a bit
confusing. From a client perspective, feature levels refer to buckets of
capabilities which are guaranteed to be supported. Internally, there is a
separate "feature level" stored internally at the Driver subclass level which
generally corresponds to the maximum supported feature level, but is also
referenced when activating workarounds for limited devices. For example, Uniform
Buffer Objects are not supported in ES2, however, Filament supports emulating
them such that the client does not need to care at all; a supported feature is a
supported feature. But internally, Filament uses this "Driver" feature level to
determine whether or not a given workaround is needed. There were several cases
where the "active feature level" was being examined in order to activate these
workarounds rather than the "driver feature level", which was incorrect.
Why should non-ES2-only devices want to activate feature level 0? Allowing this
behavior 1. makes feature level 0 more consistent with the behavior of other
feature levels and 2. allows clients a layer of validation that their software
will work on all devices supported by Filament if they explicitly opt into it.
Consistency: Filament guarantees that any given device which supports a given
feature level will also support running on every feature level below, except for
feature level 0. This change removes that exception.
Validation: It's not perfect, and there will likely be bugs and unexpected
differences in behavior between ES2 and non-ES2 devices that crop up in the
future between two devices running on the same feature level. However, it's at
least a basic high level layer of validation that enables more rapid testing
workflows directly via desktop versions of Filament rather than having to fiddle
with something like ANGLE to get perfect GLES 2.0 compliance. Additionally, it
expands options for automated testing (with the same caveats).
This change has been tested on both the desktop and Android versions of
hellotriangle.
* 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
auto-instancing can have some overhead, so when it is known that the
scene doesn't have identical primitives, it is better to disable it.
(disabled by default).
Also add some missing bindings for `enableAccurateTranslations`.
* Stop using members as globals between methods
* Multi-thread shaders generation with JobSystem
* Pass JobSystem to MaterialBuilder::build()
* Fix MeshAssimp to use the new API
* Allow the Java API to pass a job system via Engine
* Update docs
* Apply suggestions from code review
Co-authored-by: Philip Rideout <philiprideout@gmail.com>
The JNI layer already does this, but can only track objects it created,
sometimes developers might create filament objects on the native side
and wrap them into java objects and this might cause a failure to
detected when objects are double-destroyed.
However, this can often be caught by the native code -- so, when the
native side is asked to destroy an object that doesn't exist, we now
return an error (exception if enabled) and we throw an exception
on the java side.
Filament typically doesn't do this kind of tests, however these bugs
can be very hard to find, and the cost is small.
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 is useful for unit tests. The content of the swapchain can be
read to main memory with Renderer::readPixels().
This PR doesn't implement this new feature in the following backends and
platforms (TODO):
VulkanDriver.cpp
MetalDriver.mm
PlatformWGL.cpp
PlatformWebGL.cpp
PlatformCocoaTouchGL.mm
We still do not compile the Vulkan backend for Android by default, this
simply makes it possible to use the samples on Vulkan with a one-line
change, which is useful for testing purposes.
This change also makes it so that the materials used for the samples
include SPIR-V. This makes them fatter but they are merely samples.
I still consider Vulkan on Android to be experimental, there are some
features that need to be implemented.
