When exporting it as a glb file, the light component seems to have beenreset, as the only light I find is a directional with its position/direction reset and no shadow generator enabled. Sometimes, there even isn’t any light generated. I don’t know what’s going wrong.
Also, the lighting appears wrong when I import it via code in my project. The ambient lighting is gone, making the shadows pitch-black. is there any way to recover the post-processing/default lighting from the sandbox?
.glb file is a standard format for exporting 3D assets, including basic shaders, as weel as embedded textures. It’s not related to Babylon JS.
You cannot use .glb to store a specific Babylon JS scene configuration (such as some settings about cascade shadow maps or whatever), as well as in Blender you cannot save complex custom materials or blender-related stuffs in .glb
Maybe you can explain a bit more what you are trying to achieve ?
For example, on my side I never use .babylon format, not because it’s bad or whatever, but because for the usage I do of BabylonJS, I prefer keeping everything proper to 3D (assets, textures) in some binary files, and anything proper to BabylonJS (scene setup, whatever) in pure Javascript on the client side.
I kind of expected that answer, sadly. I wanted to use a glb file to keep the size of my scene as small as possible, but used a babylon file to add lights and shadows without having to do it by code. Not that I can’t do it; I’ve actually tried to implement it, but the performance was so bad I looked for alternatives. From what I’ve seen, the shadow generator in the babylon file gave me the performances I wanted, and so I went for it.
If you goal is to reduce storage, most likely the weigth comes from the assets themeselves (3D geometry, textures)
The other stuffs, such as the scene configuration, when you store it in a .babylon file, I’m not 100% sure (let’s say 99% ) but I would say it’s the same than doing it by code in Javascript side. I guess that the .babylon file loader, just reads the .JSON file and executes some JS code to build the scene, based on the content of the JSON.
So at the end, I see no reason why storing some configuration in a .babylon file would give better performances than executing the same code manually
I’ll wait for BJS devs to see this topic and eventually bounce on it
Yeah, my scene is really heavy, I’m working on optimizing it. I’ll probably go back to writing the shadow generator myself as well, sinc this seems like the most flexible option and would allow me to use a glb file.
But wait, if the glb file cannot store such information, why does the sandbox even have a toggle to export lights or not? It’s a bit confusing.
I know that glb does support some basic lighting config. So, I guess it’s here to take advantage of it, but in the limitation of what GLB is supporting, VS what is specific to BabylonJS implementation itself…
Hi, to reproduce it, I simply import a 3D model, add a directional light, and export the scene to glb. Then, I reimport that glb scene and check the light’s data in the inspector. It doesn’t matter if it’s the sandbox, playground or my project, all of them display the wrong transform for the light.
The position and direction of the light isn’t lost. The loader loads a light from a glTF by creating a transform node with the light’s transform as the parent of the light.
That said, I noticed the light direction is wrong, which is a different problem.
) but I would say it’s the same than doing it by code in Javascript side. I guess that the .babylon file loader, just reads the 
