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.
KtxBundle is basically an in-memory representation of a KTX file.
Our primary motivation for introducing this class is to have a
structured container for block-compressed textures.
Note that this class is defined in libimage rather than libimageio.
There are several reasons for this:
1. The texel data in a KtxBundle is not meant to be decoded by the CPU.
2. It has no dependendencies on any libraries (stb_image tinyexr etc).
3. We wish to use it with WebGL, which needs to avoid using imageio.
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.
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.
According to the spec, an attribute declared as an integer (ivec* or uvec* in the shaders) but be bound using `glVertexAttribIPointer` instead of `glVertexAttribPointer`. This means we were not binding bone indices correctly for GPU skinning. This issue was hidden by lenient drivers, particularly on Android.
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.
This does not add any build stuff or new sample code yet, it just does
some prep to our C++ codebase:
- Similar to Android, WebAssembly will not be using BlueGL. We were
using a mixture of #if and #ifdef when checking for the existence of
certain GL prototypes, but the latter is what we want in order to
build robustly with any GL headers. (We still perform run-time checks
for extensions, this doesn't change that.)
- Add a trivial ContextManager, does a bit more than Dummy since it
needs to create an actual driver. This doesn't get compiled yet, it
just adds files to the tree.
- WebAssembly does not support mmap, execinfo, or asm volatile.
* 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
* 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.
* Add option USE_EXTERNAL_GLES3
Causes gl_headers to use GLES, even on desktop.
Causes all ContextManagers to be elided;
users are expected to provide their own.
* FrameUniforms.resolution gets consistent precision between VS/FS
* Introduce mipgen frontend.
For now this is fairly simple although it does let you choose a filter.
Another cool feature is that an HTML file is generated which makes it
easy to review the generated miplevels.
This does not expose the Boundary enum to users because it has not yet
been implemented in the core Image library.
* Fix up mipgen per code review.
* better froxel records compression
We used to compress froxel records by reusing the
previous record on the left if it was identical,
now we additionally check the record above if
that fails.
In practice this saves 10% to 30% space in the
froxel record buffer, which is a scarce resource
for us.
e.g. if a light occupied 3x3 froxels in a given
z-slice, without compression 9 records would be
used, with left-only compression, only 3,
and with left+above compression, only 1.
* use size_t for in and out parameters
this helps the compiler in many places, not
having to cast from 64 to 32 bits.
* implement bitset’s any() and all() operations with NEON
* empty froxels are a common case, handle it first
This changes the layout of the froxels data
structure in the GPU so that the major axis
is the Z axis instead of X. The idea is that
within a given screen-space tile, we have a high
probability to access froxels at the same x/y
but different z.
This is turned off right now, as it requires
a change that breaks existing compiled materials.
* Add material_testbed application
This application can be used to automatically vary material parameters over multiple frames and capture each frame as a PNG file. This makes it easier to test/compare/etc. It's also useful to generate documentation examples.
* Rename material_testbed to frame_generator
* JobSystem now automatically free Jobs
Until now Job allocation used a linear allocator
strategy which required to “reset” the JobSystem
periodically — typically once per frame in
filament.
This is no longer required. We use a pool allocator
now, which doesn’t add much overhead. It does
use a spin-lock for thread-safety though, since
we assume very little contention, this shouldn’t
be a problem.
* Thread Safe Object Pool Allocator
A lock-less, thread-safe object pool allocator,
now used for storing JobSystem’s jobs allocations.
This gets rid of the spin-lock introduced in the
previous cl.
