I was wondering if anyone knew why texture baking in Cycles is so phenomenally slow?
I accept that this might be a technical limitation relating to how baking works, but I’m interested to understand for my own education.
Background
For background only, I have developed an add-on for Blender 2.8 that allows for automated texture baking. If you are really interested, that addon is here, but I don’t think that it’s necessary to review the add-on to understand this question.
It is sufficient to say that I am baking emission passes and normal passes (a lot more of the first than the second).
. Issue
My computer is not bleeding edge new, but it is also not old (Intel I7, GeForce Titan X). I would say that it is “reasonably fast” by today’s standards.
I cannot believe how insanely slow baking seems to be. In respect of emission passes in particular, I would have thought that these would be quite fast (not having to take into account lighting or shadows or anything) - but instead they take hours a time. Normal passes take even longer.
For a recent model, I baked 8 emission passes and 2 normal passes at 4096x4096. Total time was in the region of 14 hours That just seems disproportionate.
What is the issue here? What makes texture baking so slow? Is there any way to speed it up? There don’t seem to be any settings for emission bakes, and the settings for normal baking don’t help much.
Because there is bug, which according to developers has very low priority. In Cycles render settings, change your tile size to the resolution of your texture. So if you are baking 4096x4096, change the tile size to 4096x4096 (although perhaps try 2048x2048 first, just to be safe). You should get immediate increase in baking speed.
Furthermore, Cycles uses the amount of render samples for baking, which defaults at 128. For baking purposes, it makes sense to reduce it greatly. Try something like 16 samples, that should be fine. And of course, make sure you are baking on your Titan X, meaning that it’s enabled as CUDA device and used by Cycles
By setting the tile size to your baked texture resolution, you should get about 17x faster rendering. So those 14 hours should be more like 45 minutes Non the less, I would be careful trying that with 8k textures, as 8k tile will take quite a lot of GPU memory. 4k tile size is still relatively fine, taking about 2.6GB of GPU memory.
And about 16 seconds to bake two AO maps for convex and concave edge masks. Those require a lot more rays to be traced, so 16 seconds is a really good result:
Just keep in mind that it may not be a good idea to universally set tile size to baked texture resolution, because sooner or later someone will show up and try to bake 8k textures with some GPU that has like 3-4GB of VRAM
@LudvikKoutny I didn’t even have to wait to get home… I just baked in 10 minutes what it took 14 hours to bake last night.
I am speechless… how the hell can I thank you?
Point taken about people getting overly ambitious with the tile size. I will either have the add-on warn them, or maybe just max out at 4096… not decided yet. I will experiment.
@brecht - I understand the argument that this isn’t a bug, but rather is an optimisation issue. That makes sense - it’s not wrong functioning as such. That said, it’s so counter intuitive I am totally at a loss to understand how the user would be expected to know this. I developed an entire add-on based around baking in Blender, and I had no idea whatsoever. I just assumed Blender was really slow at this kind of thing. I didn’t even ask on the forums until recently.
Surely there is a better way to handle this? At least hinting to the user or something?
There’s also this patch which tweaks how Baking is implemented in Cycles - I should probably do some tests to see if it resolves the need for massive tiles.
in Blender 2.7 with blender’s default renderer, you can bake a black/white mask of shape on top of a UVed model at 2048 resolution with 4 times AA in 5 seconds. (8192x8192)
So, if anyone is interested, the way I dealt with this in my SimpleBake add-on was to match the tile size to the bake image size, but max out at a certain value. By default this is 4096, but I’ve provided an option for the user to specify a lower value, or remove the limit entirely, depending on the kind of computer they are working with.
It works - but it’s just added complication for the user, that I don’t think they should really have to deal with. As I have commented above, I accept that this is technically a optimisation settings issue, but the average user will not know to do this manually. It can’t be that big of a task to have Blender determine the optimum settings… surely? I had no clue whatsoever about this, and I count myself as a… reasonably …advanced Blender user…? I’m not a novice, anyway.
I didn’t know that. Why devs don’t solve this? Ok, maybe solve the problem in cycles is hard. But please, change the tile size when bake and when it finish put the old value… it can’t be so hard
Why not just use Auto Tile Size add-on and stick to whatever automatic result it throws for any given device instead of trying to predict the tile according to texture res output?.
I’m just asking cause I’m also interested in baking speed and even tweaking the tiles I find it quite slow compared to other software. Talking about cycles and GPU only.
Thanks
The issue here is that a standard small tile-size, such as you would get from Auto Tile Size, slows down baking for some reason.
Using a tile-size close or indentical to texture resolution however makes the bake go faster…?!
…
Makes little sense and might require big memory.
It likely won’t even be that fast, because Cycles is quite sluggish with baking by default.
But a workaround is what it is!
Bumping the dead.
Is this whole discussion still valid? I made a quick test and found that bigger tile size actually goes much slower than small and even smallest (8) one.
For the records my test was done on CPU.
Baking now uses tiles similar to rendering, and so performance tuning with tile sizes is also similar. That means small tiles are best for CPU rendering.