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).
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)
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: Bpy.data.images 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.