If .env Environments and textures could be packed within a .babylon file without external references, this would solve all of my current issues.
Can this be made a reality?
Thank you
cc @alexchuber
1 Like
Using which exporter ?
BabylonJS Sandbox or Playground using the âExport to Babylonâ button.
1 Like
I made this post, and in the wrong place, not realizing there was already a Feature Request open for basically the same thing all the way back in 2020
although⌠it turned into an entirely different discussion with lots of code.
iâm just a humble artist that wants to share his art efficiently =)
No worries, youâre in the right place! The .babylon serializer supports serializing textures, so if thereâs an .env not being serialized, that sounds like a bug. Let me have a look 
2 Likes
Ack, itâs not exactly a bug-- it would be a new feature. Only the Texture class can encode its image data in the Babylon serializer, not the CubeTexture class or its relatives.
Before I go invent a new mime type to base64-encode .env files, maybe @PatrickRyan knows a better way to pack these textures?
1 Like
Packing textures in the GLB worksâŚ
Maybe it would be easier to allow use of PNGs or JPGs in equirectangular layout as the environment and IBL texture..?
Just grasping at straws here ;D
@alexchuber and @staub, an .env file is an edge case here when using the term âembed texturesâ because itâs not technically a texture anymore. Itâs a Babylon-specific cube map with a special encoding to retain HDR values from an IBL in a very small file. Support for packing an .env in a glTF wonât go anywhere without a custom extension as the format only applies to our engine so would have get support for adoption across the whole consortium since many different engines are represented. Custom extensions donât mean across the board adoption and any viewer not using Babylon wonât be able to use it anyway.
For the .babylon scene file, however, there is a case to make for the feature to serialize the .env into the .babylon file. The challenge here is spending the resources to implement it since the .babylon format isnât nearly as common as .gltf in usage. The way around the limitation at the moment would be to use .hdr files for your environment which will need to be pre-computed into an environment texture at runtime. Since hdr is a Texture class, it should serialize into the file. However, you will take a hit at runtime as this is more expensive. For look development and moving quickly, this may be a decent trade-off and then make a move to manually convert to an .env in the last mile. Not sure if this will help your pipeline, however. The real solution is to implement the feature request.
1 Like
Maybe it would be easier to allow use of PNGs or JPGs in equirectangular layout as the environment and IBL texture..?
The only issue with this is that pngs and jpgs are only 8-bit files and only support low dynamic range which means no value above 1.0 is stored. High dynamic range images - those with values possibly in the tens of thousands - are 16 or 32-bit files and are needed to render as an image-based light. So even if you have a LDR file in an equirectangular format, the data wonât allow you to produce lighting just from the image. In this case, .hdr is the format to use, but it comes at a cost as listed above.
2 Likes
Thank you Patrick and Alex
The second bit is the only thing Iâm worried about⌠packing all of the environment info in the babylon file. And I fully understand the limitations with using non-hdr images as environment textures.
If the .env format can be exported as part of the .babylon file, thatâs all I need⌠as Iâm using the babylon viewer for presentation.
I donât want to involve the entire 3d graphics consortium for my humble request: support for babylon inspired formats within babylon files without external references.
Iâm perfectly ok with packing the standard textures in my glTF/glb as is working now. I would just like to also be able to export the environment because it makes such a big difference in presentation.
One of the reasons I found babylon was because of glTFs lack of support for custom backgrounds.
Thanks again!
2 Likes