The current code only updates the order in the transaction commit if there's a single out-of-order node in the scene graph, but if multiple are out of order (or one swap doesn't fully fix the ordering), then we end up with out of order scenes, and incorrect world transforms.
Additionally, when nodes are reparented outside of a transaction, the order is not updated.
The FrameGraph would erroneously specify a sample count on textures
that are sampleable and used as an attachment to a multisampled
target -- however, that's not allowed.
We didn't run into issues, because had a workaround for this when
creating the texture. This is augmented by an assertion.
- we were not unbinding the renderbuffer int the right place,
when it's created, instead we were doing that when using it the
first time. Unbinding soon makes sense because we never need to
rebind it after that.
- in debug builds we were clearing render targets at creation time,
but this was wrong because a render target won't necessarily be written
(it could be used as the source of the blit for instance).
This didn't cause any trouble in the framegraph, by chance, it was smart
enough to reuse existing render targets in the case of blitting.
Ideally we'd clear textures/renderbuffer at creation time,
merge frameBufferRenderbuffer() and framebufferTexture() because
the filament API doesn't have a distinction. This actually removes
quite a bit of code too.
- write() is marked as [[nodiscard]] since it's
generally an error to discard it
- graphviz export not display wether a texture resource is
an actual texture or renderbuffer
* Rewrite Maven publish tasks to support multiple flavors
* Don't build filamat with an unused CMake option
* Don't compiler debug in release mode
* ... for real
* Link to BUILDING.md
This was untested because our only glTF Android sample uses glb instead
of JSON. We will soon be adding a new Android demo that uses an actual
gltf file.
This fixes#1841.
Instead we use the clear flags that the user specified. This is needed
in the case where we're rendering in the target in two passes, the
first pass might want to clear the buffers, while the 2nd one will not.
If we were combining the clear flags, the first pass's flags would be
sticky and the view would always be cleared.
If combining is needed it must be specified by the user.
This is in preparation to supporting screen-space effects.
There are two major changes:
- RenderPass is now copiable and intended to be passed by copy to
the execute stage of frame graph passes
- The color pass is in its own function now
This actually simplify RenderPass api.
We have one very important unit test that is supposed to make sure
the framegraph reuses the same rendertarget between 2 passes, this
unit test would always succeed when using the NoopDriver.
Now that we can mock the ResourceAllocator, we can ensure this unit
test is doing its job.
Rotate the sample pattern at every light direction, which trades
aliasing for noise (which is arguably more pleasant) for IBLs with
very high frequency (i.e. high level of HDR-ness).
* 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
We were conflating two concepts in our comments about the roughness
remapping, which was confusing. Also changed the remapping so it
matches a log2 mapping in our default configuration.
The C definition was changed to include METAL, moving NOOP further down.
The Java definition never caught up, making NOOP mean METAL and making the
real NOOP unreachable.
This patch puts them back in sync. Also, updated the Java comments to match
the comments from the C definition.
This moves the camera manipulator into its own library and adds new
functionality including a new "Google Maps" manipulator and a bookmark
feature to facilitate camera animation.
Java bindings and an Android sample will land later this week.
In glTF, multiple nodes can refer to the same mesh, and each node can be
assigned a unqiue string label. Previously we used NameComponentManager
to annotate entities with mesh labels rather than node labels. This was
wrong because Filament entities are 1:1 with nodes, not meshes.
We still fall back to mesh labels when node labels are not provided.
Fixes#1989 by fetching extension function pointers that were refactored
in #1977. Moved string-splitting utility to a common location so that
the base class and concrete classes can both use it.
