21

I want something along the following lines:

import bpy
object = bpy.data.objects['Cube']
bpy.context.scene.objects.active = object
bpy.ops.transform.rotate(value=0.638031, axis=(-0.818828, 0.361665, -0.445779), constraint_axis=(False, False, False), constraint_orientation='GLOBAL', mirror=False, proportional='DISABLED', proportional_edit_falloff='SMOOTH', proportional_size=1)

But I still have to select the object manually. How can I make the object active using python?

Amir
  • 3,074
  • 2
  • 29
  • 55
clankill3r
  • 1,191
  • 1
  • 12
  • 32

2 Answers2

77

Just a little update if you are searching for this for 2.80 and up:

The active object has moved from the scene to the new view layers system, as you can have multiple active objects across multiple view layers.

bpy.context.view_layer.objects.active = ob

As mentioned by mentalist in the comments below, you can also set the active objects to "None". (Because "None" is predefined in Python.)

bpy.context.view_layer.objects.active = None

Also see: Blender 2.8 API, python, set active object

brockmann
  • 12,613
  • 4
  • 50
  • 93
morph3us
  • 1,449
  • 1
  • 10
  • 21
38

Answer to your question

With python, it is better to not use bpy.ops at all, but to just manipulate it's rotation directly. To answer your question of how to make an object active in python:

2.8+

bpy.context.view_layer.objects.active = some_obj

2.7x

bpy.context.scene.objects.active = some_obj

Better ways to rotate objects

After getting an object, e.g.,

obj = bpy.context.object

It would be much better to manipulate transforms directly though:

obj.rotation_euler.x += x_offset

Or

obj.rotation_euler.rotate(Euler((x_offset, y_offset, z_offset)))

Or

obj.rotation_euler = (x_value, y_value, z_value)

Or

obj.rotation_euler.rotate_axis('X', math.radians(45))
JakeD
  • 8,467
  • 2
  • 30
  • 73
  • 4
    Why should one avoid bpy.ops ? – McLawrence Aug 28 '17 at 05:43
  • 6
    @McLawrence Mostly because of speed. When you call an operator, Blender will do a scene update before continuing. This can become very expensive especially if you are calling it in a repetitive manner, e.g., in a loop. Check out this post by one of the Blender developers on the site for more info. – JakeD Aug 28 '17 at 23:32
  • bpy_prop_collection: attribute "active" not found – Phil May 11 '22 at 16:21
  • @Phil See answer below. This was written in 2017 for an older version of Blender's API – JakeD May 11 '22 at 16:32
  • I disagree that it's better not to use bpy.ops. By default, code should be optimized for coding speed vs. execution speed. Only if performance becomes noticeably bad should one look into low-level optimization. – sw1337 Jun 19 '22 at 23:47
  • @sw1337 It's not "optimized for coding speed" to use a UI function instead of the tools Blender provides for easily manipulating transforms. There's no reason to be lazy here. Premature optimization is also hardly relevant to stack exchange because this code will be widely used by others looking at this answer. – JakeD Jun 20 '22 at 13:34
  • @JakeD, don't get me wrong, it's great to have multiple different ways of doing things. But saying that it's best not to use bpy.ops is a purist opinion that you stated as a fact. In the business sense, it's actually much better to use higher level functions that abstract away complex implementation details. It makes coding and maintenance easier for a larger range of developers that come and go in a team. – sw1337 Jun 20 '22 at 19:07
  • @sw1337 The blender devs give a better explanation than I can: https://blender.stackexchange.com/questions/2638/run-an-edit-mode-operator-on-every-object-in-the-scene/2639#comment4435_2639 and https://blender.stackexchange.com/questions/2848/why-avoid-bpy-ops#comment11187_2848 and I don't see how what the OP posted is any easier to read than any of the 4 things I said. This was half a decade ago lol, but I'm sticking to what I said. – JakeD Jun 20 '22 at 21:06
  • @sw1337 For end users, performance is almost always more important than the speed of coding. Who cares if you code an app in 1 month instead of 2, only for it to unecessarily waste massive amounts of time in the long run (potentially 10's of thousands or more dev hours worth) due to low performance for making a movie or something? I get your point about code maintenance, but end users in production environments often care about completing production tasks with the software as quickly as possible rather than how quickly they get the sotware in hand, and the same goes for things like games. – SmugDoodleBug May 09 '23 at 19:23