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
8 Likes
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.
38 Likes
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.
1 Like
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.
16 Likes
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…
3 Likes
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.
Here are two spheres on both ends.
2 Likes
2 Likes
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:
3 Likes
Oh, very interesting. I did not realize that yours did not require instancing. I hope that patch gets committed soon.
2 Likes
i made some kind of beach scene
feedback:
- can’t use attributes in eevee
- on the move and extrude node, i’d like to have the selection options that are on the standard extrude node. Either way, neither of them accepts fields (yet?) for the distance, so that was somewhat of an annoyance
- i would have liked to send the distance between the water and the beach back from the water object to the beach object. So something like a reverse raycast (?) node that I could have added on the water object and that would have send that information to a point on the beach geometry may have been nice. alternatively I could have tried building everything inside of one node tree, but that would have made handling the scene in general more complex.
Geo Nodes Shore.blend.txt (418.0 KB)
15 Likes
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.
1 Like
Is there a way of using an attribute, such as Attribute Sample Texture, as a selection?
Yes, using the Attribute or Attribute Extract node.
But I think the final implementation will have nodes that look more like this, so you’ll be able to use the attributes dirrectly:
Edit - no need for the geo sockets, thanks Ludvik for pointing that out.
5 Likes
Nice. Thank you very much!
1 Like
I disagree with the mockup. Attribute sample texture should not have geometry input and output at all. It should simply be a node which has texture datablock input and mapping vector input, and outputs color and alpha, similar to shader editor texture.
There’s nothing in the Fields design that should necessitate Texture Sample node to input and output geometry.
15 Likes