That will be great.Single tile the size of the image will be ok just for the GPU I think but for CPU or multiple GPU doesn’t make sense.The other thing that will speed up the process significantly in case that you have multiple source objects to be baked to target one is to combine them before bake.Its good to have it as a option.
I haven’t really tried baking manually in Blender for a while now, but I think I remember using a single tile had a lot to do with how inefficient the memory scaling was when you had many tiles and many source objects, to the point that it would start swapping to disk in relatively simple bakes on 16GB systems. At some point it allocated the whole texture per source(!) object, per tile, which is kinda insane.
But that was a really long time ago, maybe that’s fixed now?
I used to have the tile size default to 256x256 but switch to image size if the source was emission. I know using the GPU could still crash things not that long ago by running out of memory… But not that long ago is like a few years…
I can just add the options for tile size in the advanced section of the node with a tick box to make it equal the image. It’s probably worth having it easily set for people who want to fiddle around with getting the best performance.
I’m also interested in what messing with the threads setting does if anything. It’s set to auto detect as default currently, which should be one thread per core.
Is merging all the source objects before baking worth while? I could look into doing that automatically…
I believe I used to merge objects in Meltdown, yeah. But again, that was somewhere in the 2.6 series. May not matter anymore.
The reason I don’t is due to auto smoothing… It’s fine if they all use the same setting, but it would mess things up if they are different.
That’s true, autosmoothing wasn’t a thing back then, you couldn’t edit normals at all.
Though I think you can sidestep the issue by creating a custom normals data layer? Though again, no idea if it’s at all worth the trouble. And then there’s the fact people will be doing this to dense Multires meshes, which means a lot of data that will probably be a total waste anyway.
One more consideration is that quite soon Cycles X will be the name of the game, and with it Brecht is writing new bake kernels. So it’d probably be best to hold off on any performance optimizing until Cycles X has been in master for a little while, and focus on just making the addon compatible with the shiny new context-agnostic bake API that’s supposed to be coming.
After all, there will still be a need for Bake Wrangler since the devs’ thinking is stuck in the stone age with a node-less UI.
Also, you should probably charge us for the new version when Cycles X lands. You’re doing great work after all.
The current settings are pretty optimised for what I do… My bakes pretty much are all less than 5 mins and 30 seconds more or less doesn’t really matter to me, given it used to take me over an hour to achieve the same thing!
But yeah, there are a few other things I need to work on. UDIMs and some niggling UI issues (changing to a different node editor and back doesn’t restore you open tree for eg). Things are pretty close to feature complete though, so looking at performance tweaks isn’t too crazy.
Version 2.0 will depend on how much stuff I have to rewrite to use the new API and what new features become available. If it’s a lot of work I will probably have to have an ‘upgrade’ fee of some sort, dunno if that is actually supported by blender market though…
I think on blender market you can do coupon codes for people who have X item.
Do you see this?
Umm, interesting… Though I don’t think there is much reason to create a standalone baker based on cycles…
Well, that if)
i am confused is which is the current version of this addon ?
on blendermarket there is 1.2.b4 and 1.1.1 ? 1.2.b4 has rgb exposed on the nodes but 1.1.1 does not ?
1.2.b4 is the latest unstable version which uses a set of post processing nodes to split and map channels rather than having them on the node. This makes it more inline with how other parts of blender work in regard to colors.
1.1.1 is the latest stable version, but is missing many of the features you can now access in 1.2. Everything you could do in this version is still available in 1.2, there are just some changes to how some things are accessed.
The documentation however is written for 1.1.1. It will be updated once 1.2 leaves beta.
There is baking feature for CyclesX now!!!
Do you have plan to release version for CyclesX
(may be CyclesX give speedup in baking too)
Probably best to wait till CX actually hits master.
Yeah, I plan to make a CX version. I don’t really have a time frame on it though… Like I would prefer to have some documentation on it to work from rather than trying to trawl through source code in order to use it
what if it ends up just being a drop in replacement. and nothing in the way addons interface with it changes.
Then that would be most unfortunate, as the status quo sucks.
That seems highly unlikely… I’m sure at the very least they will change how the output image is selected… Also from what I looked at, the render kernels and bake kernels are going to be unified into a single pipeline. So that should mean things like denoise which currently only exist in the render pipe should become available to bake…