Page MenuHome

Can't bake to external textures (Python)
Open, NormalPublic


Hello, when trying to bake an object to an external texture, Blender seems to ignore the "save_mode" and bakes the texture to an internal buffer. I've tried two ways:

import bpy

# Bake selected objects
for obj in filter(lambda x: x.type == 'MESH',
	print('Selected: ' +
	# Select current object
	bpy.ops.object.select_all(action='DESELECT') = True = obj
	# Bake
	bpy.ops.object.bake(type='COMBINED', save_mode='EXTERNAL', filepath='E:\\baked.png', use_automatic_name=True, width=512, height=512)
	# Other version, doesn't work either
	# bpy.ops.object.bake(filepath="//baked.png", save_mode='EXTERNAL')

And also setting the parameters in a different way:

bpy.context.scene.render.bake.filepath = 'E:\\baked.png'
bpy.context.scene.render.bake.save_mode = 'EXTERNAL'
bpy.context.scene.render.bake.use_split_materials = False

Always, the execution of the previous code returns the following and does not create an image file:

Selected: Cube
Info: Baking map saved to internal image, save it externally or pack it
Selected: Floor
Info: Baking map saved to internal image, save it externally or pack it

Tried with different paths and parameters for the bake funcion, also creating image nodes and selecting / deselecting them in the node editor for the material.

Also, I found someone who had the same problem as me, and found no solution:

Exact steps for others to reproduce the error
Find attached a blend file:

It's a simple cycles scene with a cube and a floor, Cycles renderer. It bakes correctly to textures (internal buffer).

  • Open the blend file or create your own scene
  • Run the code written above
  • Blender won't create a bake file, in the console you'll see "Baking map saved to internal image, save it externally or pack it"

System Information
Windows 10, nVidia Quadro K5100M

Blender Version
Broken: 2.79b f4dc9f9d68b, 2.77a abf6f08

Thank you



Event Timeline

Found this from 2014 in blender/source/blender/editors/object/object_bake_api.c at the end of:
static void bake_init_api_data(wmOperator *op, bContext *C, BakeAPIRender *bkr)

97641a0ec946 (Dalai Felinto 2014-01-02 19:05:07 -0200 1166) /* XXX hack to force saving to always be internal. Whether (and how) to support
97641a0ec946 (Dalai Felinto 2014-01-02 19:05:07 -0200 1167) * external saving will be addressed later */
97641a0ec946 (Dalai Felinto 2014-01-02 19:05:07 -0200 1168) bkr->save_mode = R_BAKE_SAVE_INTERNAL;

@Dalai Felinto (dfelinto) Is this something that would be hard to implement, or has it just been forgotten in the annals of time?

The hard bit about implementing this is in regard to the usability side of things. Right now each object can have its own materials, that in turn use their own textures.
To bake only to external textures means you are restrict to a single texture. Not the end of the world (and probably not hard to implement). But this is the historical reason for this missing bit.

Hi Karl, Dalai, thank you for taking a look at this issue.

I'll tell you my objective for baking external textures: I work for a company that makes software for broadcast environments; in particular, virtual sets. I want to promote Blender between our customers, and they need baking to create realistic virtual sets.

In 3D Max Cinema4D it's trivially easy to bake textures for whole sets with lots of objects; in fact, they bake a file for each object (well, they can create multiple files like for separate diffuse / AO). I tried to replicate that behavior creating a script that bakes each object individually and then relinks its material to each baked texture.

This behavior (preventing external baking, even with Python) makes it difficult to integrate Blender with our workflow, and making a workaround for this might be too expensive for me to implement.

Thank you, and greetings


Just to say that I compiled Blender removing that line, and the script worked without need for modifications. We can now easily integrate Blender in our workflow! (through custom builds)

Please, could you consider disabling that behaviour in official builds? This will be useful for advanced users (scripting), and it shouldn't affect casual ones because it's not exposed on the GUI.

Greetings, merry chrismas and happy new year :)

I'm confused as to what you changed. Can you share the git diff?

This is the patch, I modified Debian sources, not the git directly, it's just a single line.

This allows basic baking, however I think it's incomplete because Blender show messages like:

Info: No active image found in material slot (0) for object "Cube"
Info: No active image found in material slot (0) for object "Plane"

... when the materials don't have a dummy image slot pointing to a dummy image buffer. In this case, that buffer isn't really used because the bake is external. I tested this creating a 32x32 buffer and baking to 512x512 files; the later dimensions are used so this buffer is not really neccesary and just complicates the designer's workflow.

I could patch the bake_objects_check() function, adding a conditional like


However that may require changing the function signature to receive that parameter, and I prefer to ask you guys what would be the best path to reach a clean, official solution.


The biggest downside of this, is that unlike internal baking, you are here limited by one image per baking in total. Which is a limitation we can live with I suppose, otherwise I don't see how else we can proceed.
So if you can provide a patch that address the error messages for the external baking (and submit as a patch on, mentioning this issue) I will gladly review and commit it.

Thank you for your time, Dalai

I tried modifying the code for the validation function in the frontend, but skipping the error and then baking crashes Blender. The bake is trying to access something related to that image node.

If I am able find an adequate solution, I'll post a patch.


Sebastian Parborg (zeddb) triaged this task as Normal priority.

I'll assign this to you @Miguel (mo_brainstorm) as you already seem to be on it.

@Dalai Felinto (dfelinto) do you have any time to review the patch in the near future?