When ever I changed Progressive GPU to CPU it got normal. But obviously it waste more time.
So, I want to fix this.
I tried both small and big scenes. Small scenes has no problems but big scenes does, so I though it’s because of size.
But then I tried same settings with using GPU for another big scene, and it has no problem.
Then, I go back that big scene and it suddently start working with GPU progressive.
I don’t know what’s causing it. How can I fix this and make it consistent?
This sounds very similar to the problem reported over here. A fix for that problem landed in 6000.0.25f1. What version are you on? Maybe you just need to update.
I did try to update 2022 version once, but I got some problems about light baking taking too long with same settings. So, I go back the old version via git.
I see. In 2019.4 the GPU lightmapper was only a preview feature intended for experimental use and therefore it is unfortunately expected that it will have stability issues. This version of the GPU lightmapper no longer receives fixes and hasn’t received any for a while.
This makes it very difficult for me to guess what is the cause of the issues you are seeing.
I hope you will reconsider trying a new version of Unity (I’d recommend Unity 6). A lot of fixes and stability improvements have been made since then.
Should you find that light baking is surprisingly slow on Unity 6, please report it here and I’d be happy to try and help you.
I have a 1k terrain and I’m using Unity 6.2. GPU Progressive lightmapper fails but works on my mac m4 max. Specs are very high 128 gb RAM for PC with 5090.
I will try the CPU lightmapper as well soon. Btw I can’t seem to run my scene on Windows without the reflection probes disappearing even though the lighting and probes are all built on the Mac, that’s why I need to build the lighting on the Win PC to see if the reflection probes disappear again.
Will create a new topic soon if am unable to resolve it. Question: Will moving from URP to HDRP change behavior and perhaps make the baking work?
What do you mean by “fails but works on my mac”? Do you mean that it works on Windows but fails on Mac? What happens when you try to bake on Mac?
Sounds good. Please make separate topics for each issue. You may also consider using Help → Report A Bug in the editor if you believe you have identified a bug.
It could but that is very unlikely as 99% of baking code is shared across URP/HDRP.
Sorry I wasn’t clear. What I mean is the Baking process crashes with an out of memory error on the Windows PC. Works on the Mac 80% of the time.
OpenCL Error. Error callback from context: CL_MEM_OBJECT_ALLOCATION_FAILURE error executing CL_COMMAND_MAP_BUFFER on NVIDIA GeForce RTX 5090 (Device 0)
I’ve tested it on a 4090 as well, same issue. On the Mac it successfully finishes my baking after 2 hours but sometimes it will crash if I keep the anything else open (Seems it needs a lot of memory)
The baking works great if I avoid “Drawing trees” on the terrain. The problem starts only when I draw trees or even if I have a lot of Adaptive Probe Volume nodes. (Right now I set a minimum spacing of 5 and that bakes very fast with great results). So fast as in less than a few minutes.
I have noticed that it uses up over 120 gb of RAM on both the Windows or Mac when baking the terrain lightmap + APV probe data if I keep the trees visible. Ofcourse it will fail on the Windows PC after a few minutes of running.
Basically can’t bake with vegetation on (I discovered this a few hours ago, all this while I only baked with vegetation being drawn)
How large is your scene? Can you please post a screenshot and perhaps some triangle count stats? In particular, how many triangles do your trees have, approximately, and how many trees do you have? It would also be helpful if you could provide your Editor.log as it looks just after a failed bake.
With a 5090 you should indeed be able to bake very large scenes but still there is a limit, so that is why I’d like to better understand what you are trying to do.
HI, for sure here’s all the info you asked for! Hope I didn’t miss anything.
I’ve attached a screenshot with the tri count stats and video for my scene. I have around 12 mil triangles per frame. Thank goodness for AI helping me write a script to get tree and tree triangle count: I have 98261 trees in my scene. The trees have 745728371 triangles. Is that a lot of triangles?
I had nvidia broadcast running and it was using some VRAM, when I closed it, it runs the baking process longer but still stops after a while, I never knew this baking process would need so much vram, it’s literally using over 30 gb of VRAM.
Also on my 4090 PC: If there’s not enough vram, it just uses all 128 gb of my system RAM and goes on for hours and then suddenly crashes. As if there’s some sort of memory leak or thrashing between GPU/PC memory.
I have attached the Editor.log (please note that I changed my GI storage path, because I ran out of disk space on the default path so the last part of the log will have more information after the bake failed). I am going to rerun the baking to see if it is failing because of storage as well but that’s a long shot
I re-ran with more storage for the GI cache but still sadly no dice, this time Unity editor crashed with the bug report screen. I’m attaching the log for when it totally borked as well. Total bork of the editor happens sometimes too, even on the Mac.. Editor-prev.crash.log.txt is the one with the total bork (2nd attached log).
I have to say even CPU progressive throws the same error but after running for 5-8 hours. So can’t make with CPU too
I did some more testing, I removed adaptive probe volumes, then the baking takes barely 4 minutes on the mac m4 max. But the problem is there on the Windows PC with 4090/5090. I think some sort of memory leak for large maps/scenes when being baked with vegetation. On the 5090 PC, I even bug check reboots because it fills up all the page file several times over after filling up the RAM. (5090 PC has only 64 gb of ram, only the 4090 has 128 gb of RAM )
The editor log you provided suggests that the problem here is that the BVH acceleration structure data (which is built on the CPU) cannot fit in your GPU memory simply because it is too large.
This happens for two primary reasons:
Your trees use a lot of triangles.
Our current baking implementation does not use instancing which means that all trees are effectively copied in the BVH data. As you can imagine, this means very high memory usage.
We are currently working on two fronts to fix this:
We want to allow the users to specify which mesh LOD is used during baking. This should enable you to use one low-poly mesh for baking and a high-poly mesh for rendering.
We want to enable instancing in the BVH data. This will avoid the copies mentioned above, causing a reduced memory usage. Note this will come at a minor performance hit but this should be worth it because it enables baking of much larger scenes.
At this point I cannot make any predictions about when these improvements will land in a public release.
Right now and here, I recommend you try to reduce the poly count of your trees and/or the number of trees in the scene.
Thank you so much for your reply. This makes complete sense. These features will be a godsend especially because I have 3 LOD’s on all my trees and the lowest LODs are super low poly and should be enough for lighting. The instancing feature would be killer.
I will see if I can reduce the poly counts or maybe redesign my map into smaller chunks
(I discovered this a few hours ago, all this while I only baked with vegetation being drawn)
