So @rawalanche came to me with a problem trying to bake basically billboard textures for trees/grass/etc. This isn’t something you can actually do with blenders baking system, since as far as I know there is no way to get bake rays to pass through a face based on an alpha value or anything???
But you can bake it using the camera renderer plus a bunch of emission materials. Is there an addon which makes doing that simpler?
If not, is it something people do enough to want an addon to handle?
Hi, yes definitely!
Quite a few times already I’ve ran into a scenario where I wanted to bake a simple PBR texture set using BakeWranger. A simple, tiled square texture with all the PBR channels (Albedo, Roughness, Metallic, Normal, etc…)
Right now, I have to “abuse” the bake from-to system, and use a regular square plane in place of orthographic camera. That’s not good, for both the reason of issues with baking opacity mapped stuff, as well as workflow issues, as baking from-to geometry is usually meant for baking high poly mesh detail and attributes onto lowpoly meshes.
Right now, the workaround is really a bit ugly, requiring to put a plane under what I want to bake, and then set up the cage/offset settings:
Ideally, I’d expect an option where I can use the camera as “target”:
If you think about it, right now a “target” mesh is already sort of a “camera”. The UV space of the target mesh is used as a camera, and rays are emitted from each triangle in the UV space, instead from the camera frustum. So internally, technically, it’s very similar.
I am not sure if it would be too confusing if it was done this way in the UI, but to me it seems like a simplest solution to add the feature without adding UI complexity. The issue there is that the “Input Mesh” node expects a “Mesh Settings” which contains all the bake from-to mesh settings like cage, ray distance, etc… which would do nothing in case of Target being a camera.
Alternative would be to add “Input Camera” node to complement the “Input Mesh” and “Input Material” nodes. 
you can use an addon called grabdoc
While the to-from is meant for low-high poly, it does work fine for baking to a plane. If I added a ‘use camera’ or just allowed a camera to be the target, internally I would actually just replace the camera with a plane the same size as the camera that I would bake onto.
The reason for this is that using an actual camera requires the complete opposite process. Instead of rays projecting to the object, you need rays coming off the object and hitting the camera.
So it actually would require writing a completely different back-end process where emission materials are applied to the object and captured by a camera. The only benefit I see is that it would allow capturing opacity information which can’t be done via the bake to plane method.
I would have to write a completely new back-end module to handle it and probably want to charge $5 or something for it…
‘grabdoc’ does seem like it already does a decent job of it and also costs $5…? Of course then you don’t get the whole post processing and channel mixing node system that is part of Bake Wrangler…
Honestly, I really like the design of you addon, especially the node based aspect of it, making channel packing and even processing the channels before packing them a breeze. Even if it was a separate addon I’d have to buy again, I would do it. But then again, it would not be worth making it for just one customer, so I will probably just look for a workaround in the meanwhile
I do think it would be a nice option to have. But it’s not a simple thing to add… That said, there isn’t really a lot I need to do with Bake Wrangler now or probably for a while. So I could probably spend some time on it and just risk that no one wants it 
added commercial tag to the Post.
Looks like it may be harder than it seems, even with the camera based approach 
Yeah, you have to create materials that both respect the alpha but also display the data you want to capture. It is possible though.
Yeah, I was about to type that creation of such alternative tool should be much easier with the introduction of custom AOVs in Cycles. But before I finished writing the post, I just wanted to be sure that’s the case first. So I opened Blender quickly to make some screenshots, and ran into this. What a disappointment. If AOVs worked properly, it would make creating the tool a bit easier.
AOVs are supported in Bake Wrangler by the way if you didn’t notice!
I did, I was the one who made you aware of them. I use them almost all the time 
My point was that for camera based baking, it could be easier to simply pipe the Principled shaders inputs into appropriate AOVs and render all at once instead of doing the typical switcharoo of cycling them all through the Emissive slot
Well, if they worked properly, of course
Yeah, you can make a node group with some sliders to turn on/off the various outputs to help a bit… But using the camera to bake with different texture settings for each output is still pretty annoying and time consuming to do.
Basically need to use an addon I think…
So I’ve been playing around with the render changes in Blender 3… As far as I can tell the Denoise functions still do not apply to bakes in any way, even though they were supposed to go through a unified pipeline that included the denoisers?!
Using the Noise Threshold and Time Limit options work with baking. But the denoise is still no good? Or am I missing something? Like it only works with some specific passes?
I’m wondering if people would want to use the Threshold and Time limit settings in baking… Kinda annoying to have 2 extra sampling settings though.
Ah, so the changes are finally in now? Nice.
That would explain why I’m now getting just cryptic “Bake Failed” messages on the latest builds.
Anyone know what was the last hash that still worked as expected?
Hmm. Looking through the latest commits, I can’t really see anything baking related except a margin thing and some bugfixes. Weird.
Hmm, I’m working from a slightly more updated version of the add-on than you can download. I saw something about the unified pipeline a while back, I just hadn’t got around to testing to see if it did anything. And so far as I can tell it doesn’t do anything…
They broke it on Linux a few months ago, maybe that change caught up with the windows version…
I also should note that there are some settings that don’t work in 3.0.1 any more and need to be removed/changed. If you have any of those enabled it causes bake to fail, like the tile size setting for example (currently I only know the tile setting and having AO influence on combined no longer work, not sure if there are any others)…
@netherby
Hello there ! It’s been a while
I’m experiencing an issue while baking with GPU.
For some reason, the lower half of the image is different that the upper and other stuff
GPU on left and CPU on right
Metallic/Roughness
Also, baking passes using the “Bake Image” button gives different results that baking passes one after another. Some parts go missing etc.
Another point i’d like to talk about is the render time. I had to bake a model few months ago so i don’t remember which one, but it took forever to bake (like 30 mins). So i tried with textools and it was way faster (took a minute or two). So i investigated 
My Blender has a lot of addons, and it seems that BW starts a new instance of Blender as is, and so loads all the addons every time, increasing the bake time a lot. So i deactivated the addons that made Blender load slowly, and now it’s fine.
I haven’t however watched at your code, but i suggest you specify in the command line to load factory default, then enable the needed addons.
Anyway, if you need any complementary info, don’t hesitate 
The different results are very strange, though from the add-ons perspective there is no difference in how it handles a CPU vs GPU bake. So it’s more likely a problem with Blender. If you use Optix can you try it with CUDA instead?
What versions of Blender and Bake Wrangler is this with? I can try baking the file on my computer to see if a different graphics card helps…
Can you provide me with an example file where the buttons give different results, is it repeatable or semi random if parts go missing?
I actually plan to have an option (which will be enabled by default) to disable other add-ons in the baking instance in the next version. I decided to do this because there are a few which crash Blender when started in background mode, but the speed-up will also help people that load lots of stuff
I’ve uploaded v1.2.4 which fixes a few bugs and has the disabling of add-ons in the background instance turned on. That will improve the load time and reduce memory usage for people that have a bunch of big add-ons installed.
I have also moved the ‘Marginer’ system to the Advanced area of Output Settings.
This update is labelled as being for Blend_2.9, because I will be releasing a version with changes specific to Blend 3+ soon and it won’t be backwards compatible with the 2.9 series.
I used Blender 3.0 and 3.0.1. For the addon 1.2.3.
I’m on a GTX 1080
Using Optix instead of cuda or vice versa doesn’t change anything.
I will send you the file in Private Message.
Concerning the missing parts, i’m not sure but i think it was random.
I’ll let you test anyway
Thanks for the quick fix concerning the addons loading. And it also fixes another error i was experiencing: bake would faile because of the Erindale Toolkit addon, i had to deactivate when i knew i was going to do some baking.
