Filament will now allow incomplete mipmap chains for the IBL and
map the roughness to the available chain.
This allows to create roughness cubemaps with a minim size for
roughness==1, instead of always mapping it to 1x1.
cmgen will now use 16x16 cubemaps for roughness==1, which
improves the quality of rough objects significantly.
The beauty of this is that there is no asset or API change. Old assets
will continue to work like before.
This cleans up 3 related issues, but only the first of these caused an
actual user-visible bug:
(1) When the IBL was null, prepareLighting was failing to bind the black
1x1 texture.
(2) If you added and removed an IBL from a Scene, then Scene was not
returned to its initial state.
(3) The default 1x1 IBL used an intensity of 1 rather than 30000, which
is inconsistent with the null IBL.
Fixes#1940.
This removes a lot of code and will make it easier to migrate into a new
library with Java bindings, etc.
- The clipping planes and projection matrix were unused, removed them.
- In split view mode, our demos were using only 2 of the 3 manipulators,
removed one.
- Instead of callbacks and update methods, users can simply ask for the
current matrix at every frame.
- The manipulator's job is to consume mouse events and maintain an
"look at" basis, there is no need to store a reference to a Filament
Camera.
some drivers declare supporting anisotropic filtering, but don't
support calling glSamplerParameter() to set the max anisotropy, presumably because they only support glTexParameter().
We simply turn off anisotropic filtering on these drivers.
Sometimes CMake decides to use the JNI bits included with XCode instead
of those from the installed JDK. The header files are located in different
directories. This does the proper include.
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.
