I wonder, might there be a plan to unify all of those
(Seam Edges, Sharp Edges, Edge Creases, Vertex Group Weights, Vertex Colors, Shape Keys, Face Maps, Bevel Weights, UV Maps, …),
in a system that manages user attributes?
Sorry, It’s a bit messy, because I omitted the Gizmo drawing part, but the selection logic is pretty simple, just check if the position Z is between an upper and lower threshold, plus an offset.
Yeah That’s what I hope. I think It would be nice to just abstract vertex groups as point float attributes, vertex colors as face corner color attributes etc. As @BD3D said, maybe it would complicate a little bit things for beginners.
Anyway, that unwrapping is Cool! For a moment I thought that there was a node to unwrap a mesh, I can’t wait to have UV nodes as well!
Another selection node group, select inside bounds, and supports rotation, the gizmo display this time is just passed as geometry output to be joined outside the group (check the link to another post) :
I don’t really care about the gizmo implementation being robust right now, it’s just a hack to visualize what you are doing, I hope in future gizmo drawing will be a built-in function of nodes.
I really like this proposal. It seems like it will make the fields work much better. I really dig the benefit of more versatile node groups.
One thing you may not be considering: When has a new feature not been met with endless complaints from the community? When this noise is presented to the devs with every new feature or change, the only outcome is that the devs must necessarily ignore the noise in order to be able to complete a task. I think with GeoNodes being such a new direction for Blender, any initial design of such a massive undertaking would not be perfect.
I’m, as usual, impressed with the speed that the devs were able to pivot to an improved approach. Think of how much better this system is than when it was released only as a new 2.92 feature SIX MONTHS ago. It more than a decade for Autodesk to fix some of the issues with its node-based particle system.
That’s pretty rude. I guess you never used Jaques’ previous work Animation Nodes. He very obviously knows “what he’s doing.”
I didn’t really hate the attributes workflow. I really liked the fact that you could reuse data really far down the node tree without having to actually make a physical connection between the nodes. It was innovative.
The fact is that you can’t be innovative without failures along the way, but you wouldn’t know anything about that. Stings a little, no? My point is this: stop making the mistakes and unpopular decisions the programmers make into personal attacks on you and your workflow. They’re doing this out of passion and working hard to innovate on workflow and features. Fortunately for you, there is no one looking over your shoulder watching all of your mistakes made along the way to completing a project. Otherwise, you too would be subject to people publicly shaming you for not knowing what you’re doing.
That was my point. Jacques’ Fields proposal (which I very much love) was actually what set the GN development on the right track, but AFAIK the original system, from the user interface side of things was designed by Dalai, not Jacques.
If I am wrong, and Jacques was responsible for the design of the current GN design that’s in master, not Dalai, then I am sorry, and I take it back. But somehow I doubt Jacques would come up with a design like that, considering how great of a job he did on Animation Nodes.
And if I am right, then I struggle to understand why he wasn’t the one tasked to design GN from the front end side of things.
The original solution in 2.91 to 2.93 was designed behind the closed doors based on arguably subjective requirements of just Blender Animation Studio. Then, without any external sanity check, the workflow and UI was designed, and then, it was released into master branch and called production ready.
There was a failure at 4 individual points in time:
Design was based on a sample, test use case from Blender Animation Studio project. The example use case was not open to any external feedback which could avoid potential insufficiencies of the design.
Based on that, front end was designed to cover this limited use case, again closed off the any significant external feedback that impact the design significantly.
This design was then merged in master and included in official Blender build, not even as experimental feature, so some people already rely on it (with possibility of breaking changes in 3.0)
After the release, it was claimed to be production ready.
This isn’t matter of a mistake, but rather questionable process. The development could have gone smoother if it was caught at any of these 3 stages:
While designing the system, users would probably spot early on that the named string attribute exclusive workflow would be slow and limited for large amount of use cases.
If users had a chance to play with the working feature in beta phase with enough time before it’s in master, they’d be able to spot the same.
If it was in master, but had been explicity marked as experimental, instead of production ready, users could be vary to not rely on it much in production, and therefore backwards compatibility would not have to be such a strong consideration for 3.0
Even then, going so fast from nothing to a supposedly production ready feature included in master would not be such a big deal, if this feature was not as major as a whole new node based content creation paradigm, which is supposed to prepare Blender for next decade or two.
So I stand behind not being able to understand how anyone could think rushing a design of something as big and significant as this into master in production ready form was a good idea.
The reason I made all the assumptions I did, is that I have a hard time imagining that releasing the design that’s currently in the master as production ready, then having two different competing proposals, both of which mean breaking changes to already supposedly production ready design, then choosing one and making tough decisions about backwards compatibility was something the team has intended all along.
But at the same time, given your history of Animation Nodes and Particle Nodes design, I guess you already had something along the lines of Fields design in your mind back when you were working with the rest of the team on the original first GN iteration proposal.
Note that the combination of attributes nodes + previously planned attribute processor is similar to other applications (for example Houdini geometry nodes + VEX nodes). You might think fields are obviously better, and they are great especially for those familiar with shader nodes. But there are real trade-offs, other applications have made different choices with success. And with the addition of the attribute processor the usability would have improved, in a different way. So let’s not pretend that it’s obvious what the right choice is.
I never did, but I admit I made a mistake when formulating the post that started all this. Reading it back, it comes off as criticizing just the design alone. I should have been more clear that I criticized combination of rapid experimental design process with putting its result in the production ready official Blender releases so far.
I personally would have no problem with the text attribute based GN design evolving if it wasn’t presented as a final, production ready feature so fast. If we both agree that it’s not obvious what the right choice is, then wouldn’t it make more sense to keep the feature in the experimental state for at least a bit longer, until the design team figures at least what the “better” choice is?
The idea is that it’s not just the design team that figures out the right choice, but also the feedback from users using this in production. I can think of various examples where 3D apps released a complex feature like this, some early adopters use it in production immediately since it solves a real need, others wait for it to stabilize and become production ready for them.
How precisely this should be communicated can be debated, I personally would reserve the term “production ready” for when a feature has had a few releases to stabilize. But in the end I don’t think that makes a big difference or affects the development planning.
I completely understand that and have experienced that myself. I’ve used many new large features in their alpha/beta successfully in production. I was just aware of the risk of doing so, since they were not labeled as production ready.
And I also agree on reserving the term production ready for when a feature has had a few releases to stabilize is a good idea.
It’s just that from the outsiders perspective, seeing an iteration of GN with text based attribute workflow released as production ready, while also explicitly being claimed to be production ready on numerous places, sends a message of “this is the design direction we’re going with”, and then, proposals like Fields seem like something that “saved it in last minute”.
That may be completely wrong perspective of course. Perhaps this was the plan all along, but then it’d be odd to think that the original plan was indeed to significantly alter design of this production ready feature just half a year later.
When I read things like:
On top of the designs, there is work to be done for backward compatibility. This is all scheduled for Blender 3.0 and will be the focus of the Geometry Nodes module. That means the core developers and the community will prioritize this over adding new nodes/features.
After that, the focus will shift to expand the Fields design for future node systems.
I can’t help the feeling that had the GN remained experimental, it would be easier to focus on expanding new features of the winner Fields design instead of spending resources on mechanism for backwards compatibility of 2.93 and earlier GN scenes, and being constrained by it.
If I am wrong, I’d love to know. I guess my question is, since you said that you don’t think it makes a big difference or affects the development planning, you really wouldn’t say that if GN was still hidden under experimental features like asset browser, the dev team would be less constrained and had more freedom expanding the Fields version of GN, which would in turn get us to a truly production ready version faster?
Also, stop saying a feature is not production-ready when it’s been used in productions. I’ve done two with it. I think the phrase you’re looking for is “not robust enough for some productions”. It is, in fact, production-ready for people willing to use the latest features despite knowing there may be issues. Just because it doesn’t support some feature you need doesn’t mean it can’t be used in production. I’ve used the Loop Cut tool thousands of times in production even though it doesn’t have the spread parameter that I wish it did. On the other hand, Blender’s particle system has fallen short for me many times making me have to resort to other software, but it has been used thousands of times in other people’s productions, so I don’t refer to it as “supposedly production ready”.