PyGrunn: blender & python: the pleasure & the struggle - Sybren Stüvel¶

Tags: pygrunn, python

(One of my summaries of the 2024 Dutch PyGrunn python&friends conference in Groningen, NL).

He showed a demo video of content created with blender. Blender started in 1994 (python 1991). Like most open source projects, blender is all about the people. Blender HQ is in Amsterdam, btw. They have 51 people on payroll and lots and lots of volunteers. The money comes mostly from donations, sponsors and subscriptions (via a foundation, the office and a studio).

Lots of small studios and game/movie makers can only exist because blender is open source: a good reason for sponsoring/supporting the project!

Now to the python side of things. Python is used as the UI glue. The actual operators that the UI calls are written in python or C++. If you enable python development inside blender, if you hover over user interface elements, you get hints on which python class it is. Right-click and you can get the full path of an object for copy/pasting into the python console. You can then work with it.

Even fancier: if you right-click on some tool or transformation, you get the python code that would be executed if you would have clicked on the tool. Which you can then modify.

Some items in Blender:

• DNA: main data structure of blender. Flat lists of scenes, objects, meshes, armatures, etc. List items are identified by name. The actual file structure hasn’t changed in 20+ years!

• RNA (“apologies to those that know biology”): a wrapper around DNS (sub-)structures. It defines “RNA properties” (I think they’re kinda layered on top of the DNA items ). It is used by the GUI, the animation system and the python access.

• Drivers: small expression for modifying values, like moving a light through a scene. You can also do it with more elaborate python code.

• Add-ons/modules.

• Operators: you can register your own python functions as items in the user interface.

Blender mostly just uses the standard libary. As extras there are requests and numpy and GPU support.

Now on to the pain.

• Getting and isolating dependencies of add-ons. The workaround is to backup sys.modules and sys.path, grab the wheels, do any imports and then restore sys.modules and sys.path. It works, but barely. You can get funny errors when you do some lazy loading. The main problem is that most of the programmers are not really experienced python programmers that might understand this hack.

• pip install can also be used to install dependencies in some central location. Drawback is that it is very developer-oriented. And some dependencies need C compilers which non-developers don’t have.

• The new 4.2 blender will have support for wheels, that helps a lot. But it still doesn’t solve the isolation problem (for when you need different versions…). Perhaps a custom import hook could help? Perhaps a fixed list of specific package versions to use? Perhaps sub-interpreters? If you have a solution: talk to him.

Personal note: I had to do something similar for a “geoserver” add-on. Similar problems. I did some really clever stuff, but in the end it got all ripped out as it was too complex and people kept finding corner cases.

• They want blender to work without a network connection for security/privacy reasons (except when you explicitly allow it). This also has to be true for addons/extensions. And they struggle a bit with a reliable way to reliably restrict extensions in this way as it is “just python” and you can effectively do anything. If you have a solution: talk to him.