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:
That’s pretty much only thing I’d like to see changed. That they let users get involved while they develop features, not after they do.
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.
It’s a production method called “scrum”, where you try, try and retry during production, so as to test solutions in as most meaningful conditions as possible. It’s not backtracking, it’s experimenting. What you saw was precisely the testing you suggested they did
I updated the fields prototype with two new nodes.
Both nodes are just experiments for now, I’m just testing how this functionality could be made accessible with fields.
Sample Mesh Surface
Finds the closest surface point to a given position and outputs various things from that point: position, normal, distance to the original position and a custom attribute.
Right now only one custom attribute can be sampled on the surface, this should become more dynamic in the future.
Evaluate Curve
Takes a length as input and evaluates the curve at that position. Similar to the node above, it outputs the position, tangent, normal and a custom attribute at that position on the curve.
What makes both of these nodes different compared to other nodes is that they have two field inputs which are evaluated on different geometries.
The custom attribute input is evaluated on the mesh/curve that is sampled/evaluated. The position/length input can be a constant or can be evaluated on a different geometry later on when doing some kind of attribute transfer.
yup, but it seems that they learned and this time they made lots of different proposals and even made prototypes for the most promising two, as to avoid repeating the same mistake of just going with what seems to be right.
that being said i’d also agree with hadriscus that the problems can be traced back to the way they had adopted scrum to quickly build mvps, trying mostly to satisfy the very unambitious needs of the sprite fright production (unambitious as in requiring little from geometry nodes; not as in sprite fright isn’t trying hard)
The development of geometry nodes makes very much sense to me.
First, they implemented the most primitive system, based off what they need for scattering in sprite fright.
Then, they made it compatible with everything that was already existing, and extended compatibility of things that are already existing.
Then they optimized it for speed and performance.
Then they worked on usability.
This makes sense for any tool. Say you are designing an ax.
First you make a blade that chops specific things very well.
Then you test it with other materials, and optimize it to work on as many things as possible.
Then you make it fast and durable, and make a handle with an optimal length.
Then, and only then when it does what it’s supposed to do, you make a nice handle that is comfortable and easy to grip.
Whatever… I’m really excited that a decision is taken, and we already got a couple of new nodes prototypes!Thanks @jacqueslucke !
I Just hope that back-compatibilty development won’t be too time consuming, because I can’t wait to test new workflows with fields, expecially with modeling.
That was my thought as well.
What’s the difference with attribute transfer ?
New nodes are awesome!
Actually, I am testing the “Fields” prototype for the first time. It is much easier to use, but I still struggle with few simple things like how to put generated spheres on curve’s ends…
If you want to just put it there in terms of position, the new evaluate curve node can do it:
You can adjust where the sphere is on the curve, just adjust the “length” on the evaluate curve node.
This was actually my first reaction after reading his post. But I soon realized in order to do that, the sphere needs to be a seperate object. It is not ideal at least until Jacques commits his patch to make geometry directly available for instancing.
And that’s why I started my reply with:
Oh, very interesting. I did not realize that yours did not require instancing. I hope that patch gets committed soon.
i made some kind of beach scene
feedback:
Geo Nodes Shore.blend.txt (418.0 KB)
Thanks a lot! This will work!
Also, it’ll work even more handy and convenient if the Length parameter would be normalized in [0-1] range.
Can you guys confirm that the bounding box node is broken in the fields prototype? Min and Max X Y and Z components seem always to output zero:
Build dated of 18th aug, confirm.
