Personally, I think it, anyway, it is just the beginning, there is no important commercial project, must need to convert, this development of huge change is really inconvenient, but the early version does not give up how to sublimation
In practice these massive changes should be exception such that it seldom happens, otherwise it will make the users to be shying away from fundamentally new features. Please bear in mind that people might be using GN in serious commercial projects as of now and saying that they should keep using 2.93 if they like the old way is not necessarily a good way to treat this issue.
Blender files have been forward compatible with minimal breakages. And I think this is one of the those features of Blender that separates if from others.
I personally like how the legacy and the new cryptomatte nodes are handled in the compositor.
I think what people are suggesting is not that they keep using 2.93 because they like the old way. Hardly anyone will. The suggestion is simply to use 2.93 only until those people finish the projects started with 2.93 GN and use 3.0 onward for fresh new projects, not for them to use 2.93 forever.
I think the amount of people who meet following criteria:
- Have ongoing commercial project started with 2.93.
- Utilize 2.93 GN to such a degree the project relies on it.
- The project will be ongoing for a very long duration, and won’t be finished for a substantial amount of time even after 3.0 official release.
- The GN setups in it are so complex converting them manually to 3.0 GN system would take a long time.
- The new 3.0 features are so important for them they need to switch to it mid-project.
…is so small that this really would not affect many.
While I don’t disagree that it would be better for the old files to not break, I don’t know many people who rely in 2.93 GN and earlier for serious commercial projects, and even those who do seem to be fine with the compatibility break if it means faster 3.0 new GN system development.
(Editing this post instead of polluting the thread with a new one):
I’d also be happy if 3.0 was released a lot later than the regular Blender release cycle, if it means that GN in 3.0 are going to be very stable, feature rich and have as few known limitations as possible. Given how large of a feature this is and how much it will change how content is created in Blender, I am fine with it taking as much time as is necessary to iron out the design, instead of adhering to a regular release cycle.
5 Likes
For anyone wondering about the conversion script, this is a rough illustration of the “algorithm” I mentioned (click on the image to see it larger):
As you can see this is not using Get/Set Attribute nodes.
I’m well aware that a simpler conversion could be done using them (a much simpler in fact). But the resulting tree wouldn’t be levering Fields anyways. It would simply replace every single node with an equivalent node group.
8 Likes
I somehow am a bit confused to make connections between the poll options and the two compatibility designs. So the first three are basically “Manual”, and the last one is “Auto”, so is the manual conversion the " It would simply replace every single node with an equivalent node group"? Then Auto would be this “No Hardcoded doversion”? (Also confused about whether doversion is a word)
Then the locked one, what does it mean by locked? You mean locked parameters, or node groups that cannot be opened to see the field nodes inside?
The no hardcoded one feels like it’s going to make a very complicated node tree in more complex files, so I actually prefer the node groups that would just look mosty the same as before. As for locking the node group to prevent opening… Not sure what’s the benefit, the nodes inside are just field nodes, I think it could be even educational for how to recreate old behavior with field nodes. It also sound like additional work for devs because AFAIK currently there is like no way to lock the node group. I am not sure about that.
But again, I don’t know how my opinion can be translated to the poll options so I am not voting.
1 Like
Personally I’ve been considering GN in 2.9 some kind of beta-version for all this time, so I haven’t got much into it, waiting for the official 3.0 standardized, optimized, stable, non-experimental, widely-spreaded release which I could use in my production pipeline without any worries. So for me the most important thing is to have a really good stable release version of GN in 3.0.
7 Likes
I think they should work up till 3.0 and be accessible under a legacy menu. I don’t think we need to have a converter right now(need to have one before 4.0) so we could focus more time on development of new features.
Agreed, if I ever need to go back to the one project I did that used GN, I’ll handle the modifications myself. Better not have such a burden
3 Likes
@dfelinto
I think Blender 3.0 should be something really new.
So, I personally don’t mind if you break some forward/backward compatibility anyway. Besides, You have already done that by introducing the new compression algorithm for saving compressed blender files. So hell why stop halfway? 
kill it with fire without problems
1 Like
I haven’t done much with nodes yet either. But, it seems like a bug farm/gonna be a time sink for devs to try to patch/convert stuff.
Which still may end up having issues/require more fixes by devs or user.
Unless its PRETTY EASY to add some conversion code path, I’d say screw it, user can port themselves.
So they know how the new system works/understands it and makes sure works how they want. Instead of trying to debug converted stuff/maybe aren’t sure why is broken now/etc.
But I know some people have opposite opinions/maybe very passionate about auto convert.
I think if the new geometry nodes is easier to use, more robust, and is actively being developed by the blender foundation, people will naturally want to switch over. Unless there’s something that the old geometry nodes system does better, I imagine people will have fewer reasons to use it generally.
This thread is more about how to make old files working in new system (manual convert to new node groups made out of field nodes, or auto convert to no hardcoded node tree), the old nodes would not be kept around either ways so I think we are fine regarding that.
The hardcoded store attribute node and extract attribute node though, I might be wrong but it sounds like they would be removed if we choose the auto convert option, which would also cost the devs more time and labor I think. Like a downside on both user and devs. So I think I like the manual node group more. Each node turn into a node group and done. Don’t know how hard it is, but it shouldn’t be that hard, I even made 3 node groups myself the other day:
(If it’s actually hard to do then I am sorry)
Bingo. Development resources should be better directed towards other improvements. If it turns out to be a very drastic change that impacts people enough, someone is going to come up with a solution for everyone. No need to waste precious resources on backwards compatibility when someone else can do the work for you.
1 Like
By the way! Another suggestion about forward/backward compatibility.
- forget about compatibility
- New geometry nodes system (fields)
- incompatible blend file compression
- new Cycles X
- new versioning system (since 2.93)
Meet Blender X !!!
Given that we finally got somewhat reasonable versioning scheme (3.0 to 3.3, then 4.0 to 4.3, etc…) this is about the worst time to mess it up again and rename the release to something as ambiguous as Blender X 
Blender is groundbreaking.
Redoing your stuff in newer technology is always good practice.
Next to that all the older versions remain available to open/use the files made with it.
If the need is there people will write up scripts or addons to convert i’m sure.
Cheers to all devs!
2 Likes
My 2 cents: Just don’t wast time on porting the old nodes to the new system. The Idea of leaving legacy nodes readable from older files and not include them in the add menu is just enough for me to have a minimum backwards compatibility, as long as it doesn’t require any significant extra developers time.
8 Likes
since the devs were already noble and daring enough to (somewhat) start over, I would say that you could neglect backwards compatibility. I suppose existing node trees from 2.9x will look like child’s play anyway compared to what future incarnations of geo nodes will allow the users to come up with. Looking forward to what’s coming up!
bedankt
2 Likes
I think, based on my understanding of the versioning, LTS philosophy and (okay I don’t have a lot of experience/wisdom on this but still) production level utilization of Blender, it seems that the whole idea of Blender moving from 2.xx to 3.xx is that there would be significant breaking possibility.
This may seem like a backwards way to handle it, but what if Blender 3.0 and maybe even 3.1 was much more focused on developing ideal features within Geometry Nodes and full/seamless backwards compatibility solutions (like automatic conversion) were saved for the next LTS: 3.3. Given the idea is that, for full compatibility aimed at production level projects, the LTS versions are what Blender specifically markets to those users.
So if a user wants the most cutting edge features, they go for each release. If a user wants production implementation and stability they go for LTS.
3 Likes