This new sample differs from "Hello Camera" in that it exercises all
three ways of using Stream. It also uses Canvas instead of Camera2 to
draw into the external texture. It shows two sets of stripes, one
animated using the shader and the other animated using Canvas. If the
two stripes are aligned, then the stream is perfectly synchronized.
Users can tap the screen to cycle between the three modes.
Unfortunately we require RTTI to be disabled for web builds
due to the way in which we handle array buffers. This may change
in the future but for now I think it's an acceptable constraint,
especially given the fact that RTTI adds bloat anyway.
A texture resource can end-up with not usage bit set if it is used as
an attachment of a render target that gets replaced by a moveResource()
call. The framegraph should take care of culling our this resource,
in that case, but currently doesn't.
We worked around this issue by not declaring the resources, but it's
better to do this in the frame graph code, as to not affect the
user facing API.
Fix#1165
In order to use transparent views, post-processing had to be disabled
because we were not able to blit post-processed buffers with blending.
This is now fixed by simply reverting to a quad.
A side effect of this, is improved performance when a scaling blit is
needed when MSAA is active.
This also introduced new "bugs", or at least weird behaviors: the
system needs to know when blending is needed, and this has to be
based on heuristics (unless we add a new api). Currently the heuristic
is that the COLOR buffer is not discarded and the view is cleared with
an alpha value (or not cleared).
1) When scaling is enabled, we're using a blit at the end of the frame,
however, if MSAA is also enabled, this blit is not allowed, so we
need an explicit MSAA resolve.
2) When rendering directly into the default render target with MSAA
enabled, we need an explicit resolve ONLY IF there is a format
conversion, because those are also not allowed.
Before, we were doing this resolve regardless.
3) The test for "rendering directly into the default target" had
become wrong because, the Render target can now be a user texture
(which is assumed to have the proper MSAA-ness and a depth buffer),
so no intermediate buffer should be needed for those. We now
check that render target is actually the default render target
We used to have this functionality, but it we removed it because we
didn't have a use for it and it was costly.
This new implementation is only internal, and would (will?) be useful
if we wanted to generate a special buffer for SSAO for instance (instead
of just depth). This implementation, overrides the material at the time
the commands are executed, which is much cheaper than the previous
implementation.
For the street light glb from the Khronos suite, this reduces texture
loading time from 290 ms to 110 ms.
Stay tuned for another feature: notification callbacks.
Related to #1876.
- we add an 'intensity' parameter that allows to control the strength
of the AO effect. This is useful for aesthetic reasons.
- the default intensity is now 2x that of before this change, which
makes the intensity parameter match AO papers this implementation
is inspired of.
- bias is now z-dependent, which reduces some self shadowing wrt the
depth.
This is needed because filament doesn't make strong assumptions about
the units used (e.g. meters), so we can't hardcode a distance in the
shader. But also, this is a cheap change.
ssaogen now produces better formatted tables, directly usable in
shader code.
SAO shader now squares the sample radius outside of `tapLocation`, also
added some comments.
Previously, Streams had two modes (native and texid), this adds a third
mode called "acquired", which allows for copy-free synchronized external
textures in OpenGL and paves the way for Vulkan.
The native mode is now deprecated but texid mode needs to stay around
until all clients can be upgraded.
In an early prototype, this functionality was added directly into
Texture but required quite a bit of additional state tracking, so the
Stream API seemed like a better fit.
This API is probably not necessary for Metal due to Metal's shared
ownership semantics.
This has been tested with a new Android sample that will be added in a
subsequent PR.
RenderPass's API now doesn't need to know about FScene, instead we
pass the geometry info as parameters.
This is one step towards keeping the "scene" concept more away from
rendering.
This fixes an oversight in #1641 for scenes that have only 1 primitive
when the depth prepass is enabled. In such cases, the same prim is
rendered twice in a row: once for depth and once for color.
We had enhanced the main render loop to override the primitive's
backface culling state when the material instance changed, but that was
not sufficient since the same material instance can be used for depth
and color passes.
Fixes#1872.
New internal API to add custom commands (lambda) before or after each
pass. These commands can be added at any point and will be sorted
properly.
e.g.:
appendCustomCommand(Pass::COLOR, CustomCommand::PROLOG, 0, [](){
// custom code
});
Also split appendSortedCommands() in two functions to make it easier
to insert custom commands.
On Debug builds, HeapAllocatorArena needs LockingPolicy::Mutex because
it uses a TrackingPolicy, which needs to be synchronized.
On Release builds, HeapAllocatorArena doesn't need a LockingPolicy
because HeapAllocator is intrinsically synchronized as it relies on
heap allocations (i.e.: malloc/free)
- this is to allow the use of C++17 std::invoke
- don't std::move() each argument of the tuple<> instead
std::move() the tuple itself and perfectly-forward each argument.
- handle return values
- handle synchronous commands
