Geometry Nodes Backward Compatibility [Poll]

Archive Geometry Nodes
1

Hi,

The development team needs to make a decision regarding how we handle the backward compatibility of 2.93 files in Blender 3.0. It will help to know people’s expectations before a final decision is made.

The big change and manual conversion

As part of the initial Fields implementation, Geometry Nodes is avoiding hard-coded attribute names in the node-tree. That will change most of the existing nodes which will now leverage inputting and outputting attributes directly as fields.

To better benefit from the new system, artists may want to recreate their node-trees manually. That will bring the best readability to their files, and result in better shareable nodegroups.

Keep in mind that some nodes will no longer be accessible (most of the attribute nodes) and should be replaced by the equivalent function node. While other nodes are mostly updated (e.g., Point Distribute) and can still be used as before with some tweaks.

Note: List of nodes that need versioning.

Legacy node groups and hybrid node-trees

The old geometry nodes node groups will be readable by Blender without loss, so the files can be rendered just as before. Values exposed to the modifier can also be tweaked.

However the legacy nodes will no longer be in the Add menu, and the node-tree containing them will have a warning showing in the UI, urging users to update their files.

The old nodes will be gone in Blender 4.0.

Locked legacy node groups

A more radical approach would be to make the node-trees that have legacy nodes read-only. In that case if you want to edit those pre-3.0 node group you won’t be able to. Instead you need to create the new node-tree with the fields nodes. To see the node group nodes the users may have to open the file in an older Blender version or use the Python API to access them.

Smart conversion

There are some ideas as to how to convert the files in a smart way. A simple algorithm can be designed to cover most of the use cases. Roughly:

  1. Ungroup all the node groups.
  2. Add all the “user” inputs used by nodes to Group Input.
  3. Add all the outputs generated by nodes to Group Output.
  4. Add all the required “get built-in attribute nodes”.
  5. Add all the required “set built-in attribute nodes”.
  6. Index the attributes, create a lookup table, walk the tree making connections.

The resulting tree will look ugly. But at least will preserve the old functionality while using the new nodes.

This conversion is not one of the initial targets for the core development team. Instead we would like to see if the community can address that. This can be available in the Help menu or near the old legacy modifiers for a quick conversion.

If there is a good script to do the conversion we can get rid of the old nodes before 4.0 even.

Poll

Asking around the Sprite Fright team, it seems that the production files will be manually converted anyways. It should take around 2-4 days to convert all the files there. I wonder how representative this is of the wider audience. If you can help answering that, pick the options that better fit your point of view:

  • I don’t care either way - I’m using 2.93 LTS for existing projects and will use 3.0 for new ones with new nodes.
  • I don’t mind manually converting my files since they are simple and/or I want to learn the new system anyways.
  • I will manually convert my files anyways to leverage the new system and get readability.
  • Please convert things automatically since it would take me a lot of time to convert all my files (e.g., more than 4 hours for a single nodegroup).

0 voters

Thanks for your time,
Dalai

15 Likes
2
3

3.0 was knew will break up things. Simply do not waste invaluable and undetermined development time on this.

Whom want their nodes in 3.0,done them from scratch on 3.0.

33 Likes
4

How can there be 37 Voters and 46 Votes?

5

Simply do not waste invaluable and undetermined development time on this.

Agreed,
Wasting development resources on this, while old files will not break anyway until 4.0, would be a waste of energy.

I think it’s more important to redirect resources on making sure that fields are polished and ready to stick in time (for good), and that there’s no regression in terms of possibilities compared to current build
I’m more afraid of features regression, the time is short perhaps some nodes will not be ready in time :zipper_mouth_face:

Locked legacy node groups

How about simply make their interface greyed out or red or perhaps a little label on top/below?
locking them might be quite an abrupt change
just signaling gently to the users that the node are legacy is enough imho

24 Likes
6

A translation algorithm that converts old nodes in to new ones is obviously the best solution if looking only from the point of the user but I have to say that this seems like a quite time consuming thing to create.

I think that “marked for removal” legacy nodes nodes is the best way to go about it. If this is shown to be a significant issue by the time 4.0 comes out, then the translation algorithm can always be added retroactively. (or even implemented as an addon)

2 Likes
7

Legacy node groups and hybrid node-trees would be amazing and easy to debug while doing manual conversion.
Locked legacy node groups are good enough.
Smart conversion is just a waste of time. And even if it works flawlessly some people will still complain about readability. :wink:

Most important thing imho is clear communication on the UI side, that those nodes are legacy and will be not recognized by 4.0.

7 Likes
8

I’m almost sure that few users will do a conversion script with python as soon as it’s out anyway

