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.
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).
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
EDIT: Actually, in fact, it’s not even considered a bug: ⚓ T61509 Cycles Tile Size has extreme impact on texture baking performance without any difference in baked texture quality
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.
So, at 4096 tile size, it takes me about 5 seconds on my GTX1080Ti to bake 4k emission map of a noise texture:
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:
With default tile size, it’s in the ballpark of 6-8 minutes.
@LudvikKoutny Thank you! - That is exactly the kind of tip/information I was hoping someone would post. I am extremely grateful.
I’ll do some experimenting with tile size and samples when I get home tonight.
If it works out, then hopefully I can incorporate this into my add-on and also improve everyone’s bake times.
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.
Seriously. You are my personal freaking hero.
Help me poke @brecht to prioritize fixing it I’d like to use Blender for baking textures for game engines too
@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.
You just save my day. Just for the record, I adopted you as my hero as well
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
@brecht @ideasman42 is so hard implement this type of workaround?
That would be me.
It went something like this:
- Hmm, lets see if I can render 9x4,5k image using progressive refine instead of tiles? What can possibly go wrong?
- Instant OS crash without warning.
That day I learned about restoring from .blend1 backup.
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.
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.
I just use the “Auto Tile Size” but not sure if that’s optimal for baking