It looks like out static libc++abi that we use on linux needs
pthread, even if the exe doesn't use it.
Adding libutils to this test fixes the build on my local linux machine.
The real fix is probably something else, bug I don't quite
understand these shenanigans.
the texture's max level wasn't set properly when uploading
data for level 0 (it was for other levels).
this would cause uninitialized levels to be accessed by the GPU.
This is an efficient method that allows clients to add a slew of
entities to the scene. This is particularly useful for the upcoming
gltfio library, which is agnostic of the Scene and exposes a flat
list of entities.
- when possible we resize the attachments
- we also round to 32 pixels to take avantage of
pools the driver may have.
- when attachment can't be resized and don't have
the same size, we do best effort -- i.e. resize
the ones that we can.
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.