Tutorial about writing a custom geometry node for Blender

I wonder if there is a good design, in order to bring more third-party nodes into the system like this, but in a more flexible manner.

As for example the Pizza node is quite awesome to be shared here and there, however a hardcoded implementation into the core architectural domain of Blender, is bit more tricky and complex. As for example adding too many custom nodes eventually can lead to lots of maintainance where you would have to patch and update everything within each new Blender release.

Is feasible in terms of architectural implementation to strike a good balance between keeping the core architecture clean of your own modifications and then any additional third-party nodes added on top of the rest as treated as extension features rather than core features.

With this mindset, say for example you have only a master node, that can only load compiled DLLs from the filesystem and then export vertices/indices and any other sort of such data.

The DLL can only return a data structure like: int* verts; int numverts; int* indices; numindices and the implementation is sandboxed (pure implementation without external dependencies).

So no more no less with this mindset you can introduce only one node into the core architecture and then have a number of other nodes provided externally.

To see where I am going with this, have a peek on github about After Effects plugins, and you can see that you can bring any custom pixel effect into the system on the fly. This is something I am thinking about doing with Blender and let at least the core be rock solid and stable, but any other experimental or use-throw usecase be treated as an extension.

I am very interested to try these ideas. But still I am not sure about the best approach, I will have look at it in more detail first and then say where to draw the lines. :slight_smile:

Dynamically loaded libraries are currently considered an anti feature: Reference/AntiFeatures - Blender Developer Wiki. There are multiple reasons for it - both ideological and practical. This has been addressed over and over again so I won’t go into detail, but basically I would say this is very unlikely to happen.

I have talked about this subject a few times so far, as far as I remember what is being said about it is that mostly about, preventing Blender from becoming a “black box” of third party functionality.

However the counter-argument here, is that there is already a wealth of high-quality Blender addons written in Python, and sold for a good price. Some can reach up to 100$ and such.

In this mindset, I see that if the addon is written in Python or C++ for me as a user is not so much of a problem, as long as it works. Also as I a developer again I see no limitations.

As of now, I have for example seen a dozen of Python addons that call C++ code with ctypes and they can play nicely. The choice is usually:

  • speed (heavy algorithms offloaded to c++ for great speed)
  • source-theft-prevention (some are very afraid to give the good chunks in readable and clean Python)

Eventually, the meaning currently is any user can use Blender as it is out-of-the-box, but for those who seek more advanced and niche workflows will have to rely on commercial addons if they find them useful.

So for example I see that is not the point of looking at it from an ideological mindset, such as having free software or freedom of use but rather to take a more pragmatic approach and consider that interoperability at the native level is crucial.

Though I don’t expect anything to happen in this direction, but is good to put things on the table and see where things go in terms of use cases.