This includes changes to OpenGL, Metal, and Vulkan backends.
At the backend level, vertex buffers are now always composed of buffer
objects. This lets us simplify the Driver API and some bookkeeping in
the backends.
This change also splits MAX_VERTEX_ATTRIBUTE_COUNT into two constants
because the maximum number of bound buffers is a separate concept from
the maximum number of attribute semantics (e.g. consider interleaving).
For now these two constants are set to the same value.
We also now store a byte count in HwBufferObject, which allows us to
remove the byte count from the Metal-specific handle, and to add some
asserts to debug builds to prevent size overflow.
- DoF: don't convert gl_FragCoord to mediump when generating noise
- SSAO: add a bunch of missing highp qualifiers
- all matrices and UV should be highp
- Also fix some typo in comments.
The focal length slider now works over a remote connection. Also, the
slider for focus distance now controls the value in `ViewerSettings`
(which gets applied to Camera) rather than the value in
`DepthOfFieldOptions` (which is deprecated).
according to the gl spec, we can't mix the EXT versions of
glRenderbufferStorageMultisample/glFramebufferMultisample with
the regular versions. Other drivers are more permissive.
When allocating a renderbuffer and the extention is supported, we always
use it.
It looks like the layout(location) is needed for output parameters of
the fragment shader in GLES. Adreno dirver didn't seem to care, but
Mali drivers do.
This fixes shaders that use multiple out buffers in debug mode.
This adds the 565 enum to a switch block (which is an actual bug),
and it fixes a JavaDoc warning about missing summary fragments (which
is just a silly warning).
Just for fun, this is an example of a web component that allows you to
embed a Filament viewer with a single HTML element. It does not have
many features, but is much easier to use than our raw JavaScript API.
* ImGuiHelper supports client-provided context
this lets impress load >1 embedded font into the font table
* ImGuiHelper supports client-provided context
this lets impress load >1 embedded font into the font table
Co-authored-by: Philip Rideout <philiprideout@gmail.com>
We now annotate the JS wrapper for Engine with a GL context handle.
This is fairly hacky because emscripten hides its internal GL object
from JavaScript, and it does not provide a mechanism to pass JS objects
into inline assembly.
This script makes it easy to update the web page at
https://google.github.io/filament/remote/ even if you do not have the
emscripten SDK. It works by downloadinug the latest continuous web
build, then placing the wasm file in the right place.
After running the script, the user must make a git commit to finish the
operation.
This is a big hackish, but is intended to help us debug scaling issues,
this adds a couple of sliders under [Debug] to control dynamic
scaling manually.
Shockingly there were no unit tests that did a simple write-then-read.
This is important because it's easy to forget details such as trailing
commas and the fact that uint8_t is a char.
NOTE: after Metal and Vulkan support lands, we can potentially simplify
the Driver API by removing some of the old VertexBuffer entry points.
This introduces a new API-level object called `BufferObject`, and a new
backend-level object called `HwBufferObject`. This encapsulates a single
VBO. It's especially useful when clients need to share data between
multiple VertexBuffer objects. (e.g. for morphing).
In the future, buffer objects could perhaps be used for non-vertex data
(e.g. for compute).
The existing `VertexBuffer` class can now be configured to use buffer
objects by calling `enableBufferObjects` on the builder. By default its
API is unchanged. If buffer objects are enabled, then clients should use
`setBufferObjectAt` (which takes a buffer object) rather than
`setBufferAt` (which takes CPU data).
OpenGL is the trickiest backend for this, due to existence of VAOs.
The implementation in this PR uses a version-tracking scheme to
figure out when to update the VAO.
We use the technique used by Jimenez for the foreground applied to the
background, where we "guess" the missing background information from
neighboring pixels. In several papers it's not deemed useful for the
background, however, it does improve the blur quality a lot very shallow
DoF, i.e. when a moderately blurred background sits over a strongly
blured one.
