All baked textures (.hdr) are in white with correct lighting when I imported to Unreal engine

[YahyaNawir]

All baked textures (.hdr) are in white but correct lighting when I imported to Unreal engine, I was successfully baked the lighting in Blender 2.9.1, I created simple scene using boxes and applying Principled BSDF to all geometries, I also applied different colors like red and green to the several geometries.

after light build, I got some .hdr baked textures, everything is fine inside blender.

when I imported to unreal using (fbx) including all baked textures, it did not show the exact colors that I implemented before in Blender, like the red geo and the green geo. all textures are in white but correct lighting

I tried to open the baked textures in photoshop for checking, the red and green textures for example are not showing exact colors, it should be red or green.

Is there any solution how to export all baked textures correctly ?

[goodstout]

AFAIK, this is intended behaviour for baking lightmaps. What you are referring to is sometimes called a Complete Map, and not a lightmap. It is possible to bake what you're asking for, but it's under "Bake" inside a stock installation of Blender, with the Cycles renderer enabled.

If you were to bake this out, you'd get the local colour of each surface (blue walls, red walls, diffuse textures etc) baked into the texture as well.

Hope this helps

[YahyaNawir]

AFAIK, this is intended behaviour for baking lightmaps. What you are referring to is sometimes called a Complete Map, and not a lightmap. It is possible to bake what you're asking for, but it's under "Bake" inside a stock installation of Blender, with the Cycles renderer enabled.

If you were to bake this out, you'd get the local colour of each surface (blue walls, red walls, diffuse textures etc) baked into the texture as well.

Hope this helps

The reason I was trying to use the lightmapper is that it produces texture map with denoise, I also use your recommend method of baking with cycles but I got lots of noise if set the sample lower. I have to use high samples value to get better result and of course take a lot of render time.

[Naxela]

Hi,

As @goodstout describes the hdr textures only contains the lighting information and is meant to be either multiplied or added to the original textures (depending on the type) - I am planning on adding a complete map mode in the future, the problem is that it won't be entirely correct, since the light is in 32-bit and the albedo/diffuse textures often aren't, but with some adjustments it could probably still look fine, possibly by preprocessing the operation in Opencv somehow.

[Naxela]

I've added support for that feature, and it might work - At least now it combines the texture and scales it down to the lightmap resolution and denoising works as well:

[rienheuver]

I've just tested it with basic colours and it worked very nicely. I also tested with a more complex material-setup: And the result is so very nice! This is exactly what I had been looking for and also what I would highly recommend for ThreeJS-users. This 'problem' is what I tried describing to you in email @Naxela, so I'm glad Yahya made it clear. Thanks for this impressively fast implementation of the feature!

[YahyaNawir]

I've added support for that feature, and it might work - At least now it combines the texture and scales it down to the lightmap resolution and denoising works as well:

Thank you so much for the update, finally working 🥇 💯

[Naxela]

@YahyaNawir Hi, great to hear that it is working!

@rienheuver I think it that case I might have misunderstood that, but it's good to hear that. I was wondering, are there other things I could implement to make the interaction with three.js easier? I'm preparing to write a tutorial on the three.js part, although starting from scratch without knowing three.js I'm wondering if the HDR textures works directly or if I need to implement some additional encoding perhaps?

[rienheuver]

@Naxela first thing that comes to mind is the problem with UVmaps I had earlier. Namely that ThreeJS seemed to pick up on the wrong UVmap which made the textures all over the place. Haven't had that in my last tests though, so should try that first with my more elaborate scene.

Since it's all about performance it helps to understand how to get high texel densities. I'm considering splitting an object for example to put more separate textures on it. So maybe it helps to have a few more texture-size options? 1024-size builds somewhat fast, while 2048 is already a whole lot slower, let alone 4096 or 8192. So maybe also a 1536 or 3072 for example?

If it helps I can make a small repo in which you can try out some scenes so you can experiment a bit for yourself.

[Naxela]

@rienheuver

I've been working on adding some additional functionality that binds with some methods from the Texel Density addon. As the resolution itself, the reason for the texture options is that on graphics cards there's some disadvantages when using NPOT (non power of two) textures, including more memory usage, slower performance handling, artifacts caused by mipmapping and interpolation, and some older/on-chip/mobile cards even refuse to handle textures that aren't in power of two. With that being said, I could probably add an option to provide a custom resolution input that takes in any number that is divideable (as to not break functionality in other areas.)

As for a small repo with some scenes, that sounds like it would be very helpful in testing out use cases for three.js!

[rienheuver]

Ah right, I read about POT-resolutions a while ago, had forgotten about that. In that case the current settings make a lot of sense. Integration with the Texel Density addon sounds good. I must admit I still haven't tried using that since I was caught up with getting in working in the first place. I plan on doing that soon though, now that I look more into quality of the textures.

I just thought of another feature that I would personally be interested in, though it's not related to ThreeJS. Namely better support for emission-materials. The lighting of the emission-material seems to be baking good on other objects right now. However, the object that is emitting is not getting any of that light. Therefore the emitting object's texture is black, though I'd expect it to be the colour of the emission. Sounds like that has something to do with your recent 'Complete' lighting mode.

I built a small repo off of my current project: https://github.com/rienheuver/lightmapper-3js

I believe it is an easy way to display your models and view them in the browser. If you have any questions or feedback regarding it, please let me know :).

[Naxela]

I can recommend it, once you get used to working with the addon it's really useful to get a quick overview of a scene.

As for the emission problem, have you looked at the Skip material function? It was made for cases that you mention, including emission and glass, but I have been tinkering a lot with the specific class that manages that so there might be some cases where it doesn't work anymore, can you provide some screenshots in case I've misunderstood what you meant?:

When baking with complete mode without it, the baked lightmap for that specific emission area is still connected, although it's multiplier is set to 0, yet the original color is still overridden, so that might be a problem

As for the repo, thanks a bunch! I'm sure it'll serve as a good starting point for tutorials. So if I understood correctly, all the lightmaps are also included inside the .glb scene file, so no encoding is needed for the HDR lightmaps?

[rienheuver]

Ah thanks for the tip on the material skip, I'll try that soon. As for the glb-files: yes, all textures are included. GLB is the same as GLTF, except that everything is always packed in the same file (GLB is a binary, GLTF can be JSON/ASCII as well)

[rienheuver]

I tried the material skip and it worked flawlessly, thanks!