Luoshuang's GPULightmass

[Luoshuang]

EDIT: Regarding quality scaling options…I cant get into much detail here, but what we have exposed is the ray count and a filtering value. If I want to do a preview bake, I set the value to 1024 rays and fitering 1 so it doesnt look splotchy. Once I am happy, I set the ray count to 500 000 or 1mio depending on the map and filter to 0 and thats then final quality. Preview usually finishes in 3mins…the fully quality bakes can take between 2 and 8h depending on map size and complexity.

The cool thing here is everyone can decide for themselves whats their final quality visually speaking. Also emissive generates more noise…so if you have a lot of emissive lighting you might need to bake with more rays. Exposing it like this would give you unlimited freedom for quality vs. baking times

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!

@Makigirl

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…

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!

@Norman3D

I have another question, would supporting normal maps for GPU Lightmass make sense? would it use too much GPU memory?

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.