Currently, I’m loading a (rather large) CubeTexture from a .dds file and my application stalls for some seconds after applying it to the environment. Profiling shows that most of the time is spent in ConvertCubeMapTextureToSphericalPolynomial, which is to be expected, but since the browser is stalling, I have no chance to show a progress bar or any other indicator.
Is there any way to make this process faster or at least more responsive? Can WebWorkers be of any help here?
You should use .env files to avoid this processing timehttps://doc.babylonjs.com/how_to/use_hdr_environment#creating-a-compressed-environment-texture
Looks like an obvious solution, thanks! But I have a followup: is .env more or less an internal representation, specific to Babylon.JS (which is my takeaway from the deep dive chapter) or is this some standard you are following? My HDRi files are actually converted to .dds from .hdr (not quite sure what the internals are) with a tool called cmft which I would gladly remove from the pipeline. There is probably no tool yet to batch convert from .dds to .env?
Yeah you are right. We are working with Khronos Group to come with a format for IBL but so far this is not yet done
Again a followup: is there a trick to make the .dds and .env environment look the same at the same microsurface setting? On the left is the .env, on the right the .dds it has been generated from. The background is different, while the reflections seem identical (but the problem is probably more obvious on flat surfaces than on spheres.
Pinging @PatrickRyan for help
@rassie, when converting your DDS to an env, we are using PNG compression though I don’t remember if we are down sampling the source images at all. @sebavan will be able to confirm that. What it looks like to me is that your cube textures have been resized or quantized in the compression. For the reflections on your mesh, a high resolution cube map isn’t necessary and we balanced env with that in mind. The trade off was always to perform well on low end devices without a dip in the quality of the reflections on the mesh surface.
The skybox was always a secondary concern because you can use whatever skybox you want in your scene. Granted that is a secondary download, but you don’t need to compute anything from a skybox and can use a resolution that is better for rendering large in the scene. While we make it easy to use your IBL image as the skybox for your scene, I’ve never been a fan of doing it because I author IBL content to be fast rather than being of the quality to render well as a skybox.
What browser are you using and could you share a repro ? I would expect small diffs but usually imperceptible but not the kind you have here.
Actually we seamlessly switch in the sandbox one and another.
The mip maps should be generated as they originally are in the dds, we are not rebuilding them so this is highly unexpected that the quality would change as much.
@sebavan I’m using Chrome. I’m made you a zip file with the scene and both .dds and .env files for the sandbox. The resulting screenshot (left: DDS, right: .env):
You should be able to see the difference by reducing microsurface of the skybox from 1.00 step by step by 0.01 until you see a difference, which happens at different values (about 0.95 (dds) or 0.94 (env)). Changing the roughness on the pbr material is also reacting on different values.
PS: In the screenshot I have different values for roughness on the pbr material, which was unintended, but the main problem is visible in the skybox.
Thanks for the repro !!! That is actually a great catch, the anisotropy was wrongly set on the env version. I ll fix it ASAP.
Fixed it will be in the next nightly
