Allocating IDs for Geo Nodes in BKE_node.h

Geometry Nodes
#1

Hi folks,

What is the process for being assigned an ID for a new Geometry Node? The ones of the form:

#define GEO_NODE_EXTRUDE_MESH 1152

There must be some type of coordination, as it is my understanding that these get written into the .blend file. If there were no coordination, then that would mean that hacking Blender to meet one’s needs would not be possible, as sooner or later, another Geo Node would appear in the source and clobber any number used locally.

These IDs are clearly not precious, but the way that they are nice, neat, and contiguous in BKE_node.h kind of frightens me, implying that control over these IDs is quite tight, again implying that I’m not allowed to make my own Geo Node without cutting myself off from using all future .blend files and corrupting past ones. But I can’t believe that no one has wanted to create a new node before and raised the issue of where to get a new ID from…

Is there some sort of liberal process, like ICANN for being assigned a well-known port number?

Thanks!

#2

If your goal is to maintain your own version of Blender with your own nodes, I would recommend just using some large number that is unlikely to be taken by new nodes. It just has to fit into an int16.

If you’re aiming to contribute these to master, it doesn’t really matter which number you choose during development, it will be set chronologically when committed.

#3

Thank you for responding, Mr. Goudey.

I would, of course, prefer to be a good open source citizen and I believe it (a livelink between Blender and Daz Studio) will be a good candidate for master, being of interest to a large number of users, and its wire protocol is general enough to be useful for other content creation apps with a suitable SDK, e.g. Houdini, Maya, UE.

But my concern is that my changes might be rejected for non-technical reasons. In that case, I would still feel best with a zero probability of collisions, as opposed to near-zero :slight_smile: I strongly desire some coordination from the Blender dev community, and this sort of coordination by the responsible party is not unheard-of in the history of computing, as I alluded to in my first post. And I feel that not coordinating in some way would run contrary to the spirit of the GPL, which assures users that they can use the software for any purpose, if it also punished such users with uncertainty over future compatibility.

In the case of ICANN, it was literally sending an email, explaining what you’re doing, and the response was “Sure… take port 22…”. It could be as simple as that. 64K IDs are sure to last longer than Blender 3.x

Is this something that I could bring up at an upcoming open Geometry Nodes meeting?

Thanks!

#4

I don’t fully understand what you mean. But giving geometry nodes the right to download and save something to disk every update is a bad idea, and so far all proposals for such nodes have been dropped.

Just a little clarity, these IDs are needed for the fast operation of the program, yes, they must be correct. But saves use node type names, something like NodeGeometryMeshInputFaceArea.

Now the ID is less than 200, this is 2 years. So an offset of 1000 is probably enough for you for a decade. And the persistence would simply have to provide for the individual type name.

#5

While I don’t care much for the style of ‘veiled threats’ implied by the sentence ‘contrary to the spirit of GPL’ (Sorry if you don’t mean it that way @ddade) you do have a point.

I think it would be nice to add a

/* For custom versions of blender with added nodes, start numbering ids from here */
#define CUSTOM_NODE_ID_OFFSET 20000

In the header defining the IDs. And maybe also make it available from python, since I think you can add nodes with python? For that second case there maybe even needs to be a different system where the custom nodes are stored by name or add-ons wanting to define nodes get in trouble. Or is there already a system in place for python nodes?

#6

Talked about this with Hans before. Mid-term it would be nice to get rid of these integer identifiers. They mostly exist for legacy reasons nowadays. The node idname is already the ground truth.

1 Like
#7

Oh… am I incorrect in thinking that it is the IDs that are persisted in the .blend file? Is this a non-issue, then?

#8

Thank you for chiming in, Mr. Lucke. Can you instruct me on what would be a first action item for me to adopt, if I wanted to champion this cause?

In any case, are you saying that this might get resolved anyway, so my concern about future compatibility is not as urgent as it may seem? I do have my hands full with just learning how to implement the Geometry Node itself…

Thank you!

#9

I would not begin my interaction with a group full of individuals that I respect and admire, and even wish to join their ranks as a bonafide Blender contributor, with a threat. Veiled or otherwise.

I only referenced the GPL as justification to strengthen my point: Any barrier to a user’s ability to use the software, for any purpose he desires, is in fact contrary to the GPL. Richard M. Stallman even codified the concept explicitly in the GPLv3, which recognizes that there is no point in making the software free and open, if the hardware it runs on is not free and open. I know that Blender uses v2, but there’s an analogy to be made: what is the point of the software being free and open to modify as you see fit if that potentially cuts you off from the rest of the software’s user community?

I’ll get down from my soapbox now, I just wanted to clarify that no, I have more respect for you guys than that… I only wanted to present a convincing argument.

Thanks for your reply, in the first place.

1 Like