On ES2 devices (or in forceES2 mode), we emulate the sRGB swapchain
in the shader if the h/w doesn't support it. In that case, the emulation
is controlled by a uniform that technically lives in the frameUniforms
block. However, the frameUniforms buffer is not updated, instead,
the uniform is manually set. Unfortunately, the UBO emulation
overrides it with the uninitialized variable.
BUGS=[377913730]
* 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.
This is only the first step where we:
- clean-up some code to prepare for 2nd step
- add support for the linear->srgb in the shaders
The linear->srgb conversion is protected by a
specification constant and will be enabled only
if the corresponding EGL extension in not present.
Then, if enabled, the actual conversion is
controlled by a uniform so that it can be
selectively enabled on swapchains that have it
turned on.
In this change, the emulation logic that sets
these gates is not implemented (that's step 2).
This CL contains two parts:
- changes to matc/filamat
- changes to filament itself
Filamat can now generate ES2 compatible shaders. Only the unlit variant
is supported. Fog and picking are supported as well.
post-processing, skinning, instancing, all lighting and shadowing are not supported.
Filament is updated to not issue commands that are not supported in ES2.
Addtionnally, the hello-triangle sample is updated to work on an ES2 device.
* API BREAKAGE: this change aims to fix multi-view support
What has changed:
- View doesn't have a notion of clear color anymore
- View doesn't have a notion of discard flags anymore
- The clear color and color-buffer discard/clear flags are moved to Renderer
- Skybox can now be set to a constant color
- View have a blend-mode
What does is all mean:
"Clearing" (i.e.) setting its background is now handled by Skybox, by
setting a constant color to the Skybox. This should take care of
drawing views side by side.
When a view needs to be drawn on top of another, it's BlendMode needs to
be set to TRANSLUCENT and of course and, generally, it wither won't have
a skybox, or will have one that sets some translucent pixels.
As an optimization, a View with BlendMode::OPAQUE will have its
background cleared with the color specified in Renderer.
If the SwapChain already has some content, it's now possible to set
the Renderer to not discard the content, together with TRANSLUCENT views,
it's possible to draw on top of that content.
It is NOT possible to share depth/stencil buffers between views.
Fixes: #2369, #2372, #2364
* Address reviewers comments.
Note: WebGL is still broken with this PR
Renderer can now be given a DisplayInfo that contains some
important information about the current display. This will be used
for frame-pacing and dynamic-resolution.
This is most relevant on Android, where we can accurately query these
parameters. Added support for that in our samples.
This also sets the minSDK to 19 (including gltf viewer's), since this is
the version we support. We were cheating before by under-reporting our
minSdk.
-DFILAMENT_SKIP_SAMPLES=ON with CMake
-Pfilament_skip_samples with gradle
This change also renames CMake options specific to Filament
to avoid clashes with subprojects.
* Re-organize Android Gradle files
Clean up our Gradle files, share versioning, etc. and prepare for
publication to sonatype.
* Use androix annotations for desktop
* Add samples as subprojects to root Gradle
* Fix build script
* Don't break when samples aren't compiled
* Better organize the Android Studio project
