Download

Luoshuang's GPULightmass

Development Discussion Rendering
#54

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

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

02_1024.jpg
02_1024.jpg1920×1018 107 KB

03_1024.jpg
03_1024.jpg1920×1018 89.1 KB

#55

…and another test:

03.jpg
03.jpg3840×2036 448 KB

Thank you for giving us the tool to achieve quality!!!

#56

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?

#57

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:

Cheers!

#58

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

#59

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:

#60

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.

#61

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.

#62

I remember I had the same jaw dropping!!

#63

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

#64

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.

#65

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

#66

Please integrate this Epic @9-stephen-ellis

#67

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.

#68

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.

#69

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.

#70
[Album] imgur.com

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.

#71

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:

TIM截图20180416202401.jpg
TIM截图20180416202401.jpg697×458 23.6 KB

#72

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?

#73

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