Native Code Node — Write Geometry Nodes Using a Native Programming Language, Such as C or C++

This add-on adds a “native code” node, which allows you to write Geometry Nodes using a native programming language, such as C or C++.

The node takes a “file” input, which you can navigate to your compiled code, and sockets will automatically be populated from the function arguments and return type. For this to work, your code must have been compiled with debug information enabled (/ZI flag).

A typical node looks like the following:

typedef struct {
  int32_t some_integer_output;
  geometry_t some_geometry_output;
  float some_float_output;
  int32_t more;
  int32_t outputs;
  int32_t here;
} node_graph_outputs_t;

node_graph_outputs_t main (alloc_t alloc, geometry_t some_geometry_parameter, int32_t some_integer_parameter, float some_float_parameter, int32_t more, int32_t parameters, int32_t here)
{
  node_graph_outputs_t outputs = { 0 };
  return outputs;
}

node_graph_outputs_t is a struct that you define. An output socket is created for each field. Supported field types are int32_t (paid version only), float (paid version only) and geometry_t.

The function must be called “main”. An input socket is created for each function parameter (besides the first one). The first parameter is a function pointer to Blender’s memory allocator, which is defined as follows:

typedef void *(alloc_t) (size_t len, char *str);

The second parameter is a user-defined debug name for the allocation.

Arrays in geometry_t are passed directly to Blender, so they must be allocated using this allocator. You may also use the allocator for other allocations. Geometry is defined as follows:

typedef struct {
  float3 *vertices;
  int32_t number_of_vertices;
  int2 *edges;
  int32_t number_of_edges;
  /* the index at `n` specifies the first face corner, and the index at `n+1`,
   * the last face corner for face `n` */
  int32_t *faces;
  int32_t number_of_faces;
  int32_t *corner_vertices;
  int32_t *corner_edges;
  int32_t number_of_face_corners;
} geometry_t;

Download the free version, with support for the “geometry” socket type.

There is a paid version available for $29.99, that adds support for the “float” and “integer” socket types.

Only Blender 4.1.0 and 4.2.0 are supported. Other versions are not supported, and will not work. Only Windows is supported. Linux and macOS are not supported, and will not work.

7 Likes

Example files are available for the free version here. Example files for the paid version are available here. The examples include .blend files, C source files, and compiled binaries.

1 Like

I wouldn’t advise anyone to use this seriously\

What makes you say that?

I second the question.

Even with check that blender is 4.2, even in that case, at some really unlikely point, using of this add-on will provoke your pc to kill your kitty even you have no kitty.

Ok. So you’re just trolling. Don’t do that.

Yup… all it needs is some change in the Blender C/C++ data structures and all hell breaks loose… :confused:

2 Likes

Following with interest…

And don’t get me wrong @aleksijuvani, I also do some ctype hacking with my blender… specially when I’m too lazy to do it in the source and compile it.

But comercially distribute such method is extremely dangerous, and can lead to bigger problems (memory leaks, security concerns, etc).

Only memory that you can read - memory what you allocated.
Any pointer in your program is valid only in case if its data (address of memory) being initialized by the someone why is you can trust.
C API does not provide any type safety, when you get a pointer to something, here is no metadata string (like json) which is you can read and ensure that your assumptions and knowledge are correct.
If you read pointer, you can do not get an exception due to access violations if memory segment is owned by application.
If multiple part of application is deal with the same memory, only the way to do not be wrong with interpreting the pointer data is to use the same types.
If you add Dynamic Linked Library part of the programm, everything rules about type safty keep rule.
The reason of that blender is build from DLL’l and everything is okay that blender is use other DLL’s and fallow its API. Any changes in used version of the external libs are related with updated in the code and builds.
In case if blender is DLL you have to follow its API.
In this case you HAVE to have DLL for each COMMIT HASH of blender.
Overwice jmp instruction in most of platforms, instruction which is a part of function call, will pass execution flow to not place where is you expect a function which is fallow to call-convention, no, your pc will start execution of the raw memory (90%, in comparison of probability to go on data segments of memory). No one. No one know that your pc will do. This can be just segmentation fall, or printing Hello World. Your pc can increase temperature of the motherboard and die, even more your pc can push all your browser history on internet.
No one known. This is well known as killing of your cat. Main part here is that your pc can kill your kitty even you have no kitty.

2 Likes

This add-on ships with multiple binaries, and one is picked at run-time based on the Blender version, which accounts for any changes in the Blender API. It will not attempt to run on an unsupported Blender version. New versions of Blender will require a new version of the add-on to be released, which is to be expected with this approach. Please let me know if you have any problems with using the add-on, and I’ll do my best to address them.

1 Like

Thanks for expanding on your answer, beyond just the metaphor of a dead cat.

1 Like

I’m assuming you’re patching Blender itself for this to work?

Well, usually it should be SIGSEGV, SIGBUS or something alike, resulting in the process being terminated by the operating system. There is still an operating system after all, that prevents user processes from doing that sort of harm you’re describing - if that happens, it’s probably due to intentional, malicious exploit of some OS weakness. Because … processes usually are not able to read memory that belongs to another process, the OS prevents that (yep, turns out that isn’t entirely true anymore since those really bad Intel processor bugs turned up a couple of years ago, but still, it isn’t that simple).

I’ve written plenty of C code in my past, including a JIT, dynamic in-memory code generation, hard to debug, lots of misguided pointers, memory issues and so on … but never ever did I see issues of that sort. The OS never got pulled down. Worst thing that happens is your binary crashing.

Talking Unix of course. No idea what all these Microsoft operating systems will do. I heard they are not DOS anymore either, though. :wink:

2 Likes

Blender version (even last one in sequence of 4.2.1) does not related with internal API.

Does this such for daly builds?

Yeah, this is reason why i added this part of the message:

Not entirely sure I understand what you’re trying to say.

If you develop stuff that’s not part of the OS, memory access will be restricted, and attempts to access memory that doesn’t belong to the application will lead to an exception (signal). So you are pretty safe in that regard, I don’t see how you’ll end up writing any other than such code in the context of Blender node programming (except you want to do harm, and also have the knowledge of how to achieve it).

Honestly, what you’re writing here sounds somewhat alarmist to me. It is not only entirely possible to write code in C/C++ that won’t tear down your system. It is entirely normal that C/C++ application development proceeds without any of this to happen. Of course you should know your ways around C/C++, but given you do, and given that add-on isn’t malicious by itself, using its API is no different, risk wise, compared to modifying Blender’s source code itself.

1 Like

And that’s the reason why my first reaction was: I just wouldn’t advise using it…

I don’t expect any blender addon to work with daily builds. If it does - nice bonus. Otherwise, the platform is a fluid alpha and no one should be expected to keep up with that externally.