Yep. And in a couple other situations too.
Edit: I’ve fixed this particular error, turns out I had just deleted a line accidentally while refactoring. I wouldn’t be surprised if there’s still a whole bunch of situations where the addon bugs out though. Keep the reports coming.
Hello.
I found your addon very cool.
I think we can improve its usability a lot in some areas:
Bugs:
There are also issues with materials. but i’ll describe them later.
Improvements:
There are also many improvements need to make the script to be Pro. If you want to make it pro - we can make it step by step.
I did TextureAtlas script. So, i can be helpful in python too.
I’m glad you like it!
About bugs - see notes in 1st post - there are currently no sanity checks in place. Up until yesterday the script was just a huge for loop, so I didn’t want to complicate it any more than necessary. Now that I’ve refactored it into several functions I can start adding sanity checks. In addition to the situations you listed, I’m trying to figure out a way to check if the cage has the same topology as the lowpoly (which is not so certain if you’re using a triangulate modifier for example and there’s a single quad triangulated differently somewhere).
Lowpoly groups (as well as lowpoly vertex groups) will come, but my concern there is ensuring that works with cages. Rather than bothering with duplicating and merging single objects, what I’m going to do is duplicate the whole scene. That way I can make all the destructive changes I need and then just delete it after the bake without bothering with any cleanup. I can then also use the compositor to do a bunch of useful things (such as antialiasing by baking at higher res and scaling down, and correct margins on multipart bakes via the inpaint node).
The TextureAtlas scripts is one of my favorites! If you want to help, you’re very welcome to do so, just fork the script on github and send pull requests 
Ok, i get you about bugs.
About lowpoly groups - it’s great.
About duplicating of entire scene - i think it’s not good, as you will duplicate millions of polygons of the hipoly models. I think it’s simplier to duplicate a lowpolyGroup and merge into one object.
Another Improvement we need:
What do you think?
Ok, i’ll fork the project and will be helping when i get some free time.
Yep, I totally agree, it should be possible to rebake only one part. I’ll put that on my to-do list. There’s a slight problem there with margins - if you set them too high they might cover other uv islands. But unless we keep all the previous parts separately, I don’t think that’s solvable, so the user will have to look out for that.
I think duplicating the entire scene is the right way to go mostly because of this issue. With just 4-5 hipoly objects, the memory cost of the hipoly[i].pixel_array at 4k (that’s 28 * 4096 * 4096 * 5 = 2.24GB) will outstrip the cost of the geometry in most cases. If I duplicate the scene, I can join the hipoly objects into one, save memory in many cases, and speed up baking. It doesn’t seem like the issue will be solved anytime soon.
Cool that it will be possible!
Well, Cycles baker is still WIP. I think devs will make memory usage as in BI-bake (which merges all objects automatically during baking). This issue is only for Cycles. And i think it will be solved soon.
If you duplicate the scene - you get (2.24GB * 2 scenes (blender memory)) + Cycles baking which takes memory too.
The addon will be unusable in this way.
I suggest don’t merge hipoly groups. And don’t duplicate entire scene.
Also, Cycles has this issue https://developer.blender.org/T41126
So, it’s still in development.
Cycles baking takes much memory even for small ammount of objects as you can see.
Tha same baking in BI and Cycles:
BI Baker - 2.6Gb of RAM
Cycles Baker - 3.7Gb of RAM + 1.5Gb of physical memory.
I hope this is good argument not to merge hipoly and not to duplicate entire scene.
I think you misunderstood. That 2.24GB is just for the bake buffers, that’s not the scene data. And it will grow really really fast if you add more hipoly objects to the hipoly group. With 10 objects it will be 4.5GB + geometry. With 20, it’s 9GB + geometry. Even if each of those objects is just a small detail with 100 triangles. If I merge all hipolys into one object, at 4k it’s going to be a fixed cost of just 448MB + geometry, regardless of the amount of hipoly objects, which is really not so bad.
Other benefits are that we can do much less cleanup, so there will be fewer bugs and less complexity, and that we can then use the compositor to do stuff with textures.
The bug you linked to is a duplicate report of the one I linked to (and has been merged into it). While the bug hasn’t been tagged #wontfix yet, it seems the current recommendation from Dalai is to merge objects, so that’s what I’m going to do.
But duplicating hipoly and merging hipoly models - will take much time. Why don’t you want to leave it for 3dArtists which decide what to merge? I think this is not for the addon but more for artists who should do it manually.
Nah, it shouldn’t take much time at all. It does the same thing whenever you press F12 to render. Maybe a few seconds at worst.
While it’s pretty easy to merge stuff manually, it’s often much harder to unmerge it later and rebuild the modifier stacks if you need to change something. Baking shouldn’t require you to do anything destructive, so I think merging should be temporary, automatic and handled by the addon, not the artist.
Ok, let’s do it and make tests. 
No problem if it will be ok.
Do you think you would be able to add an option where I don’t have to add a hipoly for baking but instead use a Normal Map applied to the Lowpoly and bake the Normalmap Information to itself?
Baking the Normalmap Information is so much faster than having to Import your Hipoly and bake from that.
Like another Button with “Normalmap” next to the “Object” & “Group” Buttons in the Hipoly area.
Cheers Christian and thanks again for this Addon
Nope. Cycles doesn’t currently support this. It’s a planned feature in Cycles and it will come eventually, no point trying to find complicated workarounds.
Thanks Piotr a nice addition to the UV tool sets we can never have enough tools, so peace guys.
Hi actimelvanille,
What do you want to say…baking with a normalmap to what? Displacement may be? Good idea but with a textures soft you can like CrazyBump or Ndo2…or xNormal. It’s a transcryption, an approximate but not a baking process actually.
or
If I understand you want to bake(like Sverchok add-on for parametric meshes) a volume with a normal mesh and bake to a texture then.
I don’t know a soft that make this…but in future, may be. Good idea!
Bye bye.
Hi Piotr,
I work now as I had to you said on this future feature for baking process with the job of the old “Material by Element” add-on…
Your addon is a very Suiss knife… Congrats!
Hi, i can’t make it work. can you show a demo on how to set it up?. I’ve tried a lot an i keep getting black images when i bake. I tried normal, diffuse, everything
Need a video too ^^
I need to be in cycles render beacause the addon needs a node tree to work.
The normal map tangent is in world when baking.
The AO is Black and the color too.
Can you help me on this ?
thx 
Hi folks. It’s been a while. There’s an update on GitHub.
The AA Sharpness setting is just the filter size. Avoid extreme values (close to 0 and 1) for best results.There’s a few more things I’ll be adding next week, maybe I’ll make a video afterwards.
Re: black renders - There’s a bug somewhere which sometimes causes a black image, particularly if you Render, cancel the render, and then bake. I can’t quite track down what causes it. Right now in most cases, if you just re-bake, the black should go away. Also, if you’re using cages, make sure the cages aren’t renderable, or they’ll make AO black too, due to secondary rays hitting them!
Also, there’s been a lot of changes under the hood, and I haven’t had the time to test it very thoroughly, so there’s a good chance I missed something. Report bugs!
Hi there! Is there a video or a written tutorial on how to use this addon? Thanks.
