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.
This does not add any samples or continuous integration, but it at least
allows developers to do a "-p webgl" and check if an actual wasm file
for the core Filament library can be succesfully built.
* Add single-threaded config to Filament.
This adds a tick method to Engine and disables a couple components
in Renderer (FrameSkipper and FrameInfoManager).
This will make it easier to support WebGL, and will allow us to remove
some of the command buffer debugging stuff that we added for Vulkan.
* tick => execute, and other review feedback
* Restore the ASSERT for FFence::wait.
* Add clear coat normal map support
This change allows to set a separate normal map for the clear coat layer of a material.
* Document the new clearCoatNormal property
* Fix typo
* Add missing method to query the type of a light
* IcoSphere now generates front facing triangles
* Add a fairly generic sphere object to use in samples
it provides an ico sphere with normal, and reuses
the same vertex/index buffer for each new instance.
Each instance can have its own material, size and
position.
currently it’s not possible to change the # of
subdivisions.
* FilamentApp now provides a “default” pbr material
this makes it easier to create renderables for
testing.
* clean-up lightbulb and add spheres for each light
lightbulb now has less hardcoded things and it
spawns a small sphere for each light.
* Try to clean up asset folders for sample apps.
This removes the build step where we copy a subset of assets, and makes
it so that FilamentApp hands out a "root path" for assets. For now this
is determined based on the location of the executable. This allows
developers to launch samples from any CWD.
Closes#11
* Restore asset copy to build.
computeLightTree() takes a list of light as
a bitfield and produces a depth-first
binary tree array that can be used to efficiently
check which lights volumes contain a given z
coordinate in screen space.
Currently computeLightTree() produces the array
locally on the stack, which isn’t useful, but
before we can make use of it, a lot of other
things have to happen.
