Black details in Babylon Viewer but fine in Sandbox

We are using the Babylon Viewer to display 3D models of our products on our website. It works great, but there is one issue. The models look a lot less detailed when compared to the Babylon sandbox when using the exact same model and files.

The main issue is that certain details are black in the Babylon viewer. For example the hinges should be chrome in color and they are in the sandbox, but in the viewer they are black. In general the quality of detail is much better in the sandbox.

Here is a link to a screenshot to demonstrate the issue and difference:

Left is our site, right the sandbox.

I am pretty sure this has to do with config settings, likely the lightning, but I can’t figure out how to improve this.

Can someone point me in the right direction to improve the model rendering detail?

These are my current Babylon.js json config settings:

	"templates": {
        "loadingScreen": {
            "params": {
				"backgroundColor": "#ffffff",
                "staticLoadingImage": ""
	"camera": {
        "beta": 0,
        "alpha": 2.4
    "environmentMap": {
        "texture": "",
		"rotationY": 0.5

Here is a link to the 3D model on the site:

Here is a link to the 3D model .bin and .gltf files in case you want to check them in the sandbox:

The environment map:

Again, I hope someone can explain the difference and point us to the solution.

Thanks in advance,

Yep this looks like a environment map difference, I’m sure @PatrickRyan will have great words on this subject :smile:

@Jaap_Huisman, in looking at your file, the environment DDS you are using is the problem. DDS files are hard to debug due to the limited software packages that open them but let me walk you through what I am seeing. This is a sample file showing metallic and dielectric materials ramping from roughness 0 to roughness 1. This is loaded in the sandbox with the default environment:

Note that the left-most spheres reflect the environment cube exactly and the varying roughness is a good indicator of the mip maps in the file. Now when I drop your environment on the scene, this is what renders:

Looking at the environment texture, we start to see some problems:

The file is passing transparent pixels to most of the scene. In comparison, here is a DDS file that I had baked long ago from our standard studio environment. This is also the +X part of the cube so we are looing at the same direction in the environment:

The big difference here is that if you look at the type in the files, your environment is an unsigned byte and the default studio is a 32-bit float. I’m pretty sure the issue here is that the format of your environment doesn’t match the type that the shader expects. This could be simply choosing the wrong conversion to DDS.

I was able to open your environment in GIMP, but saw exactly the same as what was displayed in the inspector:

I would suggest a slightly different approach to your IBL. The first would be to move away from DDS enviroments as tooling is disappearing for it. My go to package had been Lys for many years, but in the later versions of Windows 10 and now 11 the software won’t work. Knald seems to have basically dropped support for updating the software and any emails to the website go unanswered. Instead, I would suggest using the .hdr to .env conversion method for your IBLs.

If you drop any equirectangular .hdr file on a model in the sandbox, it will load the file and do the necessary conversion for you. You can then export to .env from the sandbox which will reduce the file size for you and author a format that is tailor made for our shaders. The .env file won’t open anywhere else, so retaining the original .hdr file is important. But you will also benefit from a small file size.

For example, your DDS is 8mb. If I download a 2K .hdr from polyhaven, that file is just under 6mb. Dropping it on the sandbox loads the .hdr to the scene:

Then choosing the tools section of the inspector, you will see an option under scene export to generate an .env file.

The .env generated from that file is 900k. This will give you a much smaller download and still retain the quality you need from your environment. I hope this helps, but please feel free to ping me back with more questions.


Thanks a lot for your deep insights @PatrickRyan!
This is of great help.

I will pass this info to our 3D model designer, as I am just the web developer.
I thought it had to do with config settings which I could change and improve, but modifying the environment file is out of my scope.

I have a few more questions if you don’t mind:

  1. Just to be sure: this problem has to do with this environment .dds file, correct?

This is the the source for the reflection in the mirror.

I’m asking this, because there is also another .dds file loaded:

This is the default viewer skybox that you can see around the product.
But this one is not the problem, correct?

  1. Would you be able and willing to lend your services to us and help generating a proper environmentMap file?

You have some great insights in this field and we had been struggling creating a proper file that can be used on the web. We do have the original HDR file, but it had a big file size that’s not suitable for web. We had been using different tools to convert these into smaller files. Some didn’t work, some were low quality and some were too big. The current file was our best result. For mobile we have a smaller file.

For us it’s essential to see a bathroom reflection in the mirror product that is of decent quality, but also suitable for web.

Please let us know if you would be willing to offer your service to us.

Thanks again,

@Jaap_Huisman, happy to help with more questions. To be honest, when I look at both DDS files, I am seeing the same issue that they seem to be formatted in a way that is just alpha. Again, DDS is a very hard file to debug and I would probably advise to move away from it for this reason. If the file is the file you are using for your skybox in scene, I’m not quite sure how it’s working without looking at your code. Typically for skyboxes, we pass a group of 6 images and the scene assembles a cube map for us. You can rely on the scene to create a skybox for you if you are setting an IBL as the environment, but you can always just create your own.

The same can be done for reflections if you have a mirror surface. Typically for material reflections, you are good enough with the IBL reflections in PBRMaterial even if the cube faces are only 256 px per side. This is mostly due to the complexity of the model and relatively low percentage of a material that is reflective like chrome. A mirror is a different issue, however. Since a mirror is usually a large flat surface intended to reflect the environment, the small 256 px environment cube texture is too small and shows pixelation. This is where you would want to pass a separate reflection cube texture. This is an LDR image set to make up a cube like a skybox would. This texture gets assigned to the material as the reflection texture and then your lighting calculations will take the environment texture into account, but the reflections pull from the reflection texture. This allows you to get faster lighting calculations with the smaller environment texture, while still getting higher quality reflections. You can also benefit from image compression of jpg with your reflection textures since you do not need any HDR data.

This thread dealt with much the same problem you are looking at and would be worth a look.

My suggestion for your tool chain would be something like this:

  • Open the sandbox and drop your mirror asset into it
  • Drag and drop your .hdr texture onto the sandbox to load and convert the .hdr into an environment
  • Open the inspector and click on the tools tab
  • Choose Generate .env under scene export
  • Go to 360Toolkit - Convert equirectangular to cubemap
  • Choose the six image option for output
  • Upload your .hdr image (note that for larger cube images, you will need a 4k or larger image)
  • Export your images as jpg
  • Rename your images according to what Babylon expects, i.e. filename_px.jpg, filename_nx.jpg, etc.
  • Create your environment with your .env file
  • Optionally, create your skybox with another set of skybox textures. You can follow the same instructions as above
  • Create your reflection texture and assign it to your PBRMaterial

This should get you where you want to be. Note that when creating your reflection texture, you don’t need an .hdr file. You only need an LDR equirectangular image to convert to a cube map. The important thing here is that the image can be projected to be spherical without seams or lost information. Any method for creating an equirectangular image can be used.

Hopefully this gets you a clear path to a workable pipeline. If you like, you can create a playground with a sample asset and environment set up and I can take a look at any problems you may have. Working with playgrounds is always easier since I can see exactly what you are doing in your code and make suggestions. Let me know if you have more questions.


Thanks again for your time, insights and advice.

Can I reach you somewhere? Couldn’t find a PM option here on the forum.
Would like to ask if you would be willing to help us out as a one time job/assignment.

@Jaap_Huisman, you can get to direct messages by clicking on the avatar of any user. If you don’t see that option, you may need to raise your trust level with discourse (a system to avoid spam). You can find the guidelines at Understanding Discourse Trust Levels. You simply need to meet trust level 1 to send PMs.

Hi Patrick,

Sorry for the late reply @PatrickRyan.

It seems you were right: the conversion from .hdr to .dds seems to be the problem.
I have loaded the original .hdr file into the sandbox and now the metal reflects in perfect colors! See screenshot below:

It’s great that we have identified the issue and cause, but unfortunately your suggestion of using the ‘export environment’ to .env will not work for us.
The problem with this is that the exported file is of really low quality, as can also be seen in the screenshot above.
It seems it greatly reduces the file size and quality. For our environment file this is a problem, because we need to show a good/decent quality bathroom reflection for our mirror products to appeal to potential customers.

This was the reason we looked for other ways to convert .hdr to a useable file of better quality.
We tried different tools, but the only one that gave good results in terms of quality and file size was Lys, where we bought a license and created the .dds files.

Are you aware of any other ways to convert the .hdr file to a better quality .env file?
I wanted to look into your other suggestions, but this tool seems to be down for me:

You asked me to setup a playground, but:

  1. This is a bit difficult for me to setup
  2. This may not be necessary as the issue can be replicated in the sandbox

Here is the original .hdr file:

The other model files (.bin and .gltf) can be found in my original post.
You can load theses three files in the sandbox to replicate the issues: the reflection of metal is fine, but the quality of the bathroom environment is poor.

Hope you can help.

Thanks again!

That’s because the generated .env file is only of dimension 256x256.

You can generate a bigger file with this PG:

Note however that there is a CORS security problem, you will have to host the file somewhere else if you want to avoid these problems.

I tested it locally to avoid the CORS problems, and with a 1024x1024 environment file you get:

instead of this with a 256x256 file:

Be aware that the environment file is now 8.2Mb, though (instead of 636Kb)!


Thanks a lot @Evgeni_Popov, this fixed all our issues!

Managed to create a 512x512 2mb file for mobile as well.
The files are indeed big in size, may look for a slightly better size/quality balance ratio later.
But for now very happy.