It turns out that it degrades performance even in cases where we
thought it would help. It seems to always trigger a "glFlush"
and has a very large CPU overhead. It looks like
glInvalidateFramebuffer() does a better job.
IF an UBO is marked as STREAM, meaning that data will
change every frame and the buffer content is invalidated
as well, then we use map/unmap buffer in asynchronous
mode to copy the data into the buffer.
This assumes the buffer is sized to be significantly
larger than the average amount of data used every
frame.
This makes our createTexture* helpers more consistent with the
createMaterial helper, and extends the wrapped Engine class with new
methods.
Before, clients did something like this:
const ao = Filament.createTextureFromPng(Filament.assets['foo.png'], engine);
...
engine.destroyTexture(ao);
Now, they can do:
const ao = engine.createTextureFromPng('foo.png');
...
engine.destroyTexture(ao);
This is more symmetric and concise. In general the JS API now supports a
class of "buffer-like" objects which exploit dynamic typing in order to
accept any of the following: BufferDescriptor, asset string, or
Uint8Array.
This test recreates a renderable every few frames and dumps the heap
pointer to the console so we can check if it increases over time.
Also simplified the personal web server script so that it uses twisted
and avoid doing a chdir, seems to be more reliable this way.
We were not normalizing one of the orthonormal basis vectors, causing
the visual aberration reported in #423.
This CL also add a "back light" to the redball demo to lighten up the
dark area in the IBL.
Fixes#423
Shameless recreation of the Android `textured-android` sample. I will
make this into a tutorial soon.
Also made some improvements to the test-builder Python script. Really,
this script exists only to make iteration easier; we need a better
solution for automated tests...
If a scene was used in several views, we would update the renderable
ubo several times per frame, which is not desirable. So we now have
such a UBO per-view. This could change in the future, depending
how we want to manage it.
We used to have a UBO for lights per scene, however it's better to
have one per view, since it depends on the camera heavily and is
limited in size.
Not doing so, could force us to upload the same UBO multiple times
per frame, for e.g. if the same scene was used in multiple views.
- move UBO declarations in UibGenerator, i.e. next
to their Uniform Interface Block definition.
This should help forgetting to update one but
not the other.
- move UniformInterfaceBlock.h and SamplerInferfaceBlock.h under
private/filament/.
- do the same things for samplers
We use the command stream to store the lights
ubo data (16K max), which avoid a copy and simplifies
the implementation. we can get rid of GpuLightBuffer.
The docgen script now looks for /// comments in the binding definitions,
and generates markdown from those. The reference page has three
sections: classes, free functions, and enums.
Before this CL, the web archive had two folders: "public" (which
contained web demos written in C++) and "filamentjs" (for the barebones
WASM).
After this CL, the web archive will instead have "dist" and "docs". The
dist folder will have the WASM and accompanying JS file, while the docs
folder has the tutorials and their accompanying demos.
If your machine has Python 3 installed, then "build -ap webgl" will
attempt to generate the JavaScript docs. If Python 3 isn't available,
this build step will be skipped. Note that our Kokoro macOS machines
already have Python 3 pre-installed.
Also removed the pipenv file to simplify the Kokoro Python environment.
Fixes#394.
