HDR , Dds , Env files

Hello , i am a 3D Modeler and i am new in the Babylonjs world .

Usually in 3D software we use .Hdr files , so i am wondering :

1-What is the difference between .hdr , dds , and .env ?

2- And what is the best extention to use ?

3- Also how to convert .Hdr file to dds or .env

I already check this link Use a HDR environment (for PBR) - Babylon.js Documentation , but i dont find the answser for my question !


Hi Propido,

Welcome to Babylon! As this is about 3D modeling/export, I’ll have to call for help from subject matter experts @PatrickRyan and/or @Drigax for part of it, but I can at least answer some of you’re asking.

  1. .hdr is (apparently) a lossless image format for storing high dynamic range image data; I’m no expert, but I’m guessing that the focus of is on quality as opposed to compression, meaning it’s likely good for source content but not as ideal for shipping over a network to be displayed in real-time. .dds is a DirectDraw Surface; this format is designed specifically for use in real-time rendering, but it’s a Microsoft-specific type that can be tricky to use outside of the Windows ecosystem. .env is, as I understand it, a file type introduced by Babylon as a more Web-friendly alternative to .dds; a more precise description is in the second paragraph of the documentation section I linked to, but it’s basically just a pre-mipped cube map of PNGs along with a little bit of metadata.
  2. As alluded to above, it depends on the use case. If you’re trying to store high-quality image data you’ve captured so you can make use of it later, you probably want to keep that in .hdr. If you’re working with Windows-focused game dev tools and want to use your texture specifically in a real-time Windows native application, .dds is probably the canonical choice. However, if you want to use your texture in a Babylon.js app that will be retrieved from the Web and run on a variety of devices/platforms, I think .env is probably your best choice.
  3. Creating .envs is covered in a different section of the documentation you read: Creating a compressed environment texture. That workflow will allow you to go from .dds to .env. Going from .hdr to .dds is a separate step, and either PatrickRyan or Drigax will probably know more specifics than I do, but broadly speaking you just need a tool that can import .hdr and export .dds. A quick glance around the Internet indicates that there are plugins to make Photoshop do this, and that GIMP might be another option. Also, if you search for, “convert hdr to dds,” there are quite a lot of sites that claim to be able to do this for free.

Hope this at least helps you get started!


@Prodipo, let me expand on what @syntheticmagus said about the file formats.

  1. .hdr is one of the few file formats that has an option to store 32-bit data which is necessary for high dynamic range. The .dds file format is one of those options for 32-bit data, but also allows storage of mip-maps which is how we simulate roughness in our PBR rendering. Rather than calculating a specular lobe from the roughness value of a surface and sampling and averaging many pixels from the IBL, we instead correlate the roughness level with a particular mip level and do a texture look up from the .dds. This is much faster than all of the extra calculation which is a must for rendering on low end devices.

  2. In your normal asset creation workflow, you would continue to use .hdr files in your DCC tools. The .env format is specific to Babylon IBL for rendering. The .dds format can be used for either cubemap environment lighting or simply as compression for your model textures. If you are looking to compress your model textures, you can use the .dds format and a tool like the Nvidia Texture Tools Exporter can compress your textures in either a stand alone app or a plugin for Photoshop. Syntheticmagus is right in that the .dds format is not the easiest to use as the tools to save and open it are limited.

  3. For environment IBL, you will always need to pre-compute your .hdr to align with our PBR calculations using Lys, preferably as it matches exactly with our algorithm. IBLBaker can also be used, but is not an exact match for our algorithms. In a pinch it can work, but the lighting will be slightly different though may still be acceptable. The link you mentioned do contain the exact steps in each software to do the conversion. Unfortunately, there just aren’t more options out there than these two that we have found that can work.

If you have specific questions about the conversion process in those two packages, I can help answer them, but start with that documentation page as your first stop. Those will get you to the .dds file and then further down the page shows you how to use our inspector to save out an 8-bit RGBD .env file which will save you a lot of file size to speed download. Realize though, that you won’t be able to easily open that .env file for edits as it is basically an optimization only for file size so will only work for rendering in Babylon.js.

The best workflow is to keep your .hdr source file for edits and pass any iterations through Lys or IBLBaker and then convert to .env in the Babylon.js inspector each time you need to make a change. This will give you the best results rather than trying to edit a pre-computed mip chain in the .dds or deconstructing the .env file.