Due to an assertion in etc2comp, this unfortunately uses RGB8 instead of
RG11 but it still helps quite a bit (3.3 MB savings in the unzipped KTX
size).
This shrinks file size as follows, although it seems to darken the
rendered result.
```
1398209 Oct 2 16:22 ao.ktx
699172 Oct 2 16:20 ao_etc.ktx
1398209 Oct 2 16:22 metallic.ktx
699172 Oct 2 16:19 metallic_etc.ktx
1398209 Oct 2 16:22 roughness.ktx
699172 Oct 2 16:20 roughness_etc.ktx
```
At build time, mipgen now creates several compressed and non-compressed
variants for albedo.
For ASTC we use the ARM encoder, for S3TC we use the STB encoder. The
latter is somewhat limited so we may wish to investigate other libraries
in the future (e.g., AMD Compressenator).
At run time, we detect which of these variants to download, based on
available WebGL extensions. In practice, this means that desktop
browsers will use the S3TC variant and mobile browsers will use the ASTC
variant.
The makes unzipped albedo go from ~4 MB to 682 KB using S3TC.
Mobile support (ASTC and ETC2) is coming in a future PR, stay tuned.
Sometimes you want your KTX file to end in an extension other than
".ktx". For example, GitHub Pages applies gzip encoding to bmp files
but not to ktx files (which I think is consistent with nginx defaults).
This change makes it so that a deploy script can rename the files and
apply a simple string transformation to the HTML.
(1) Suzanne's normal map is actually linear but we were telling GL that
it is SRGB, so the shader was not reading (0.5,0.5,1.0) from a perfectly
flat normal map.
(2) --linear in mipgen was not honored when consuming PNG files.
(3) The build was not passing --linear to mipgen for the normal map.
To determine PNG vs KTX, we were looking at the file extension of the
asset name rather than the actual file path (which is a URL).
Also, le singe était trop sombre, so I added a call to setIntensity.
In Chrome, this reduces texture load time from 620 ms to 150 ms because
it removes the PNG decoding work for the surface textures. We are still
using PNG for the envmap, I'll fix that soon.
Many web servers, including GitHub Pages, automatically use gzip
encoding for these files. Over the wire these files actually are not
much bigger than the PNG, even though they contain miplevels.
Stay tuned for compressed textures, which should make this better.
I tested the validity of the resulting KTX files by using macOS Preview,
which can read some types of KTX files. (!)
This CL also adds mipgen to the WebGL build, although its outputs are
not yet used by the sample apps.
This looks for VULKAN_SDK at build time, and if present it tells
Filament to use the `libvulkan.1.dylib` that's located there. Otherwise
it falls back to our old loading strategy, which uses a bundled version
of MoltenVK that allows us to avoid requiring installation of the
LunarG SDK.
I tried this out an it works for me...
Closes issue #238.
This adds a new demo that leverages ImGui. It looks very similar to the
existing material_sandbox demo we have for desktop, with a few
differences:
1. Does not use FilamentApp.
2. Does not draw a shadow plane.
3. Does not use a TrueType font in ImGui. (improves load time)
4. Does not allow the user to spin the model. (will fix soon)
We now have a triumvirate of web demos with a progression in complexity:
1. triangle
2. suzanne
3. sandbox
This is a sufficient set of WebGL samples for now, at least until we
finish creating a proper JavaScript API.
This CL factors out some of the common code with the native sandbox
demo, but keeps the UI definition separate since the web demo has some
minor differences (e.g., there is no shadow plane yet).
Note that using viewport units for height was wrong; it caused a bad
aspect ratio on Android while the URL bar was visible. This is explained
in an article:
https://developers.google.com/web/updates/2016/12/url-bar-resizing
The WebGL build invokes cmgen for samples, which takes several minutes
in debug configuration. Let's use a release build for the host tools,
regardless of the build configuration for the target architecture.
This removes the trick of drawing to a 2D canvas. It was corrupting the
alpha in RGBM images, which caused subtle banding in the Suzanne
reflection. Moreover it added complexity to the demo code.
This commit will increase the pre-zipped WASM size by 17k, but I think
it's worth it.
This also removes one of the cmgen passes in the WebGL build; we were
using PNG instead of RGBM for the skybox to work around the banding
issue that this fixes.
Some browsers complain about missing charset metadata etc, so this makes
our HTML samples a bit more legit.
Also, using an opaque canvas improves performance and makes it easier to
diagnose bugs.
This uses "foreach" in order to create proper dependencies for each
cubemap face and miplevel.
It also adds a custom command for the mesh and envmap assets, similar to
how we already handle materials. This seems to work properly and
rebuilds the assets only when upstream dependencies have been dirtied,
or when downstream dependencies have been deleted.
* Introduce two WebGL samples: triangle and suzanne.
This commit has no effect on mobile / desktop builds, it only adds new
targets to the `-p webgl` build.
We will eventually expose a proper JavaScript API, but for now these
samples use a (somewhat under-engineered) `filaweb` framework whereby
the WebAssembly module exposes a small number of C entry points: launch,
render, and resize.
Each sample has two source files: a cpp file and an html file. The cpp
file generates js / wasm pair. The generated js is simply a loader for
the wasm.
The CMake script creates a pristine "public" folder which contains the
minimal set of files needed to serve the web application using a simple
static file server. The public folder like this:
/suzanne.js built by em++ from suzanne.cpp
/suzanne.wasm built by em++ from suzanne.cpp
/suzanne.html copied from REPO/samples/web
/filaweb.js copied from REPO/samples/web
/favicon.png copied from REPO/samples/web
/monkey/*.png copied from REPO/assets/models
/monkey/*.filamesh built by filamesh
/desert/* built by cmgen
To decode PNG textures, we use the somewhat unusual approach of using
JavaScript to draw them into a hidden 2D canvas, then reading back the
pixels. This allows us to avoid fattening up the wasm file with a PNG
decoder. An alternative idea would be to pass a DOM Image directly into
glTexImage2D, but this would require some #ifdefing and/or JS injection
in Filament's OpenGL backend.
* Optimize the suzanne material.
These two functions expect a vector of the same size as the
matrix's storage vectors (float4 for a mat4f for instance) which
has two major issues:
- The vector must end with 1 for homogeneous coordinates to work
- Passing a single scalar (mat4f::scale(0.5)) creates a matrix
whose diagonal is set to that scalar, thus breaking homogeneous
coordinates
With this change scale and translate expect a vector who dimensionality
is 1 less that of the matrix's underlying storage vectors. i.e. a float3
for mat4f.
