I think that greatly depends on Blender further acquiescing to some industry expectations:

- having a stable plugin API that is not Python based is a must for many studios that are working with large computations. A stable C or C++ API is a must for them, versus having to patch and recompile the entire application from source.

- Allowing the plugin API itself to not be beholden to GPL. This stops a lot of commercial plugin developers from supporting Blender.

- Better large scene performance. Right now blender absolutely chugs compared to commercial apps when your scenes get larger

- better undo performance because it's effectively saving a copy of the whole file again per undo.

- potentially more ingrained support for Pixar's USD toolset including a Hydra stage view. Which would open up access to a lot of commercial renderers, but also offload large scene handling to the Pixar stack instead.

The leadership have been resistant to a lot of these over the years. But they seem to be coming about to the value of playing well with existing toolsets rather than being the do-it-all that doesn't fit in well.

I am hopeful with their current trajectory after the revamp of the 2.8x series that it'll see further advancements in the areas I mentioned.

> - Allowing the plugin API itself to not be beholden to GPL. This stops a lot of commercial plugin developers from supporting Blender.

Chaosgroup solved that problem by using the process boundary. They have an integration plugin in GPL and then execute a standalone version of their renderer that they offer separately.

Which works fine for a renderer where you're typically serializing the scene and transferring it over anyway.

It's not as tenable for things like deformers etc that need to feed data back in to the scene every frame. Well.. at least not without severe performance repercussions.

As long as it can be streamed or batched you can get pretty much the same throughput with IPC. Only latency suffers slightly (microseconds, still within a frame budget even for realtime use), but you only pay that latency overhead once per batched action.

How does jackd manage multi-process realtime audio (or e.g. ReWire on Windows)? Maybe there's a way for Blender to do the same thing, at least on UNIXy platforms.

It gets some criticism for it, but, in my opinion, it has one of the most innovative/powerful UX of any software I've used.

Some highlights:

- Any panel can be positioned/sized however you like

- You can create custom named layouts for your own common workflows

- Fully extensible via Python plugins (create new UI panels, menu items, hotkeys, etc.)

- Anything you can do manually can be scripted with python

- By default, (although this has changed some) the more-frequently-used hotkeys are single-key. And of course it's all configurable and (if I remember correctly) they have presets for matching other apps like 3ds max / maya.

- searchable commands palette (press [space], start typing command name, press [enter] to execute command)

- on load / "new file": it loads [something like] "default.blend" instead of a hard-coded set of defaults, so that you can configure its definition of an empty file (which IIRC also includes the default layout configuration). To make it quick+easy to change, you can set with menu option [File]+[Save Startup File].

- Windows can be broken out and dragged to a separate monitor

- Lots of highly-specialized UI widgets. e.g. inline ranged slider that captures the mouse on click and adjusts the value as you move the cursor, has a "progress bar" to visualize the percentage, allows keyboard entry if you single-click instead of click+drag, has arrows on left and right that can be clicked to step forward/backward, has label inline with widget, and has description on mouseover

- Generalized interactive timeline for animation and sequencing

- Powerful node-based editors for shaders, textures, etc., with nodes for each stage of the pipeline and utility nodes to apply transformations (e.g. add a node for a source image, draw a line from the image's color output to the input of a "brightness" node, etc.)

And not only can you use it for the obvious 3D tasks, but it can be used as a non-linear video editor (including things like cross-fade of audio and/or video, video superimposition, textual overlaying, cropping, stretching, mirroring, color manipulation, option to use 3D scene output as video input, etc.), shadeless 2D raster/vector animator, 3D printing, and probably other things I don't know about.

I prefer Cinema4D UI over Blender. It does all the things you listed and then some.

Blender UI is great, but Cinema4D UI is arguably better. I've used both for 10 years.

I think most engineers and designers forget that they're just tools. Vim or emacs? PyCharm. Whatever works for you. Stop letting tools define your craftsmanship. This comment reminds me of pixel peeping that most enthusiast photographers do...comparing MTF curves for days. How about going out and taking pictures, learning composition and narrative, story telling and photographic experimentation? But they're too enslaved to their tools.

I guess that too can be a hobby?

You may be right but keep in mind that there are a lot of talented people that cant afford paying for software such as Cinema4D and that's the beauty of Blender you have access to 3D software with good amount of possibilities without paying anything and the community is pretty huge and getting a momentum

Yep, I agree - Blender is a great tool and not wanting to take away anything from it.

But I found this horn-tooting about Blender and saying that its superior to every 3D software out there is a stretch if not flatout wrong.

Ever used Houdini? Yeah, it's not totally free but it's free for non-commercial use. It will blow your mind what it can do: https://www.youtube.com/watch?v=MIcUW9QFMLE

The Houdini UI is nothing short of absolute genius.

I don't see Blender ever competing with Houdini. Like...ever. Because, it is fundamentally a different take on 3D content. It does the same thing at the end (3D content), but the way it does it is different (procedural). Better IMHO, but I could be biased.

Does that mean Blender has no place in the sofware ecosystem? No. Can we me a bit more pragmatic, stop horn-tooting and objectively look at the 3D software landscape as a whole? Yes.

Houdini is nice peace of 3D software they are going for a lot of years now leading to 90s good that they added some affordable licensing for indie artists recent years but again for starter 3d artist Blender is best choice after that its up to the person what direction he/she will choose.

> Anything you can do manually can be scripted with python

Moreso - the tool tip for each button / text box lists the python code needed to call that function / edit that value - so it’s not just “anything that can be done manually can hypothetically be scripted”, but “if you can do it manually, then you just need to look at the tooltips and write them down into a text file, and you’ve just written a script to automate your workflow”

I agree, after I learned Blender using any other 2D or 3D software felt like a dinosaur after.

with the advent of so many open source libraries for physics, maths, geometry, rendering, whatever, blender seems to be the right sink to aggregate all of them.

I would like to port OpenFOAM over to Blender. It’s very powerful software but a mess of dependencies and rubbish documentation. An implementation within Blender would make life so much easier.

You have to make due with 32-bit floating point accuracy for any vertices defined in Blender for the geometry to be passed along to any external libraries. In a prior gig where Blender was the primary development environment, I needed to do all kinds of gymnastics (converting floating point numbers provided by the user in the gui to strings then to Python floats or sometimes 32-bit or 64-bit numpy objects, then to the external package and back) in order to maintain double precision accuracy. Anything created or stored as a Blender FloatProperty is a 32-bit value on the C-side. But if you operate on that FloatProperty object within the embedded Python process you are operating on the 64-bit representation of the 32-bit pattern, since Python floats are all 64-bit values.

I heard more than once during that gig that “Blender is not CAD” even though we were doing everything possible to bring it closer to being so.

But with vertex values, those are created directly in Blender’s C layer, so no possibility to make those values have 64-bit accuracy if that is important to your application or external library.

I am in agreement that Blender would make a fantastic environment to pull together many open source scientific and engineering libraries, but the vertex accuracy is the one major drawback there.

This seems to achieve the blockMesh functionality.

http://tkeskita.kapsi.fi/blender/SwiftBlock/docs/swift.html

This is very informative. I would think at the very least Blender would allow far more convenient means to construct a blockMeshDict when assembling simple geometries.