That is just because the prototype is not a complete implementation. In general you should very rarely feel the need to give attributes explicit names in the proposal. The Attribute ... nodes (e.g. Attribute Transfer) that are in master and in this prototype just have not been ported to the new system yet.
Same reason as above, we just did not port everything to the new system yet, this is just a prototype currently.
Yes, we do want easier to use nodes for common randomization tasks. For now you could just create a node group instead of copying all nodes all the time.
I noticed that custom tooltips do not work in node groups with this patch.
The properties panel looks like this inside the group:
This is what the node looks like:
I am still kind of confused though. Why did we have to first do it the wrong way, then backtrack and then do it the right way? I mean it was obvious from the start this is how GN should work. I am puzzled why the original attribute system not only got approved, but even made it into master and was called production ready.
Itâd make more sense to have these design tests earlier, and have features in beta longer, so there are no more debacles like this one, where significant portion of whatâs already been called production ready will most likely be deprecated, removed and break backwards compatibility.
Because it seemed the right way at the beginning, and it might look different from coders perspective. While it might be obvious for a user that we need to see what we are doing to keep track, for coders it might be more like do math in your head and then just fill attributes it saves some nodes and gives flexibility. It might be like with chess - if you playing long enough at some point need for visual representation of figures may seem redundant because you just see all the figures in your mind so you donât need to see it with your eyes, but most people do (at least this is my guess). Also because coders probably were looking for a solution even better than what we have already in blender, itâs just sometimes âbetterâ is the enemy of âthe good oneâ. I canât remember precise, but there was some Murphyâs law saying that if you upgrade something long enough, thereâs a big chance that you will end up breaking it. Good thing is that we didnât stick with this state for good, but yea it will cost some time and effort to get used to new system, but itâs better to have it usable than fighting with attributes in long term. And yea we can complain that we didnât have system right way since February, or we can do our best to help develop system the way it should be, I think devs really got the feedback already and for now I donât see the point in looking back we are all human beings after all, and every one makes mistakes. Iâll also have to make my group nodes from starch (before I tested fields I was skeptic to the whole idea of turning workflow upside down), but Iâd rather focus on just remaking it than wondering what could be done but wasnât (it ainât productive at all, and helps no one).
Thatâs a bit False tho
There was many complaint about the attribute system right from the start.
In fact, my first ever feedback was about this, i recall how weird it was to not being able to âseparate the attrâ and other users had the same feelings back in the days
I think that the new developement pace is a bit to blame
everything must be done fast and new masterbuild every 3 months ect⌠that do not leaves a lot of time to think deeply about some isssues perhaps
When you see the system for first time itâs natural that everything itâs new, first opinions are not always true as well. I agree that GN shouldnât make to 2.92 and 2.93 official, but it did and unless you have time vehicle you can complain about for years and it changes nothing.
Well if you sacrifice long time of your life to develop something itâs natural you hope that people will get used to it if they give it some time. They were just wrong, itâs already been said many times.
I think that devs at this point really have no doubts that it might be done better from the beginning, and now theyâre doing everything they can to fix it. There is no need to make witch-hunt itâs what I mean.
I am having extremely hard time imagining this seemed like the right way to anyone who knew what they are doing. Itâs really frustrating to read these kinds of nebulous posts saying like âItâs always this way, there is this and that law, itâs subjective, we are just humans, etcâŚâ
No, itâs not. There are many existing examples of not only software packages who have gotten features right on the first try, but also those that have been doing it consistently for years, sometimes even decades.
This is a prime example of design by someone with no practical end user experience combined with no review by someone with one. Someone was allowed to bring such design completely under the radar all the way to the final, non experimental Blender builds.
A great example of a system similar to GN developed by someone who as also experience as an end user is TyFlow, a 3ds Max plugin. It had vast majority of things and workflow gotten right already at the release, and people were able to utilize it in production for even very complex things already in the very first version. All that it took was someone who knew what features and what kind workflow are necessary minimum for it to be truly usable.
I am in no way implying that a developer also has to have any substantial experience as an user. But if that is not the case, then it necessitates that a feature design produced by such developer is sanity checked already during the development, not after itâs been included in production version and called production ready.
As BD3D says⌠this has been obvious from the start. What went wrong is that despite many complaints, whoever was in charge of GN simply plugged their ears with their fingers and went âNANANANAâ as loud as they could. And this is why now we have to back track.
Bottom line is that there is absolutely nothing that would prevent us from having the Fields proposal as the first, initial GN implementation. And had that been the case, we would most likely have many more happy and productive GN users than we have right now.
Open source or paid ones? They are not some huge corporation.
Repeating same song again and again makes it really tempting to plug my ears and go nanana right now. This was said many times before, now itâs better late than ever. The thing you are doing now seems more like kicking a lying man on the ground than constructive critics. What do you want to devs do? Shame walk or sth?
How does that have to do anything with the development process? Size of the dev team nor source being open or closed has any impact on development method. Itâs a choice.
I think my critique was constructive enough. I directly suggested that if the features are designed by someone without practical end user experience, then that should be compensated for by letting users be involved sooner than when the feature is added into an official non beta Blender build with a âProduction readyâ sticker on it.
If GN were released in experimental branch, same as Cycles X, we would not have to read there will now have to be substantial amount of development spent on backwards compatibility, and only after that, progress on making the Fields system better:
Well it have to do with a lot, open source development itâs different, on many levels, starting with less salary, less man power, and more searching for compromises and workarounds. They canât afford to just buy top coders on the market to make miracle work in a month, they have to be careful to keep the blender going, there are no guaranties that they will have the same budget next year as they have now and there are many areas to maintain and develop not just GN. Maybe attributes just seemed better, faster to implement, easier to code on time, more flexible, I donât know, Iâm not a coder, but I just donât assume that it was an obvious piece of cake to create from scratch a complicated node system. At 2.92 release people got really horny for GN so they released it, and yep it shouldnât happen but if they wouldnât release it there would be also a backlash that they are doing nothing, and GN is in alpha forever feature, so they probably bent under pressure.
With the rest, I can pretty much agree, those are legitimate points. Everything is more clear and constructive when we speak more respectfully, focusing on what could be better for the future rather than digging up what canât be changed already.
I think it depends on how they decide to achieve the backward compatibility . I discussed with my friends how it is possible to make it backward compatible when we already removed a bunch of Attribute nodes in the prototype. The result of our discussion was that one possibility is to keep the old nodes working but not include them in the Shift A menu. If they decided to do that, I donât think it would cost that large amount of time. But if they decide to convert old attribute nodes to the new function flow nodes somehow, it might be a bit tricky.
