Blender is hands-down my favorite piece of software I've ever used. I use it for professional purposes semi-regularly, and with each new update just keeps on getting better and better.
Excited for the 3.0 releases!
Blender's Python API on the other hand is very poorly documented, and - to me - seems poorly thought out. It's not really designed as an API, it's just exposing the existing C++ code, and usability is not a concern. It feels tacked on, leaving lots of gaps. Somewhere I've seen a quote by Ton Rosendaal that Blender is for artists, not for coders. If you want Blender to be a competitor for Maya that seems very short sighted.
The one thing that impressed me though, was the speed by which the Blender devs react to tickets. Hats off to them!
All the API changes are also documented in the release notes [0] and the API docs allow to view the Python API for each version [1].
What change between versions caused you problems and what parts of the API docs were lacking?
[0] https://wiki.blender.org/wiki/Reference/Release_Notes [1] https://docs.blender.org/api/current/index.html
What is a problem, though, is that when you google an issue, and find a solution, you then have to upgrade that solution to your version of Blender. That is very annoying because unless you're familiar with Blender, you can't tell if the solution is wrong, or correct but outdated.
I can see that older scripts for 2.79 and earlier may cause the issue you're describing, but this doesn't seem like a Blender specific issue. How did Maya handle API changes between versions? I would assume that there were breaking changes at some point that caused similar issues.
The documentation is great, agreed, but I am not sure you can attribute that to the python part of Maya. The documentation structure goes back to pre python days.
If any of the major studios spent a fraction of their development budget on Blender rather than Maya (and contributed back to the community) I think we could see great strides in polishing Blenders usability for scripting.
> I was always amazed at Maya's basic architecture: Every UI action maps to a command that is run by the interpreter.
That is pretty much how it works in Blender. All the buttons and properties in the UI are accessible through the Python API.
Yes, it seems that way, and I was hopeful at first. But then I tried to use it.
In Maya, you can just copy paste a command from the command window, and it will work.
When you do that in Blender, it will probably give you an unspecific error message like "not possible in the current context". Because you need to manually switch Blender e. g. from Object mode to Edit mode (Faces), and your command only works in that context. So you develop a script that works initially, but later you find that it only works if Blender is in a certain state. That state is nowhere documented, you have to guess what it wants.
While Maya uses arguments to commands, Blender uses the equivalent of global variables.
When you have issues with calling an operator due to a wrong context, there are different ways to approach the problem:
1. Figure out what the necessary context is and switch modes, areas, etc. to match the requirements.
2. Figure out what the necessary context is and override the context.
3. Avoid using operators.
Approach 1.) could be accomplished by checking where the operator is originally used in Blender. For instance the `bpy.ops.mesh.remove_doubles()` is available in edit mode in the Mesh > Clean up menu. Thus edit mode is required to run the operator. This will work for many operators because they don't have very complicated requirements.
Approach 2.) is for when you must use an operator, it requires a complicated context and you know about Blender's internals. You can look at the operator's (poll) implementation and construct a specific context that is passed into the operator [0]. This should only be used if there is no better alternative.
Approach 3.) is preferable when you are working with mesh data. Instead of using regular operators you can use bmesh instead [1]. It doesn't require switching to edit mode or passing a context. It's usually the more efficient approach as well.
[0] https://docs.blender.org/api/current/bpy.ops.html#overriding...
I do agree that the Python API is often just a thin wrapper around the C/C++ code [0] and that the documentation of the required context for operators is a bit lacking for people who are not familiar with Blender's implementation. This is also acknowledged in the API docs [1]. However, I do think the API is quite usable and not particularly complicated to understand.
[0] https://docs.blender.org/api/current/info_gotcha.html
[1] https://docs.blender.org/api/current/info_gotcha.html#why-do...
maya is even MORE layered than just ui -> script commands, there's the intermediate layer of the node editor which shows the scene data as a set of interconnected nodes and what information they're passing between each other (with a few odd omissions) basically any function in maya can be accessed at least 3 ways at 3 different levels of technical skill. where in blender there are still fairly large missing chunks to translate between the UI level, node level and script level.
all that being said it's a very impressive 3d suite and I highly welcome any and all competition!
In 1995 I started my own 3D animation, design and VFX studio. It was a Softimage house on SGI with a DEC Alpha render farm but I had a couple seats of 3D Max as well as Side-Effects Prisms and, later, Houdini.
I have used Cubicomp 3D, Bosch FGS-4000, Vertigo, Wavefront, Alias|Wavefront, Softimage, Prisms, Houdini, Maya and 3D Max packages as well as the Rhino 3D Nurbs modeler and several other long-gone packages including a 3D solids system whose name I cannot recall.
A 3D guru I am not, though. I regularly see stuff today that I just cannot imagine how in the hell was done and the insane skill levels involved in doing it. I will point out one thing that was common among the really good 3D practitioners: most of them are really good musicians in addition to being outstanding fine artists. The character animators generally had a drama background.
Now, I just mostly play around, doing the occasional explainer video/animation pieces and elements, usually having to do with automotive and aviation technologies. My old-ass brain can't keep up any more.
I remember thinking at the time that, had I had no prior experience to build on, I probably would have given up on it.