Resources are now single textures (generally buffers in the future),
but no longer a render target + a set of texture.
Instead, render target need to be declared and are associated to a pass.
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.
The `./` and file separator in the executable path prevented the program from running. The other changes are just cleanup for conformity. This is the last of the Windows doc changes as far as I can tell.
This class will not extend well to glTF so this cordons it off into the
filamesh namespace, which is an already-existing namespace that we use
for the things related to the filamesh file format.
For glTF we might create a new library with its own MeshReader so
this will mitigate confusion.
we could crash by dereferencing something that's
not a pointer when blitting to a rendertarget not
backed by a texture (i.e. renderbuffer).
also there was a case where we couldn't disambiguate
between the two cases.
This fixes an INVALID_OPERATION at draw call time with skinned
renderables. We do not see this error with Adreno drivers, but we saw it
with WebGL, and technically our usage was not spec compliant.
In the public docs and materials API, Filament "variables" are custom
interpolants (outputs of VS, inputs of FS). However we internally used
"variables" to also refer to built-in VS inputs.
CodeGenerator had a generateVariable method and a generateVariables
method, which did something completely different. :)
The vk_imgui sample regressed in December or so, after some changes in
how Filament manages uniform buffers. This commit makes the Vulkan
driver more consistent with the GL driver, which does a check for
zero-sized buffers.
This reverts a JobSystem optimization that attempted to avoid signaling
a condition when there was no waiters. Unfortunately, there was a
race that caused the the signaling thread to miss that the waiter flag
was set, thus not signaling.