This caused regressions with some of our samples like vk_hellopbr:
- For the new 1x1 textures, RGB isn't accepted by Vulkan and Metal.
Currently these platforms require RGBA, although we plan on adding
reshaping functionality for the future.
- Too many texture samplers in a single shader, this causes a run time
error. This could be alleviated by creating an atlas.
- vk_hellopbr assumes that all materials have a "metallic" param.
Going forward, we plan on creating a new library that avoids MeshAssimp,
so for now let's just disable gltf_viewer.
For test coverage, ensure that one of our C++ based web samples
uses a filamat file instead of inc, because this is how the JS based
web samples will work.
This makes pre-zipped triangle wasm go from 747 KB to 741 KB.
The web build now invokes cmgen three times for each IBL: uncompressed,
S3TC (desktop), and ETC (mobile). Alternatively, we could enhance cmgen
to accept multiple compression strings, but per discussion with Mathias
we decided to keep it simple.
I decided not to use compression for the skybox in our web demos because
the quality is too poor (see PR image). I did not try playing with
compression settings, might be worth revisiting in the future.
This change will allow the skybox use a compressed texture format.
For now, the old internal format "RGBM" is still honored, but in a
forthcoming change we will replace the enum with UNUSED.
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.
