Discussed this feature with Mathias, we decided to create
MaterialInstance Java wrappers on the fly, and create Material Java
wrappers lazily. This is simple and avoids caching the wrapper objects,
which might otherwise lead to complexity and bugs.
Note that gltfio creates material instances behind the scenes, so this
feature is particularly useful for gltfio clients.
Previously we used the <T=float> template instantiation of setParameter
when the client specified FLOAT4. This resulted in the lower layer
adding needless padding, thus causing a buffer overflow.
Moreover the JNI code for this was somewhat cryptic because it casted an
enum value to an int, then added 1 to compute the size. We now use
a switch statement to improve readability.
This issue was discovered (and the fix was verified) with the upcoming
Android port of the bloom demo.
We now never process mirroring or mipmaping with multithreading
it's just not worth it given the overhead of the jobsystem.
We also require 64 lines per job, below that, we only multithread per
face (6 threads). This should probably depends on the sample count,
but we don't have this facility yet.
Special case downsampling for mipmaping.
This alone improves performance by 2x for small cubemaps (e.g. 16x16).
This adds a utility function on IndirectLight populate the reflection
map from an environment at runtime. This performs some processing
similar to cmgen, albeit at a reduced quality.
In commit d955e73 we changed the default IBL from RGBM to RGB, but we
kept its internal format of RGBA8. Since the internal format is not
compatible with the data format, we see GL_INVALID_OPERATION during the
texture upload.
This is a single-pixel black texture, so the format does not really
matter, but this clears up a GL error seen on some platforms.
In commit d955e73 we changed the default IBL from RGBM to RGB, but we
kept its internal format of RGBA8. Since the internal format is not
compatible with the data format, we see GL_INVALID_OPERATION during the
texture upload.
This is a single-pixel black texture, so the format does not really
matter, but this clears up a GL error seen on some platforms.
- RGB_11_11_10 is exported in a RGBA PNG file where the 4 channels are
used as a uint32 storing a RGB_10_11_11_REV pixel.
We use the .rgb32f extension, and those PNG files contain garbage
when seen in a PNG viewer.
- This is now the default for the -x option.
- compressed KTX files don't encode RGBM, which means they can't
support HDR, unless an HDR compression scheme is used.
* Make CMake 3.10 the minimum version, add LTO option
* Install a newer CMake on Linux CI builds
* Update LLVM and Cmake on Windows CI
* Update build/windows/ci-common.bat
Co-Authored-By: Ben Doherty <benjdoherty15@gmail.com>
* Update formatting
* Apply suggestions from code review
* Update build/windows/ci-common.bat
* Update CMake
* Switch Android projects back to CMake 3.6
⚠️ breaks materials
There used to be a constraint that ibl cubemap needed to be
256x256. This constraint is now relaxed. IBL cubemaps can be any size.
We also add 16 float4 of padding to the frameUniform, which brings
its size to 1 KiB, the idea is to prevent more breakages in the
future.
For now this uses gltfio in the ubershader configuration in order
to avoid the filamat dependency. Note that we have not yet done a size
analysis of the `gltfio_core` library.
New Kotlin-based sample app is forthcoming.
NOTE: Should we expose Engine::getEntityManager() to help with issues
like this? e.g. it would allow gltfio to extract it from the engine
rather than consuming an additional argument.
This fixes an entity id collision that I saw when building gltfio into
its own DSO (e.g. on Android). Since it is a separate executable it has
its own EntityManager singleton. This id collision was causing unwanted
entities to be added to the scene.
No need for a proper library, this is just a common location to simplify
JNI bindings in other projects like filamat and gltfio.
There is no need to move the one Java source file (`NioUtils.java`)
since downstream libraries will have a dependency on Filament, and
FindClass should work fine.
