Luoshuang's GPULightmass

Hey guys,

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! :slight_smile:

FarronKeepGPU.JPG I will upload some more images and stats when I have a rebake and a bit more time :slight_smile: If I remember correctly, this bake took around 1h…maybe a bit less :wink:


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! :smiley: Bake time like…I dunno…3mins? :smiley: The scene is not mine, I only relit it :slight_smile: The details from the windows is just like…I dunno man, I can sleep veeeery well tonight XD

Lightmass_GPU_03.JPGCheers! :slight_smile:

PS: Lightmap rez is all green…like pretty normal green, so not too dense :slight_smile:

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.

Downloaded already! :wink: THANK YOU!!! …testing an emissive only scene right now! :wink: …but as soon as it’s done (I still can’t believe the speed!! :D) I’ll update and test it straight away!!

Thank you for answering to this!!

Please integrate this Epic @9-stephen-ellis

Really impressed with the quality so far. I’ve never been able to get such clean results with baked lighting so easily and quickly. It’s also a much more predictable workflow than the CPU-based one.

A huge plus for me is being able to assemble large flat areas out of separate meshes and not have to fix seems or cover them with columns.

So I gave it a try, and here are my results in a fairly complex scene (using a bunch of custom area lights that are basically spotlight arrays, so it had a ton of data to work with)

CPU vs GPU Lightmass - Imgsli - CPU vs GPU baking results, using “UltraHigh” on the GPU lightmass and very high settings on the CPU to eliminate any and all inconsistencies between modular components (production, quality 4, smoothness 0.25, and scale 0.1).

As you can see, the GPU lightmass had… problems. Namely in the bounce lighting, it’s way too dark.

CPU vs GPU Lightmass 2 - Imgsli This is the same test, but with “LowerQuality” on the GPU for the sake of time, and changing Diffuse Boost to 1.5 in the world settings. As you can see, it’s significantly closer in the end result. I suspect the extra color might just be from boosting the diffuse like that, it’s the brightness that needed to be fixed.

Also worth noting, the “FastPreview” preset would stall at 93.33% in the scene, eventually taking longer than UltraHigh did on that one mesh so I canceled it. This happened both times when testing that file.

As a side note, just something I encountered when using base lightmass, not sure if this is something that can even be changed, but is there any way to make it look at world position offset or tessellation when calculating the baked shadows? It’s a pretty fringe edge case I ran into the problem, but when vertex painting a mesh’s heightmap with a ton of displacement it would be pretty significant for catching the shadows properly. Again, not sure if that’s a thing that can be solved with this, just figure I may as well ask.

Did you use SourceLength and SourceRadius on the lights? Unfortunately they belong to soft shadows and are not taken into consideration when calculating bounced lighting by GPULightmass. Since you said you’re using spotlight arrays, I believe the area lights are the problems.

Nope, nothing fancy here, no source radius or source length. Just a bunch of non-area light spotlights shoved together.

Also, interestingly, LowerQuality is closer to the CPU results than UltraHigh. It’s still not exactly what I would expect, but it’s closer.

I’ll check my code again to see whether the fix to spotlight attenuation calculation has been made into all versions.

@Zero-Night Now I’ve recompiled all the versions. Let me know if you still see huge variations between different presets. I also did a simple test with light arrays:

It’s a lot closer now, that helped it. This is with the new UltraHigh preset vs CPU. GPU is still a bit darker, but it’s much closer.

Edit: So in a room with much fewer lights, the darkness difference is still very noticeable between the two.

Now worth noting, these ones are area lights, they use the source radius. Is this about what you’re expecting for that?

It would be good to get source so we can debug it!

What is the version of the CPU builds? 4.19.1?

4.19, don’t think I rebuilt after .1 came out since the project was finished, or at least in a state where I didn’t care to continue further on it. The engine currently is on 4.19.1 of course. I did some further testing, turned off source radius on all spotlightdss in that other room, with no change to the final result, it looks identical.

Also worth noting, the FastPreview setting works for me now with the more recent update, it no longer stalls. :slight_smile:

Edit: Just did some more testing, with the Realistic Rendering demo scene. The GPU lightmass solution actually seems more accurate in this particular case, properly having the light passing through the subsurface red cloth get tinted red for the bounce lighting. So in a scenario where everything works out perfectly, it’s faster (less than a minute for a maximum quality bake) and gets better looking results. If some of the weirdness like those spotlights in that scene not bouncing any light get worked out, I don’t see any reason to use the stock lightmass over this, at all.

In some areas like behind the TV, it’s still getting oddly dark, but for the most part I would say it’s a notable improvement.

If you have a bit of money left, you can go for something like this here… :cool: