Official Progressive GPU Lightmapper preview

CPU:


GPU:


Case 1310621

Please fix.

 

Also, GPU needs like 10 times more rays to be as clean as CPU. With that in mind GPU isn't really all that fast.

These are with the same rays.

CPU


GPU

 

Any chance to have an option in GPU lightmapper somekind of "Ray Multiplier" ?

 

I have to say the GPU lightmapper is very fast. We build large projects for Naval simulations, scenes with around 95 2k lightmaps. It would take 3 days to bake with CPU vs. 30 minutes with GPU.

 

I'm trying to use the progressive GPU lightmapper in 2019.4.5f1 (I can't move up to 2020, sorry) and I'm getting an error about being out of resources on my 1070GTX. I've seen that the suggestion in other threads is to disable progressive updates, but I can't figure out how - there doesn't seem to be an option to do that anywhere obvious, and google has been no help.

 

I have a GTX 1080 and I can't get the GPU lightmapper to work no mater what I do. I can set it to tiny settings and it still errors out with :OpenCL Error. Falling back to CPU lightmapper. Error callback from context: CL_OUT_OF_RESOURCES error executing CL_COMMAND_WRITE_BUFFER on GeForce GTX 1080 (Device 0).

Or : OpenCL Error. Falling back to CPU lightmapper. Error callback from context: CL_UNKNOWN_ERROR

 

Hi, I have found that on a fairly large scene, the baking switches from gpu to cpu, unless I take the scene view camera, place it underneath the scene and face it downwards, so there are no meshes in view. It then seems to work successfully and I have been using this trick for at least a couple of years now, but have no idea why it works, so you may want to try that.

I would also like to add I have progressive updates turned off and my lightmap size at 2048, due to using a 2060 super.

thanks

 

benchmark bake time:
02:14 on 4790K CPU (2 hours and 14 minutes)
00:24 on GT1030 GPU (24 minutes)

 

My spec:
Q8400 cpu + GT 1030 gpu + 6gb RAM
I decided to buy a powerful computer but now I don't need it with GPU lightmapper
My system is very fast when working with Unity and I only had a lightmap problem that was solved with gpu lightmapper

I had never tried the gpu lightmapper because I always had the OpenCL error on 2020.2
But now with the 2019 lts installation, my problem was solved and I was able to test it
the result:
The scene already baked on 4790K in few hours but for the now i baked it again in 34 minutes using GT 1030 2gb gpu :
GTX 780 : 12 minutes

 

Code (CSharp):

1. Failed to find a suitable OpenCL device for the GPU Lightmapper, falling back to CPU lightmapper. Please install the latest graphics driver.

Unity 2019 works well but in 2020.2f1 i have the problem
My driver is most up to dated
GT1030 Windows 8.1 64bit Driver 461.72

 

This is very bad news
I have a powerful GTX 780 3gb
So there is no solution?

 

Same Issue how'd you fix this?

 

What am I missing here. With Bakery I bake a very simple scene wit high settings, in less than a minute.

With Progressive GPU, I get an OpenCL Error withing 10 seconds and it falls back to CPU, with the error of Available GPU memory: 3.46 GB (on a RTX 2070 Super)

I then lower the res back down to 20 texels, progressive GPU bakes quickly and I can see the effect in scene view and game view, but then when playing, it reverts to no bake, until I stop playing, then it shows the bake again.

This is in 2021.2.0a8 and HDRP DX12 (no raytracing)

 

You need at least 16GB of VRAM in my experience with GPU baking, especially if you want to bake 4K maps. Had this problem here as well with 2070 super but upgrading to AMD 6800XT with 16 GB VRAM solved it.

Note that the Nvidia 25% limit on OpenCL allocation sizes will require you to use a 24 GB Nvidia GPU to fit the geometry BVH. AMD doesn't have this limitation, so for example AMD 6800XT should suffice. You would still have to dedicate the entire GPU to the baker for everything to fit (one GPU for the editor and a different one for the light mapper).

I know this is not a ideal 'solution' since it should simply not run out of memory but that is just the way things are right now with Unity and GPU baking being in Preview.

 

Yeah hope they fix this soon because that is rediculous. Bakery bakes the same scene in less than a minute. Also I'm not getting an AMD GPU just to get light bake working. I also use raytracing and you need NVidia for that (also use other apps and everything revolves around CUDA and RTX)

Maybe in the future they will autodetect your hardware and auto use OpenCL for AMD and RTX or CUDA for NVidia....

 

Or, you can just, you know, buy Bakery.

 

I already did, bit currently it doesn't play nicely with HDRP 12

 

Any ETA for this regression getting fixed?

 

So i put a extra rtx 2070 in my rig to use for baking. Even with that I still get "OpenCL Error. Falling back to CPU lightmapper. Error callback from context: Not enough GPU memory to fit lightmap in memory, even in tiled baking mode. Available GPU memory: 2.49 GB". I dont see how the available memory is 2.49gb when there is almost 8gb free. I used to make sure that the right devices is selected for baking : "-OpenCL-PlatformAndDeviceIndices 0 1". What am I doing wrong? Baking at 2k resolution loads about 3gb of memory on the gpu and stays at 1% utilization.

 

I'm currently tested out GPU baking with GTX1060 3GB
On a new project with HDRP,
Unity 2019.4.24f1, able to baked with standard settings.
but
Unity 2020.3.3f1, will crash upon start bake.

 

@shin-sim Current minimum GPU VRAM requirement is 4GB (since

2019.4

):
https://docs.unity3d.com/Manual/GPUProgressiveLightmapper.html

Back in

2019.3

, it was 2GB:
https://docs.unity3d.com/2019.3/Documentation/Manual/GPUProgressiveLightmapper.html

.

 

No, the second GPU never showed up in the baking device dropdown. Do you still need a bug report for this ? Also Im not sure what files I could include to help you out.

 

What settings do you recommend for PLM GPU?

 

Yeah ray sample count, for a good starting point. We based our scenes on the old default

 

Thanks, will do.
I'm on a 24 gig VRAM (nvidia 3090) and it works even for our biggest scenes. (Sometimes I need to restart Unity because it fall backs to CPU anyway, maybe a memory leak or something).

I found a new bug btw, it seems that you bake ref. probes too early so they become black. I need to bake them again for them to be correct.

 

Mine are complete black though. But maybe same bug anyway?

 

I still have problems with the GPU Lightmapping. VRChat still use Unity 2018.4.20f1. So that mean Unity still using a preview version for lightmapping.
My PC have AMD Ryzen 5 3600x and AMD RX 5700XT. (Driver 21.3.1)
I tried to remove the OpenCL.dll file from the folder. It doesn't work
I tried to copy a newer version of OpenCL.dll file from the amd driver to editor folder. it doesn't work too
I checked on the log file.

Code (Boo):

1. -- Listing OpenCL platforms(s) --
2. * OpenCL platform 0
3.     PROFILE = FULL_PROFILE
4.     VERSION = OpenCL 2.1 AMD-APP (3224.5)
5.     NAME = AMD Accelerated Parallel Processing
6.     VENDOR = Advanced Micro Devices, Inc.
7.     EXTENSIONS = cl_khr_icd cl_khr_d3d10_sharing cl_khr_d3d11_sharing cl_khr_dx9_media_sharing cl_amd_event_callback cl_amd_offline_devices
8. -- Listing OpenCL device(s) --
9. * OpenCL platform 0, device 0
10.     DEVICE_TYPE = 4
11.     DEVICE_NAME = gfx1010
12.     DEVICE_VENDOR = Advanced Micro Devices, Inc.
13.     DEVICE_VERSION = OpenCL 2.0 AMD-APP (3224.5)
14.     DRIVER_VERSION = 3224.5 (PAL,LC)
15.     DEVICE_MAX_COMPUTE_UNITS = 20
16.     DEVICE_MAX_CLOCK_FREQUENCY = 1870
17.     CL_DEVICE_MAX_CONSTANT_BUFFER_SIZE = 7059013632
18.     CL_DEVICE_HOST_UNIFIED_MEMORY = false
19.     CL_DEVICE_MAX_MEM_ALLOC_SIZE = 7059013632
20.     DEVICE_GLOBAL_MEM_SIZE = 8573157376
21.     DEVICE_EXTENSIONS = cl_khr_fp64 cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_int64_base_atomics cl_khr_int64_extended_atomics cl_khr_3d_image_writes cl_khr_byte_addressable_store cl_khr_fp16 cl_khr_gl_sharing cl_khr_gl_depth_images cl_amd_device_attribute_query cl_amd_media_ops cl_amd_media_ops2 cl_khr_d3d10_sharing cl_khr_d3d11_sharing cl_khr_dx9_media_sharing cl_khr_image2d_from_buffer cl_khr_subgroups cl_khr_gl_event cl_khr_depth_images cl_khr_mipmap_image cl_khr_mipmap_image_writes cl_amd_liquid_flash cl_amd_copy_buffer_p2p cl_amd_planar_yuv
22. -- GPU Progressive lightmapper will use OpenCL device 'gfx1010' from 'Advanced Micro Devices, Inc.'--
23.    use -OpenCL-PlatformAndDeviceIndices <platformIdx> <deviceIdx> or -OpenCL-ForceCPU as command line arguments if you want to select a specific adapter for OpenCL.

No GPU shown on or Unity doesn't detect my GPU for lightmapping.
What should I do... I really want to make the GPU lightmapping work so much or it will take like 3 - 6 hours for baking the scene.

OpenCL Error. Falling back to CPU lightmapper. Error callback from context: CL_INVALID_PROGRAM always happen

 

GPU PLM is extremely fast (GTX1650 4GB)
I don't know why users say bakery is better or faster
GPU PLM quality is amazing

I will compare soon ...

 

Well, I have never used bakery so I can't compare how fast it is, but the plugin does have several features the default Progressive light mapper doesn't have, for example:
- Bakery can use normal maps from the materials and believe me, this feature makes a big difference in how the lightmaps look.
- You can recalculate light probes without rebaking the whole scene (unity is making a new system for light probes so this will change).
- Seems like they have some automatic toolkit for fixing lighting leaks and UV seams. This sounds like a big deal because in standard unity you have to deal with UV maps manually. It burns a lot of time because you never know why is that happening (too low padding between UVs? Backfire Tolerance? Something else?). It's worth noting that this is a problem only for the unity engine, I haven't seen that kind of issue anywhere else, even in the decade-old tools.
- Probably also have better presets, which is a big deal because the default one in the unity engine is terrible. It forces you to wait forever until baking is done and also doesn't provide good quality. I'm surprised the team still didn't make several presets so everyone can prototype quickly.

And maybe they also (still) have better memory management, but that's also on the way. Well, that's my tiny bit of feedback, I've lately had experience with lightning in ue4 so expect more of that, possibly in a separate thread.

 

The main problem with Bakery is that it does not work with Unity default light sources
With PLM, you can use standard Unity lights and achieve the desired result without much difference with real-time light.

Bakery and Unreal Engine lightmappers are around Beast lightmapper
PLM is much higher quality and more professional

PLM is out of the box and is seamless with unity's lighting workflow

UV:
UV unwrapping is very simple...
1. Use unity's Auto Generate unwrap in import settings from textured model
2. use maya uv automatic unwarap for interior models with white surface

Your all problems will be solved easily!!!

I will try again on bakery and i will share the results

 

I mean, it auto adds a component, not sure what the issue is.

What do you mean?

 

1. All features(normal map bakes , bake reflection probes...) was available in the beast lightmaper on unity 4
2.I worked with Unreal Engine 4 a few years ago
And I know that there is no such thing as Indirect Light sources in Unreal Engine 4 and you have to simulate it with Spotlight and planes

 

I wish it would be true but that's not always the case. Sometimes you lower the texel density. After a long process of baking, it appears some meshes just look wrong because you have to also deal with the padding. Of all options in to set up, this one is pointless. You always want it to be the smallest possible but also to not cause any problems. I personally feel like the proper value could be found with an unknown to me calculation. Again, every other engine successfully takes care of your project so that I never have to deal with randomly generated problems because a piece of a UV is too close to the border of the map.

But there are also some other cases, like:
Sometimes you want to use unity's probuilder for fast prototyping, and since it does all UV wrapping automatically, you can't deal with it to make it work with PLM.
Sometimes you (or any artist) might do something wrong with UV wrapping and the result will be UV overlap. You can see the number of texels that are overlapped (sadly only after baking) but not the percentage of the whole UV map, so you can never clearly see whether it's a big deal.

They have them to lower baking time in closed spaces. Also, remember that it's easier to do these cheats in ue4 than in unity since you have several specific options just for that.

Oh and also, If you have worked only a few years ago, you have missed a lot. Fortnite happened and they improved that part of the engine too.

 

UV problems mostly happens on incorrect modeling ways

Some tips that make your lightmapping uv problems away:
1. Always use cubes instead of plane for walls. in real world we don't have 0 z axis scale plane as wall
2. As i said before, always use simple maya automatic unwrapper for UV2 to fix 100% of the unwarps issues
3. Always use proper surface culling directions (normal direction)

Because of the automatic UV fixing solution on offline renderers , most modelers always model the scene in the most wrong ways (plane as wall, wrong normal direction) that make the whole game lighting trouble

Anyway, so far I have not had a single uv/unwrap related problem with the above tips

I have some uv fixing solutions in my old videos. i will share if i found them

About UE4 lightmapper:
The speed is too much slower than unity's PLM CPU:
In the below scene the UE sample is from evermotion(as i remember). The baking time is ~5 hours by default author settings
I have baked with higher indirect lighting and indirect shadows inside unity in 10 minutes using same cpu. Now using GPU lightmapper you can bake in seconds with the same result!!! You don't need to wait long time to see the result

Lightmapping settings:
In unity, you have 100% real world physical lightmapper. So finding a true settings are very simple. You have a physical sky light (color or ibl) and 3 simple direct light sources with true physical indirect light/shadows results. Also you have emissive materials as indirect lighting + area lights

In unreal engine everything is fake !!! in unity you can also use UE fake style for indirect shadows or lighting to reduce noise and bake time:

 

Some comparison results +


Fake indirect in UE4 (tested 3 years ago):

Spoiler: Technical lightmappers Comparison

Spoiler: Tree Lightmapping Quality

This is what that Bakery can't do i think:

 

Please next time try to read my messages. None of this is addressing what I'm writing about and it's not even fully true. There always existed specific cases which automatic unwrapper can at best cause, definitely not fix.

Also, I will point out this again with UV maps, there are issues with the default unity settings (and sometimes changing them) that I haven't been able to replicate in any other engine, with the same meshes.

I can't confirm this as for me they were pretty much the same with minor differences. Yeah, the PLM provides more realistic results, the settings are nicer in unity, the GPU renderer is faster than the CPU renderer thus unity can be faster than ue4.

One more thing about the speed, in ue4 you have a dedicated toolkit to see exactly how much time it takes to bake each mesh. It helped me to speed up the baking process by about 11%, a really nice thing unity could copy too.

Oh and also, these screenshots you have provided here are misleading, There are a lot of parts towards making complete lightning, including post-processing, choosing the right method of AO for your type of project, sky settings, environmental settings, materials settings, shaders, and others. While there are differences between PLM and Beast (which I won't try to confirm whether they actually exist), all differences between ue4 and unity are choices of the user.

 

I don't like to upset anyone. I'm sorry

Please send me one of the examples of UV problem in Unity