However, it does not help for mimapping, as the texture is still a (half) float texture.
To be able to use mipmapping, I think one should not make the BABYLON.RGBDTextureTools.ExpandRGBDTexture(currentLightmap); call and let the shader do the decoding. However, I wonder if the mipmapping process generates valid mip maps for RGBD encoded data…
Also, I think it’s a good idea to still have the ability to create a texture from a .hdr file thanks to your .hdr loader.
Woa guys, I knew Babylon’s community was famous for being very helpful but I didnt expect this much!
@sebavan This seems to be the solution! I am going to test it out and come back with the results, but its going to take me some time, I am still getting use to javascript in general.
@Evgeni_Popov It does! My previous comparison is using ACES tone mapping if I remember correctly, I am going to keep tweaking it once I get @sebavan method going.
Removing the line means you do have mipmapping: with the line you don’t have them.
However, it also means a little more work in the shader because the rgbd value has to be decoded each time the lightmap is accessed. However, compared to the other stuff done by the PBR material, the extra work should be negligible.
@sebavan: I think there’s a small bug somewhere as the inspector is still saying that the texture has mipmaps when decoding the rgbd to a float texture => the generateMipMaps property of the internalTexture is not reset to false?
Hey, I am extremely new to Babylon and I found this thread when doing research on displaying residential units. Please forgive me if I am missing something obvious.
I am also not sure if I should ask this here or open a new thread
I have a question regarding the display of the used model. When comparing the output of: https://www.babylonjs-playground.com/#8EGGW2#2 and let’s say https://www.babylonjs-playground.com/#8EGGW2#9 the edges seem to be rounded (it all looks more natural). Does this all come from the use of Lightmaps or are there other tools/features being used to achieve that effect?
I tried to understand the Code from the Playgrounds but did not see where this ‘roundig’ effect is originating from.
We have the very same problem with dark lightmaps.
Right now I’m using Nuke in order to tonemap the lightmap to force it fit inside the 0-1 range of 8bit PNG files.
You mentioned that RGBD fancy thing and we would want to understand that magic. Investigating a bit, it seems the “D” of that RGBD format is intended for depth, so personally I can’t understand how that would make PNG format to have broader luminance range.
Currently, the lightmap is generated in HDR file format, so we can do whatever is needed to it but to save it to PNG format and retain luminance values.
You wrote about that playground that converts HDR files into PNG RGBD format. But I can’t make it work.
Is there another way to create such wide range PNG formats?
Nevermind, I managed to make it work.
I wonder, though, if the resulting PNG can be converted to JPG as I don’t know if JPG supports RGBD formats. Because our converted PNG is like 20mb in size, and that’s pretty much.
Well, I’m completely new to lightmap generation (I come from offline rendering, so no need for them at all), but I thought ONE lightmap for everything in the scene would be appropriate, that’s why I use one 4k file for it.
@sebavan Please excuse my late response. I looked at the scene again and came to the conclusion that the effect I was experiencing has to originate in the lightmaps that are used.
It seemed to me as if there was a bumpmap being used or something similar that changes the actual geometry of the mesh, but it is just the effects of the Lightmap tricking my brain