Java callbacks are now directly dispatched to their handler, instead
of first going through filament's opportunistic dispatch, reducing
callback latency.
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.
No need for a proper library, this is just a common location to simplify
JNI bindings in other projects like filamat and gltfio.
There is no need to move the one Java source file (`NioUtils.java`)
since downstream libraries will have a dependency on Filament, and
FindClass should work fine.
The bug was reproduced and the fix was verified by copying the following
code snippet into one of our Android samples:
val norm = floatArrayOf(1.0f, 0.0f, 0.0f)
val tang = floatArrayOf(0.0f, 1.0f, 0.0f, 1.0f)
val expected = floatArrayOf(0.5f, 0.5f, 0.5f, 0.5f)
val resultBuffer = FloatBuffer.allocate(4)
val qtc = VertexBuffer.QuatTangentContext()
qtc.quatCount = 1
qtc.quatType = VertexBuffer.QuatType.FLOAT4
qtc.outBuffer = resultBuffer
qtc.normals = FloatBuffer.wrap(norm)
qtc.tangents = FloatBuffer.wrap(tang)
VertexBuffer.populateTangentQuaternions(qtc)
Log.e("Filament", "${expected[0]} == ${resultBuffer[0]}")
Fixes#695.
