Blender is shaping up to be the best open source project I've seen in my 20 years of tech, and I'm comparing this with many other large ones I've used, like Linux kernel or various distros, FreeBSD, Kubernetes and so on. They do everything so well, even the releases, I think it beats the paid competition now or will soon do in feature parity and ease of use. As of Blender 2.8 the UI is fantastic.
This update comes with many geometry node improvements which continue the trend of making Blender the premium non-destructive modelling solution. I'm in particular interested in seeing how 6900 XT and regular M1 (in Mac mini form) will perform under Metal with 3.1 and macOs 12.3. I was a long time Radeon VII user on Mac but before 3.0 the stability and performance was just not there so I've moved my Blender experiments to Windows and Nvidia which works spectacularly but I'm not fussed about booting win just for Blender. Sadly I don't think AMD is bringing HIP for their older, pre-6000 GPUs https://code.blender.org/2021/11/next-level-support-for-amd-...
100% agree. I've been using Blender for over 20 years as a hobbyist and it has consistently been one of my favorite pieces of software. It's written by creators, for creators, and you can feel the love and care that they put into it.
One area I wish they would start to give more attention is their scripting. I consider myself a Python expert, and the Python API leaves a lot to be desired at an architectural level. For example, many operations (bpy.ops) require an accurate "context" to succeed. This context is essentially putting the UI in a particular state, as if the user had clicked specific items and activated certain windows. This makes the api feel like an afterthought to the traditional UI interaction, and introduces a number of issues that I won't bore you with. Suffice to say, you end up writing a lot of boilerplate to ensure predictable state changes in between operations.
If they levelled up the Python API to be more friendly to the code-oriented generative art crowd, they would be even more unstoppable!
Another example is how incompatible "bpy" is with Python idioms: in Python you're supposed to use `is` operator to compare identity, but since many objects in bpy are short-lived wrappers of the actual C++ data, you have to use equality operator `==` instead. Otherwise you may run into such problems:
"is" is a pretty special operation in python. The only thing it can be reliably used for is to check if two things refer to the exact same object. Retrieving the same value twice has no guarantees about returning the same object twice.
"is" causes so much confusion I'm not sure if it should've been a part of the language in the first place. It can always be substituted with the more explicit
`1 is 1` gives `True` in CPython because numbers in range -5..300 are reused (not 100% about the exact range). This is not a problem, because there's no practical need to compare identities of two integers. There is however a need to compare identities of two bones, for example if you want to parent all selected bones to the active bone, but the active bone is also selected, so when you iterate, you check if the iterator `is not` the active bone before parenting.
Of course in the end of the day it's not a problem that you have to use equality operator instead for bpy wrappers. It's just surprising, non-idiomatic in Python, where a developer unaware of this gotcha would rather think using `==` can give `True` for two different bones but similar enough that the `__eq__()` returns `True`.
Substituting with `id` solves nothing and goes against Python's spirit.
I know why "is" works like it does. I'm just pointing out that having two equal objects from the same source not be the same object IS idiomatic python. The reference implementation does it with something as basic as integers!
Substituting with id goes against the python spirit because "is" exists. I'm trying to argue that "is" probably shouldn't exist. It's a bit of a footgun.
You are simply wrong here. The `is` comparison you show is a CPython specific quirk, and not part of the Python philosophy. How could you think otherwise if it's inconsistent and doesn't apply to all numbers in the same way?
Glad you brought up scripting! I'm 2 years in my Blender journey. I remember downloading it before YouTube existed, took hours to compile the FreeBSD port, launched and got overwhelmed by the complexity, it ended there.
My goal with Blender is to animate explainers and screencasts, how feasible is to have a procedural pipeline where I could just launch Python scripts changing basic properties like text, position? Basically I want to generate animations where I have a bunch of re-useable objects but change their properties via code, is this something Python bindings could help me?
Funny you should ask! Yes, it can be done. I've built something like this recently...my goal was to make programmatic videos of chat conversations. Here's an example[0]. This was rendered totally headless (no launching blender UI) and the input file was a json document that was generated programmatically. I'm in the process of containerizing it so it can be run serverless in the cloud, driven by a job queue.
I currently run blender in a docker container headless on google cloud run. I generate 3D model and render animations of them. Here is one I did today:
You've just blown my mind! Wow, this is something I'll spend my next 3 months before summer definitely. Thanks for the inspiration and showing the possibilities, the headless part is just icing on top.
Each text bubble is duplicated from a rigged template speech bubble. The rig controls the dimensions of the bubble based on the size of the text it contains. Drivers are heavily used on the bones to coordinate them with other bones and movement.
Each bubble is parented to a screen object which scrolls upwards, but the parenting is dynamic, so that it only engages when the message has been "sent".
The "typewriter effect" of each bubble is not keyframed (unsupported) but handled by a frame update callback. The typing is determined in advance with random jitters to emulate a person typing.
Hope that explains it! I have considered sharing the framework, but I know I will get a lot of requests that I'm not prepared to handle unless I was receiving donations.
> For example, many operations (bpy.ops) require an accurate "context" to succeed.
The bpy.ops are really just a python shim to be able to call them from the UI.
Not a good idea to call them from a script (because of the reasons you cited) but that hasn’t stopped anyone, ever. The whole of blender is designed around the MVC model and the operators are the ‘control’ and are dependent on the ‘view’ (aka context) to do their thing.
All the underlying data structures should be exposed to the python API (through bpy.data IIRC) so, in theory, one could do whatever their little heart desires.
Weird design but once you realize the UI runs everything through python it mostly makes sense.
Definitely, prefer using bpy.data objects whenever you can. IIRC there were a few things I wanted to do that only seemed possible through bpy.ops, for example recursively duplicating a collection. In the UI, this calls bpy.ops.outliner.collection_duplicate() and requires the Outliner editor to exist and be active. There are workarounds, but they aren't pretty.
Back when I was poking at the python API a lot of what I did was figure out how the operator did it and either wrap the function it called as a method on the object or write a simple C function wrapper and expose that to python. Most things that people needed just needed someone to spend a little time on.
I think it was the outliner (the part where you edit the keyframes?) where the underlying design made the python API an absolute trainwreck. I spent a bunch of time on that and it was just bad, the best that could be done was to expose it and let people who were sufficiently motivated dig around and figure out how all the pieces interacted because it wasn’t at all obvious. Horrible design from the python side…
Anyhoo, sounds like someone just needs to add a collection.duplicate() or .clone() method — whichever is more pythonic.
I totally agree with you. I use the python API in Blender to make some renderings of mechanical connections we are developing. As a python expert I am always a bit disoriented by how things should be handled. It would be really great if the python API could get some love in the future.
Besides being context-sensitive, I also recall the API being weirdly designed w.r.t. mutable variables, global state, and so on. The kind of stuff you expect to see when someone who is not primarily a programmer, but is instead an artist or something, designs an API (which I would guess may be what happened).
In the end I was able to get what I wanted (a script which would spawn a bunch of geometric objects according to a procedural function, set the scene, and ray trace a frame) but it took a bunch of weird incantations in a mix of API idioms.
Yes, it's quite bizarre. I have used blender to generate training data for a neural network (which was a stunning success, and quite fast compared to any other method I could think of).
I had no clue how to use blender before, but now I feel like I have at least a passable idea of how the UI works -- despite basically never having touched it!
I still think PostgreSQL wins on the clean codebase competition. It's a thing of beauty.
Don't get me wrong. Full props to Blender and its contributors. The UI/UX, speed, and stability have improved by leaps and bounds in the last few years. I miss the game engine though.
This update comes with many geometry node improvements which continue the trend of making Blender the premium non-destructive modelling solution. I'm in particular interested in seeing how 6900 XT and regular M1 (in Mac mini form) will perform under Metal with 3.1 and macOs 12.3. I was a long time Radeon VII user on Mac but before 3.0 the stability and performance was just not there so I've moved my Blender experiments to Windows and Nvidia which works spectacularly but I'm not fussed about booting win just for Blender. Sadly I don't think AMD is bringing HIP for their older, pre-6000 GPUs https://code.blender.org/2021/11/next-level-support-for-amd-...