- Add option to build.sh to build for paritcular stereo
techniques (default to NONE). Only applies to samples.
- Consoldiate viewer checkbox for debugging stereo rendering
- Add DriverConfig flag for stereoscopic type so that it can
be used to determine availability of the feature and
(to be completed) enable corresponding GPU features.
Co-authored-by: Mathias Agopian <mathias@google.com>
* don't crash if we don't have a Camera set on View
- also add a method to query if a camera was set
* Update android/filament-android/src/main/java/com/google/android/filament/View.java
Co-authored-by: Powei Feng <powei@google.com>
---------
Co-authored-by: Powei Feng <powei@google.com>
This reduces resource utilisation for Views that never need shadows.
It saves a UBO, two Entities and about 10KB memory. We also lazily
allocate the debugging DataSource, which saves about 10K per View
in debug builds.
Overall this change makes "simple" Views less than 4KB heavy down from
about 24KB (debug, 14KB release).
The main changes:
- ShadowMapManager is now allocated lazily
- the ShadowMap cache object is also allocated lazily
- debug DataSource is allocated lazily
- ShadowMaps are prepared/initialized with a Builder, which makes it
clearer that some APIs are only for preparing the ShadowMap cache.
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.
- Remove queue submit call when using headless swapchain. It was meant
to emulate a real swapchain, but queue submits are expensive.
- Add option to remove flush and wait when window resizes. If a
headless platform uses this signal to refresh the swapchain, we
don't necessarily need it to also flush and wait before the refresh.
- Refactor VulkanPlatform customizations
This fixes the gltf_viewer automated testing mode, invoked via
`--batch=default --headless`.
ReadPixels was being issued with an out-of-bounds size on high DPI
platforms, which caused weird backend errors.
Since we create an invisible SDL window while in headless mode, the
presence of the SDL window does *not* indicate headless vs non-headless.
Partial fix for #5111
This functionality (in the Automation section) was violating a
constraint that was landed in November.
1) Call postRender inside beginFrame / endFrame.
2) Use RGBA when issuing ReadPixels (required by some backends) and
convert to RGB when dumping out the PPM file.
- OpenGL ES on Android
- Metal on MacOS/iOS
- Vulkan everywhere else (Linux/Windows)
The main change here is that OpenGL is no longer the default on
desktop.
Most of our samples have a `-a` option that can be use to specify the
desired backend.
- move public headers from filament/foo to filament-foo/
to avoid confusion with libfilament's headers
- add support for equirectangular to cubemap conversion
- add support for using an .hdr file directly in all our samples
These changes make it easier to test headless rendering in macOS.
I verified that this works using the frame_generator tool, however
it requires the fixes in PR #2529.
This is done for consistency with the Android samples. Tested with
gltf_viewer against Vulkan, Metal, and OpenGL. Dragged window between
high DPI and low DPI displays.
Since resizing does not trigger the "NSView has changed" handler in
PlatformCocoaGL, it now must to detect a resize in order to make the
required call to NSOpenGLContext::update() as per the following
documentation.
https://developer.apple.com/documentation/appkit/nsopenglcontext/1436135-updateFixes#2528
- there was a case where setting a clear color on the Renderer
would clear a blended view with that color instead of transparent
pixels.
- move configuring the ui view into ImGuiHelper
- fix gltf_viewer sidebar so its background is not uninitialized
* 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
Ben Doherty
Sungun Park
Powei FengandMathias Agopian
Eliza Velasquez
Joel Winarske
Johnathon Selstad
Philip Rideout
Romain Guy
Pixelflinger