Thank you! This is looking amazing! Looking forward to see more stuff!
I have another question, would supporting normal maps for GPU Lightmass make sense? would it use too much GPU memory?
Currently the reason why the number of rays is fixed is also tied to some algorithm details - but i’ll definitely make it changeable in the future!
The amount of video memory used is dependent on total number of tris and total number of lightmap texels (i.e. the square sum of lightmap resolution), so it is hard to estimate without seeing those data. However we may still have some hope - did you use the command line baking technique I’ve mentioned in the tips? It can usually save 1.5G~2G vmem since the editor is not rendering.
For the splotches problem, it is very similar to the situation in vray where you have a low subdiv in Light Cache settings and have Retrace set to off. This problem will be fixed next time I change the algorithm.
For the light leaking problem, Norman3D have already noticed it in some tests done with me. If you can also provide some simple scene reproducing the bug the it would be very helpful!
GPULightmass bakes directional lightmaps which should support normal maps by natural. But if you want the bounce calculation to take them into account or let the result be baked directly into lightmaps then it is not supported, and I probably won’t support that since it has been proved to cause many problems unless you are targeting low-end platforms like mobile where directional lightmaps are not supported by the UE runtime.
Currently all platforms support directional lightsmaps. Haven’t seen any case where using normal maps for light bake calculating would result anything but problems.
Still, I don’t quite understand what is the use case for using normal maps in baking
I always assumed Use normal map for static lighting for intended for mobile. But there’s a shockingly low amount of results when googling “Use normal map for static lighting”, but did find this on Answerhub.
"This option in the editor is not for just any normal maps in the game. It’s for specifically built types where lightmass would need to know how to address.
As a test case, if you have a cube with all faces using a single smoothing group, but then render out a normal map to achieve sharp faces. Lightmass will need to be told about the normal map to reconstruct that as a cube with sharp faces. This is where this option comes into play."
So it seems like the feature is there for cases where the smoothing on the model does not look correct unless it has a normal map. With some workflows, that might actually be a common and large issue. But you can also avoid some of those problems by face weighting normals.
This is something I will be doing some testing with. Boxes with no normal map, baked normal map, weighted normal maps, weighted and baked, with “Use normal map for static lighting” turned off and on.
I couldn’t get Use normal map for static to effect my lightmass bake at all using 4.19.1, stock baker, production settings, 1024 production quality light maps. Maybe I should have tried bigger bevels on the boxes.
I believe it is time to summon @DanielW for this problem
Me neither. When I have tested it I just get horrible shadow splotches.
That would be great!!
Thank you! I’ve seen the command line option, I will try it with the higher resolution lightmaps! …I’ll have to keep in mind this limitation… :S
Thank you! …to be honest I get a LOT better bakes with HIGH SPEED already and rarely run into errors! /testing as much as I can in my free time!
It wasn’t a leak it more looked like a surface was getting lighting information when it shouldn’t have (or the shape of the light/shadow)… I’m still not sure about that case but will make some changes and will let you know if…
I have re-baked an old, only HDRI test scene of mine to see the differences… WOW!!! So much more color and direction from HDRI! And ALL those “shadow bleeds” at contacting/touching surfaces are gone!!
Just for the record, the light leak problems I have encountered I believe are linked with the spotlight. Light leaks seem to happen where the outer cone of the spotlight intersects the geometry.
In regards to the normal map question, I believe it’s only useful when using normal maps that add something of value to the surface. Like someone mentioned, when a normal map is trying to “add” more to the shape of a surface. I’m thinking about a tiled floor which normals are used to fake that each tile is rotated, or a more extreme example when a organic shape is decimated and normal maps are used to give it the high resolution look. I think it’s much less relevant if the normal map is used for micro details.
I do have more questions: Are the light portals taken into consideration? I guess not since it’s path traced?
so I gave it a shot with the high-quality setting and I have to say its pretty awesome already!! There are several things that are super cool with the new progress display, but for bigger projects, the first phase i.e. can get quite long and its not considered in the time remaining…so fairly intransparent. But nevertheless a huge step forward!
Sadly, I forgot to turn off “use normal maps for static lighting” so I got a couple of artifacts. I will do a clean rebake tomorrow, but for now here is a first tease!
I will upload some more images and stats when I have a rebake and a bit more time If I remember correctly, this bake took around 1h…maybe a bit less
Currently the use normal map option is already ignored by GPULightmass so if you see artifacts they are high likely bugs in my program :S
Ah I see…but dude…HOLY SHIT! This is fucking insane! Bake time like…I dunno…3mins? The scene is not mine, I only relit it The details from the windows is just like…I dunno man, I can sleep veeeery well tonight XD
PS: Lightmap rez is all green…like pretty normal green, so not too dense
I believe the HDR improvements are from the Lightmass 4.18 updates.
GPULightmass shouldn’t have any differences beyond the quality, speeds, and feature set.
Someone please help Luoshuang to add OpenCL support and let EPIC integrate this out of box. GPU speed boost is really amazing. Would be really good if someday baking can use both CPU+GPU at once and CPU as fallback if GPU fails.
I remember I had the same jaw dropping!!
I’m still not sure (have no idea! :S) how could we bake large maps on a single computer… the vmemory is very limited… it’s not as easy to “upgrade”/ increase your vram… Any ideas? :S
I’ve updated a new version to fix the bug. It is a rather silly bug inside the spot light attenuation calculation. Please let me know if that fixes for you.
For an OpenCL implementation there might be a potential problem: NVIDIA cards have worse support of OpenCL so if I transit to OCL then they may get much slower (take a look at vray RT’s CUDA and OpenCL). If I want to maintain the same speed then I probably need to maintain OCL and CUDA at the same time which is actually impossible at least for myself.
The way to do it is called out-of-core raytracing on GPU. However it is much more complicated to do and it will certainly slow down the raytracer a lot since we’ll have to swap in and out vmem pages a lot. I believe we won’t get to the point in the near future.