Blender Python API Papercuts

A long time papercut for me is poll().
I’d love it if you could (optionally?) apply poll() only to the first run of an operator - so only when its called from a menu or shortcut, but not for redos.

If you build a tool, that ends with different conditions, for instance a different object selected/active than at the start of the tool, and that object doesn’t match the poll requirements anymore, than you either can’t use poll() or have to make it more vague, which then requires additional checks inside the tool.

Applying poll() to redos therefore seems uneccessary, because redoing resets the starting conditions anyway (unless the operator pushes an undo itself).

  • bind and unbing Surface Deform and Mesh Deform without bpy.ops
  • is missing frames pr. sec and aspect X and Y values.

scene.ray_cast needs some sort of object mask property to ignore specific objects. so tired of handling self-intersections and avoiding selected objects

usage would be:
objects_to_ignore = bpy.context.selected_objects.copy()
objects_to_ignore.append( some_other_object)
results = scene.ray_cast( view_layer, ray_origin, direction, mask=[objects_to_ignore] )

no more ray hits on the objects you have selected when your ray originates from the selected object!

Shader parameters are indexes and not named tuples.

This thread is a really good idea. Here’s one more papercut:

When doing python stuff on the armatures, the edit bones (and their values) are only accesible from armature’s edit mode. If the mode is object or pose, you can’t for example access the bone’s roll value.

Some way of detecting an in-progress modal operation is needed for so many things now that we have Tools and Timers. I wrote an autosave incremental addon for the artists at my studio and they’re complaining about hitches while sculpting. If I could detect modal operations in progress I could delay the autosave until after it completes (this is one of many examples I could give)

When saving a .blend file, we cannot choose which object to choose.

Here’s a couple of things that would be really useful:

  • Faster data transfer between Blender image data and Numpy. Currently it takes seconds to transfer 2k textures. Ideal solution would be a Numpy proxy, that has next to zero overhead (Numpy using the same data pointer as Blender internally). There was already an attempt at solving this but I don’t know if it went anywhere: perf issues

  • Raycasting with packets (multiple, like 100k rays inside a vector which would take only 1 function call) instead of single function calls would make the BVH much, much more powerful from the Python side. Again, Numpy would be a good solution here. I’m assuming that the overhead here is function calls, as you’re making them millions per second.


Yes and no, it woks well for what i’m using it for, but for inclusion in master i needs more testing/cleanup which i haven’t found time for. If anyone wants to pick this up from my patch, go at it, if not, it’ll get to it… eventually (it’s a side project i use it in, and the time i have for those is shockingly low recently), could be quite a bit before i’ll have time.


Totally agree, this would make things like circle/polygon casting much simpler.

On a related subject- BVH raycast has no option to ignore backfaces, so if you have an inverted cube and try to bvh raycast from the camera’s view you will always hit backfaces before any front-faces. SUPER annoying.

One that’s bugging me lately- There’s no way to apply, remove, or duplicate modifiers without using bpy.ops, which means if you’re doing a lot of these in bulk there’s a lot of select_set() happening.

Not sure what you mean? Why select_set()?

Anyway, you can use context overrides to avoid changing the active object:

override = context.copy()
override['object'] = some_object
bpy.ops.object.modifier_apply(override, modifier=some_modifier_name)

For removing you can use object.modifiers.remove(some_modifier)

1 Like

Interesting, it never crossed my mind to use an override for that even though I’ve used them plenty of times in the past for other things. Learn something new every day!

It’d be nice if Blender’s internal walker functions were exposed to the Python API so add-on devs wouldn’t need to write their own from scratch.

1 Like