Closed rawnsley closed 2 years ago
Our rendering is correct:
You can see automated comparison between Filament and other glTF renderers. Aside from specific (known) differences with some extensions, they all compare roughly the same: https://modelviewer.dev/fidelity/
It seems like you are not generating/loading your IBL properly. The easiest way to properly load an IBL is to use cmgen -f ktx -x path/to/output envmap.hdr
and then to use KTXLoader.createIndirectLight()
. Example:
private fun createIndirectLight() {
val engine = modelViewer.engine
val scene = modelViewer.scene
val ibl = "default_env"
readCompressedAsset("envs/$ibl/${ibl}_ibl.ktx").let {
scene.indirectLight = KTXLoader.createIndirectLight(engine, it)
scene.indirectLight!!.intensity = 30_000.0f
viewerContent.indirectLight = modelViewer.scene.indirectLight
}
readCompressedAsset("envs/$ibl/${ibl}_skybox.ktx").let {
scene.skybox = KTXLoader.createSkybox(engine, it)
}
}
@romainguy That comparison site is super useful, but my screenshot is straight from the sample-gltf-viewer not my own code. It uses an IBLPrefilterContext to generate the IBL reflections object at runtime rather than cmgen.
It looks fine there as well:
Oh. Perhaps it is device specific? I'm using a Pocophone F1 and a Snapdragon XR1 based VR headset and I get the same issue on both I think. I'll do some more testing to try and narrow it down.
Is there any easy way to dump the cubemap textures that IBLPrefilterContext spits out? It might help debugging.
You could try and dump the textures but they are in R11G11B10F format, so you won't be able to look at them easily. The best way to inspect them is to use a GL debugger like AGI or vendor tools like Adreno/Snapdragon Profiler.
Apologies for bringing this one back after so long. I can't find a single hardware device where this works like it does in the emulator. Is anyone able to confirm it working on a real device?
In case it isn't clear from the screenshots, the specular component is too sharp and the diffuse component has a much more defined highlight than the reference renders.
This is the reference model roughness.glb.zip. It's non-metallic spheres with roughness varying from 0% to 100%. The background IBL is from three.js, but I see the same thing with other HDRIs, particularly when they have very bright elements like noonday sun.
Looks fine with the built-in IBL:
The issue only shows up (Pixel 6) when prefiltering an IBL at runtime:
Looks like it's not a rendering bug but either a bug in libibl or how gltf_viewer uses it.
Offline generation looks fine (desktop render):
Thank you for reopening this, we caught a bunch of problems on mobile.
This is a little subjective, but the reflected light from an IBL on a 100% rough PBR material feels off. It also differs significantly from an equivalent three.js render.
Here is the filament render on Android using the gltf-viewer sample and the Venice HDR IBL Here is the equivalent in glTF Viewer using three.js
The sample model has 100% roughness and is non-metallic, but the filament render definitely looks shiny. Other objects with 50% roughness are almost as shiny as those with 0% and the effect is particularly pronounced on HDR images with small bright points of light.
My guess is that there's something wrong with the IBL cubemap, either the initial generation or the eventual roughness-based selection, none of which I understand very well. I was trying to investigate this assumption, but I got stuck working out how to write the various IBL cubemaps out as bitmaps so I could look at them.