Some buffers (like animation data) do not contain any vertex data
but web-based clients still need to know about this.
This interface is much simpler than the bindings lists, and in fact
we might remove the binding lists in the future to simplify the API.
Fixes#1593.
some driver don't support all float buffers as rendertarget, so we
improve the backends (opengl in this PR) to return what it actually
supports and we update the client (filament) to take that into
account when making decisions.
by using variadic macros we can greatly simplify the macros
definitions for declaring the backend API.
in particular we don't need a macro per number-of-argument, this is
now done automatically.
Unfortunately, we still can't handle zero-argument declarations, so
we keep the _0 variants.
This performs surgical modification of the IFF chunks rather than
invoking filamat from within matdbg. Low-level direct manipulation
(bypassing optimization passes etc) allows us to diagnose issues with
the shading pipeline.
This CL also adds keystroke bindings to the Monaco editor. You can
press Cmd+S to rebuild the current materials, or use Ctrl+Arrow to
navigate between shader variants and materials.
In a subsequent CL I will add a README that describes how this works in
detail, it will include a list of limitations and a feature wishlist.
We now check for FILAMENT_ENABLE_MATDBG and simply skip the draw call
when the program is invalid. The initial error message is still dumped
to the console, but we will not terminate or dump an infinite cascade of
error messages.
This only adds Engine-side support for edits. The debugger client will
be enhanced in another PR. This works by simply clearing the program
cache and swapping out the MaterialParser. Neat!
However, there are some gotchas:
- The DebugServer callback is triggered on another thread so to be safe
we defer the swap until the subsequent call to getProgram().
- The getProgram() method is const but in reality it can insert entries
into a mutable cache. This CL makes the constness of it even more
misleading by applying edits.
- The edit operation will leak the old HwProgram but I feel this is
fine because simplicity is crucial for injected behavior and this is
a developer-only feature.
Texture are special resources that can be read in different ways; either as
attachment (read) or sampled (sample), the user must now declare explicitly if she intends
to sample from a texture.
sample() implies read() so there is no need to call both.
This was already the case, as read() used to take a boolean, essentially meaning the same
thing. However, the bool didn't make sense for non-texture resources.
This also simplifies the implementation.
the framegraph will figure it out automatically from the
rendertarget sample count. this is done during resolve(), and after
moveResource is taken into account (so this works with imported and
moved resources).
when creating a rendertarget, if the sample count is not specified,
any existing target with the same attachment will match.
this simplifies both the user and implementation.
getRenderTargetDescriptor() now takes a RenderTargetHandle instead
of a texture handle.
