This is INCREDIBLE!! I’m amazed by the speed!! It’s like 10 times faster than the CPU version!! You are amazing!! …first the multi bounce Skylight and now this?! I hope this will be the future!! Thank you !!!
I did some testing yesterday (discovered your post too late! ;))…
This scene had almost 5000 meshes, HDRI Skylight, Directional light, Point lights and emissive too!
Took 22 minutes (!!!) on a GTX1070 /lightmaps from 64 to 2048/
I had other tests too and run into some errors…
In this scene I run into a “out of memory” error just before the tracing… I had to lower lightmap resolutions… What is the memory limit?
I had a scene lit by a HDRI. The result was VERY nice (detailed shadows) but I had white spots close to corners (will post screenshots in a few hours…) …maybe too few samples?
…and there was another one which turned out completely black… but I will check that again!
Oh I did another test this morning with an older lighting test scene from the forum and I got some strange results (will post later, didn’t have time this morning)… I had some lighting appearing which I couldn’t “trace back”… was not looking real…
BUT overall: IT IS AMAZING!!! And SOOOO FAAAAST!!!
THANK YOU!!!
ps.: What kind of scene/lighting tests would help you ?
/edit/ I forgot to mention the progress bar! It’s so much better than the original (non existing? ;)) one!! …and even has an ETA!! So cool!! :))
It should support OpenCL by then and then it could be good for integration officially. I just now discovered this thread and wanted to try it but found out it is CUDA only.
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.
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."
-Tim Hobson
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.
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
Ah I see…but dude…HOLY ■■■■! This is ■■■■■■■ 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
Someone please help 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.
You are amazing!! …first the multi bounce Skylight and now this?! 
I will upload some more images and stats when I have a rebake and a bit more time 