5 Likes
9

However the legacy nodes will no longer be in the Add menu,

This does not work as well as you’d think, I’ve done something similar once in my dayjob and users

  1. Complained they couldn’t make a small modification, “it just needs this one extra thing!” leading to increased support costs
  2. The smart ones started copy/pasting existing items bypassing the restriction

you may as well just stick them in a clearly marked LEGACY submenu and save all parties involved a whole bunch of frustration.

12 Likes
10

I noticed that more than one option can be selected in the survey, maybe that’s why more votes appear than compared to the number of voters haha.

3 Likes
11

I had made a forest in NPR style with geometry nodes of version 3.0 alpha and so last week I did the test of doing all the conversion to the version of “fields prototype” which took me 3 days more or less (+ 2 days learning to use the new node system in the process without having watched tutorials).
Obviously I did the conversion little by little and without haste, but because I did not put anything to sell with geometry nodes. I like the new node system with fields, it is a bit more intuitive to use and it is easier to learn. Personally, I prefer that you guys focus on further developing and improving the nodes from the prototype. Keep up the great work you guys are doing.

5 Likes
12

Agree, leave the compatible nodes untouched and the incompatible nodes greyed out, so we can just go, replace them for the correct nodes or procedure and that’s it, but we have access to our tree :slight_smile:

2 Likes
13

I think something like this should be done and there should be a focus on “branding” the difference between the old system and the new system, almost like the texture node editor (deprecated?) vs. the shader editor. The old geometry nodes are really just more readable advanced particle systems with a focus on populating scenes. The new system is much closer to what I envisioned geometry nodes would be: nodes that procedurally generate new geometry and parallelize modifiers. It’s a shame that “Particle Nodes” is already associated with a different module. I could see the old geometry nodes merging with the particle workflow and limiting the scope of the new (fields) nodes to generative modeling.

14

Honestly, putting them into legacy menu where they are even more easily available than copy/pasting will make people use them even more. And after that, they will be even harder to get rid of and deprecate.

From what I’ve seen, most of them can be replaced by node groups build with the Fields system, so I think that’d be best solution to replace them with. At the same time, automatic conversion seems to be the least wanted option in the poll, as many people would want to see Fields solution develop more rapidly, so it’s probably not worth it.

The locked approach seems like the best way to go here. Old things will continue to work but can not be modified. I don’t think it will do that much damage since GN in 2.93 and earlier are so limited that not that many people are relying on them yet.

I am also a bit confused about “increased support costs”. The dev team is pretty ruthless in terms of rejecting anything on developer.blender.org which doesn’t fall into an extremely narrow BF definition of what a bug is, and immediately closes such requests, so I am curious how this would result into increased support costs…?

15

The reference was to our costs at the office, how the BF manages this is up to them.

16

Please, focus on making the new Geometry Nodes good and well for 3.0.

Thank you all developers.

4 Likes
17

Another idea on how to handle the conversion:

If the nodes “Attribute Extract”, “Store Persistent Attribute” and “Attribute Remove” from the fields prototype are kept in the final version too, then I think every other legacy node could be modeled easily from these nodes and the normal fields nodes in a node group. Then every legacy node could be replaced by a generated node group emulating that node. That way many old nodes can be removed from the code while keeping old setups intact. Not sure if that is a big advantage internally. From a users point of view this is probably slightly worse than the “Legacy node groups and hybrid node-trees” solution.

18

Honestly I would just pretend pre-3.0 geo nodes didn’t exist. It’s a burden on a team to have to carry over so much legacy for a project not even a year old.

Fields proposal is clearly superior and has the potential to be used by more people. For older stuff 2.93 will be supported for multiple years anyway.

18 Likes
19

A simple popup on file opening of there are non compatibles nodes?

Maybe a link to link to the build the file was saved on.

I know many people of develop software on old software because there are afraid of breaking things.

Maybe later a conversion mode can be implemented after the new system is fully featured.

1 Like
20

I think one of the coolest things that Blender does that other tools somewhat struggle with is compatibility between versions.
If there was some versioning code or python script that tried to automatically convert the setups somewhat, that would be pretty valuable imo. For example the production files from Sprite Fright are all made with the old system - it would be kinda bad if those will only work with an at some point in the future ancient version of Blender.

IMO it’d be fine to get rid of the old system without any traces if it was an experimental feature or only accessible in an experimental branch, but old Geo nodes is an official, standard thing.
The feasibility of converting the old trees into new ones prolly depends on what kind of nodes will be available in the 3.0 series, so maybe it makes sense to develop migration solutions then?

Are there some things that can’t be removed or rewritten because the old nodes rely on them?