I’m exporting a scene with the unity exporter. this time it’s a rather dark scene and i notice that i’m losing part of the emission when loading on babylon.
from what i understand the unity lightmaps are used as shadow maps in babylon. so it seems that the shadowmap comes after the emission map and hides it underneath. is it what’s happening?
how can i solve that? @MackeyK24
unity
babylon
It looks like you’re baking the light map into an HDRI that’s then supposed to serve as the environment texture for the scene but first have you tried toggling the option in the Inspector that says “use light map as shadow map”?
If that one-shot fix isn’t the ticket, then I would check the Scene properties to make sure and assign the environment map texture - try using the emitted HDRI from Blender if possible. Ed: maybe also make sure you’ve selected the options to emit normal maps, etc from Blender
Try fiddling with the intensity and see if that helps, but you may need to create a Glow Layer to bring out the emissive channel, if you haven’t already
HTH!
thanks for your input
actually no, the baking is done with using 8bit png (it’s all automated by the unity exporter). i tried to play with that “use lightmaps…” toggle but it doesnt do anything.
i read about “environment texture”. i don’t think that it is what i’m trying to achieve. from what i understand, the lightmaps come just as a second set of uvs (i’m not very good in all of that. i may be wrong)
Can you please send me the scene?
Looking at the two images again, maybe a/part of the problem is that BJS emissives don’t contribute to environment lighting, whereas they do for Unity?
This could potentially be solved by placing a non-directional light inside the sign, using the letters as a negative mask that allows light to shine through them, although you’ll need to make sure the sign mesh is properly setup to act as a light box
So @metafred i checked out your scene using the new upcoming Babylon Toolkit. I have an option in the toolkit to patch the shaders and inlude emissive lighting when using lightmaps
Wahh you answered many long-term interrogations I had in a single video.
That override color checkbox, so useful.
Thank you for the video, much appreciated !
Yo @sebavan / @Deltakosh … Shouldn’t this be the default behavior for the Babylon Shader… The emissive light should after the shadow map. This is how i am patching the shader
pbrBlockFinalColorComposition
finalColor.rgb*=(lightmapColor.rgb+finalEmissive.rgb)
I dont think it does after lightmaps.
The only way i can get emissive lighting when using lightmaps (as shadowmaps) is to patch the the shader in the pbr final block
finalColor.rgb*=(lightmapColor.rgb+finalEmissive.rgb)
Ohhhhh with Light map as shadow map !!! you are fully right and it looks like a bug… I ll fix it tonight
also @MackeyK24 should it not be: finalColor.rgb = finalColor.rgb*lightmapColor.rgb+finalEmissive.rgb; instead ???
Same thing as using *=
not really as one will also multiply finalEmissive.rgb with finalColor.rgb which I believe we should not 
This is literally what i been using in the pbrBlockFinalColorComposition
finalColor.rgb*=(lightmapColor.rgb+finalEmissive.rgb)
And it has been working great as i show in the video
@sebavan … so your just moving the addition of the finalEmissive to after everything else, including lightmaps
Yes, the emissive contribution is like an additional light (it is light emitted from the material), which is added in the end to the contribution of the other sources of light. It is wrong to modulate it with the light calculated from the other sources. Imagine that the latter is 0 (because there is no source light in the scene): you would end up with no light at all whereas you should in reality end up with the emissive part.
out of interest, what is the difference between a lighmap (non-shadowmap) and an emissive map? Doesn’t this code change make them the same?
Or am I missing something?
The main difference is “mul” or “add”
The code only fixes the part where emissive was multiplied as well and it should not.