Thanks Piotr and Happy New Year 2015!
Bye bye
Spirou4D
PS: Yes indeed, a tuto would be great apreciated, may be…
Nope. Like I said, I’ll make one next week. Next up, a Material ID pass. Then either custom outputs or a curvature pass.
I’d think it’s pretty intuitive though. Add one or more lowpoly/highpoly pairs of stuff to bake to the same texture, add the passes you want, and hit Meltdown. The baked textures will appear on the disk (in the same place as your .blend, by default in the ‘textures’ folder). That’s about it.
Okay, thanks, that would be excellent! 
Hey, i’ve just started using this addon and i’m really enjoying it, i’d love to actually make a version that integrates with a asset organisation plugin i’m working on at the moment called Capsule. This has been super-helpful regardless in setting up a scene for baking, and batch-baking and exporting assets,
Theres a few things i’ve noticed with the plugin that at least seem like bugs. Whenever it prompts me that a object isn’t visible in the scene, or that the wrong rendering engine has been selected, it won’t for example get rid of the duplicate scene it makes for baking. It doesn’t seem to clean up after itself if it can’t successfully perform the bake operation.
Id also like to suggest two things:
- Have the program automatically show and hide an object before and after baking, if the objects required are hidden. When baking i just like to focus on my low-poly meshes being baked in the scene, and it’s annoying to see the high-poly models clip into it. It would be nice if the plugin could also automatically switch rendering engine (if this can even be done in python), so it doesn’t interrupt your own workflow and setup so much.
- Be able to automatically preview maps on the model - particularly for things like normal map baking, its important to see if you’ve screwed up the map bake, and if so where. It’s not particularly important for the normal map to be properly shaded on the model, but as long as it can be seen as a diffuse map it would still be helpful for troubleshooting.
Thanks for making it, this is looking awesome.
Glad you like it
The code is GPL, you’re free to integrate it with whatever you wish. Just fork on github and have at it.
Ad. issue 1: will fix. Although Meltdown should just not show up if you’re not using Cycles, I think.
Ad. issue 2: since you can’t really predict where the script will fail, this would involve lots of try/catch statements, which would really make the script less readable while i’m still developing it. I’ll do it eventually, but closer to where it’s actually feature-complete. In the mean time i think i should focus on just getting the script to not fail (as often)
Ad. suggestion 1: I’m not quite sure what you mean here. I usually put mi hipoly and lowpoly meshes on different layers so I can switch between them easily. I think the script, as far as possible, shouldn’t do anything to your original scene.
Ad. suggestion 2: I had planned on adding opening the baked textures in the UV editor after the bake. I guess I could also put an image node in the lowpoly’s materials and put the viewport in texture mode. I’ll think about it.
If I get round to adapting it, will do 
Issue 1 - Sweet - the addon does show up regardless of what rendering engine I have selected, although I think this is a good thing tbh.
Issue 2 - Well you already catch some bugs, like when it finds the wrong renderer is being used, I merely suggest to point the code to some end of process clean up function when it finds one of these bugs, so if the code does fuck up, extra scenes and components aren’t left behind, but obviously making it fail less would also be good XD.
Suggestion 1 - Currently I setup my scene so all objects are on one layer, as I don’t like the layer system a whole lot. I prefer to isolate objects using the outliner when working on them by hiding them, but your script can’t recognise whether or not an object is hidden before trying to operate on it, as a hidden object is unselectable. It would be cool if at the very least, your plugin can recognise if an object it needs is hidden and unhide it for the operation, and then if possible hide it again after the operation is complete, so it doesn’t visibly affect the scene, or require me to setup the scene in a specific way to bake it. Implementing a check for this is relatively simple in python scripting from implementing it in Capsule. Your layer method does have some advantages though, so I guess ill use that at the moment.
Suggestion 2 - Okay, sounds good :).
Ad suggestion 1: Ah, ok, yeah, I was confused because you also mentioned it in issue 1, will fix. Probably today, along with the MatID pass. Actually, it’s supposed to be already working now, but I must have broken it at some point 
Alrighty.
Material ID pass is in. For now it just bakes the viewport color of the material, so you have to set them before baking manually. I’ll add support for random colors later. Actually, if someone has a suggestion on how to select colors that are random, but deterministic, so that the colors aren’t different for every object every time you bake, I’d appreciate that.
Also, objects should bake now regardless of visibility. You can hide everything in your scene, and it will still bake fine. (But not for environment objects. If you want to bake in a specific environment, and you haven’t set up an object group for that, those objects must be visible and renderable.) Cages on the other hand will always be hidden since I can’t count how many times this tripped me up, and I can’t really see a use case for keeping the cages visible for baking.
Grab the update at the usual place (link in signature).
Oh awesome, thanks a lot. I will test and see how it goes! OwO
Eh, forgot the case where there’s a group for hipoly objects with the matID pass. It’s already fixed, but you may want to update again. Sorry!
(actually, I recommend you just clone the repo to your addons folder instead of using the zip, for easy updates)
Haha, thats fine. I’m still a noob when it comes to using Git, so for now i’ll download manually, although ill probably clone it next week after i get to grips with it :3
On the new Material ID pass, does it just take the diffuse colour of the object?
Hi @Piotr_Adamowicz,
I have the answer about your question: because I wanted to make an add-on for bake materials ID: use the “btrace addon” code
in contrib does some materials & materials utilities has some nice code. maybe you could randomize the color ramp & apply random mats? @Meta-Androcto
Its board is a very good appreciation python coding, I watched what he was saying and indeed there is a color pallet distribution tools and ramdom feature too in the last “Color Blender” panel.
Good luke!
Friendly.
Spirou4D
Last release: http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Curve/Btrace
What is this way to ignore my contribution Piotr?
You answer the others but not to my aid? really strange!
@Spirou4D, thanks, I’ll look into it. It’s not only about making a palette though, it’s about assigning the same color to the same object predictably each time.
@Crocodilian: No, it uses the viewport color:
Edit:
Eh? But I did answer? I was having breakfast. I don’t sit in front of the computer all the time
it’s about assigning the same color to the same object predictably each time
Not you don’t use the viewport color because there are a lot of mat in a object. You can’t use the diffuse color because some mat are the same diffuse color. You must attribute a different color in a x color palette ramdomly or not.
x is the number of mat_ID.
But not always the same for all process, only one different color by matID, it’s the only rule!
Well, yeah, slip of the tongue. I meant assigning the same color per material, not per object.
yes but mat viewport color must be different others mat viewport color and it’s just difficult to organize this with much objects.
I know, it’s a difficult question between viewport color or list of custom color automated by number of mat in one object only for matID baking. It’s a choice!
on the other hand, for create the x color by mat, you must use a fractal process:
you must choose one color and then, remove this color of the list and choose the second color in the (list-first color) et then…etc…and then x time, to obtain x really different colors.
The problem is not obtaining x different colors. That’s easy.
The problem is to keep assigning the same colors to the same materials even if the scene changes, the number of materials in the scene changes, names of the materials change, the shaders in the materials change, etc.
You really want to keep assigning the same colors in the mat ID pass because if you have a node setup in Substance Designer for example, then that setup depends on getting the same colors for every material.
Right now I think I’ll just assign colors at random if they’re not set and save them for future use as a material property.
The problem is not obtaining x different colors. That’s easy.
Not it’s not so easy…think really that!
And that make Substance Designer is not the ref!
MatID map is just a map to select the area of a mat in one object and depend only of the job you make with this object.
It’s just a selection map by material.
BUT in a blender file you can have two different mats with the same viewport color by mistake, you can not prevent this!
And with your matID map, you can’t select this two materials because they can have the same color by mistake.
Yay, someone else uses Substance Designer <3
Couldn’t you just technically leave this up to material assignment, and use material linking to use the same IDs across scenes and files?