This is nowhere near releaseability, but maybe someone could find it interesting. Blender has (as you may know) a rather extensive Python API, and I always wanted to leverage Blender’s capabilities for 3d plotting. At the same time I try to avoid 3d plots at all costs for publication, but now I finally need them, so I can’t put it off anymore
Already a couple of years ago, I put together Blender.jl that was able to render the standard cube and load some premade meshes. I have now updated it to use the latest and greatest packages in geometry and colours, and simultaneously added some initial support for materials using the node system (all of this is of course already available through the Python API, I just made it slightly more convenient to work with).
Here are some examples:
To get it running, you need an installation of Blender-as-a-Python module, which can be slightly tricky to get going. I’ve just updated my AUR package to Blender 2.93.1 (I don’t know why the AUR page still says 2.80…).
Could this be built using BinaryBuilder instead? It would be awesome if one could just say ] add Blender and it would install the Blender Python module automatically.
This reminds me that I’ve read somewhere (likely on Twitter) someone tried Julia as a Blender liquid(?) simulation backend and got a substantial speed-up more than a year ago or so.
Memory (I remember @paulmelis is the one always experimenting with cool visualisation tools!) + twitter search skills (JuliaLang blender from:@username)
It’s not exactly just a Python module… you basically have to recompile the entire Blender package, which then gets exposed as a Python module. It’s around 4k C++ files. The problem is that it’s kind of finicky to compile, and then the Python module is installed in the system-wide Python library, instead of the one that the user has set, which may be a local Conda installation.
I just admire that you all can use Blender at all. I’ve tried and failed several times to learn it. It definitely doesn’t suffer from an overly minimalist UI.
The UI indeed seems to be the major stumbling block for new users, as it is so different from other packages. But the perception of that threshold is probably higher than it really is. We normally (non-COVID times) provide in-person courses where we teach researchers Blender in a day, with no prior experience required. Due to COVID we have turned that course (and its advanced followup) into online self-paced courses. The material is freely accessible, and can perhaps help you:
This post has quickly become my most liked one on Discourse, and Blender.jl has been the most starred of all my repos, totally eclipsing the work I’m actually payed to do . I assume this means people are interested in actually trying it out, but I have no idea how to move forward, making Blender.jl (easily) usable for anyone but Arch Linux users.
The problem is, as I see it, the following: Blender both embeds a Python interpreter and exposes itself as a Python module (when compiled as such). This means that a rather large library must be compiled, which must be linked against libpython, which raises questions about ABI compatibility etc, with the Python installation of choice of the PyCall.jl user.
The easiest route (for me) is to let the users compile Blender-as-py-module themselves and install into the system-wide Python distribution (as described here). Not very nice UX and will of course not work if PyCall.jl uses Conda to install Python and libraries.
Same as 1. but in the case of a Conda install, try to symlink the Blender Python modules into the Conda install. Seems brittle because of ABI incompatibilties, and paths (what happens when the Conda install is updated).
Some kind of build.jl magic that using PyCall.jl intelligently decides where the user’s Python installation is and compiles Blender accordingly. Also seems iffy, and the build stage will take a long time without any output => appears crashed.
Compile and upload Conda packages (such as the ones linked above, which is slightly outdated and does not provide packages for all platforms), but I don’t really wish to become a Python package maintainer as well…, not to mention that the ABI problem remains, so one would have to compile a package for each platform/Python version combination.
BinaryBuilder setup, sounds awesome on the surface (even though I know @giordano does not want to vendor Python packages), because at least we can compile for all platforms easily, but the problem of system-wide vs Conda installation of Python remains, along with the Python version issues.
I am a little bit out of ideas. Soliciting some input from @stevengj and @tkf as PyCall.jl gurus.
I’ve been wanting to make libpython configurable via Preferences.jl but I’m very lagging for handling a bunch of TODOs in my pipeline. But from a quick glance of this thread, if we have the Blender package distributed as a wheel in an artifact, it should be good? We can then just use python’s package manager to associate a Python environment to a Julia environment and install the wheel in it. I played with this idea a bit before https://github.com/tkf/PyVirtualenv.jl
I really like Makie as a concept in Julia and I hope it gets even better over time, but I have always preferred Blender whenever I made anything really fancy. If one day it becomes possible to access Blender through Julia and start using Blender’s internal geometry nodes concept etc. from Julia, it would be a really amazing day for me
button faster in my life!
. I assume this means people are interested in actually trying it out, but I have no idea how to move forward, making Blender.jl (easily) usable for anyone but Arch Linux users.