Thanks for all your inputs guys. Actually I think what would avoid most of the “issues” would be a visual feedback of the values on the viewport. Then we could guide ourselves by the colors, for instance, instead of just the node value output. Pretty much something like weight paint visual feedback where one can see the different values.
But I’m pretty sure this was already discussed and probably is on the plan.
Ohhhh I see now, that’s a Shape Key!
Good to hear that. What do you exactly mean with “falloffs”? I think I’ve missed that.
Is it possible to output different floats to be used on the curves to have different heights?? I assume that to have a way to read some object IDs without the need of point distribute/instance would be a nice thing. The problem is that on this tree, curves are created after the float, so on my understanding, it isn’t possible. Either way, is it possible to generate randomness per object without the points nodes?
This issue and lots of others will be solved when attribute transfer will be improved. If you could affect parameters of instances from another GN object, then it would solve like half of animation limits. For now, the only fairly easy but limited method I know is plug your value to geometry input, and instance with animation nodes (attribute object output and copy data path, only float values and it’s slow). For more, you can ask on AN discord.
Yeah, I hope to see this on GN soon.
That tree inspired me @kurk . As long as you deform the original mesh within the same node geometry stream, you can store and blend the edits with the original at any point, just like shapekeys!
That looks good. That was what I had in my mind initially. Being able to morph between modified shapes is very helpful, I am hoping to make a morphing setup between the same topology meshes.
Is there an idea of when will the fields implementation merge in master will happen?
(Roughly)
Yeah, hopefully sometime next week. Keep in mind we started from scratch for the real thing, so it won’t have nearly as many features as the prototype yet.
It’s mind boggling to a mostly non-coder to think a working prototype can necessitate in fact major reworks to be properly made (whatever that means). Keep up the good work ! I’ve seen your commits for level sets and I have no idea what they could be, so I’m impatient to see what’s in store
Cheers
Been using the prototype a lot recently, and one thing I noticed. The shade smooth operation done with Store Persistent Attribute does not feel fit any more.
I remember previously in the Geometry Nodes main thread someone suggested a dedicated shade smooth node and I disagreed. Becuase back then use an Attribute fill does not feel that different than using a dedicated node in the old workflow, and it also fitted the old workflow pretty well.
But with the new Field workflow, use the store attribute node just for shade smooth feels out of place with the overall Field workflow and I finally start to feel troublesome. I am now suggesting a dedicated Shade Smooth node with a checkbox that accepts a field input:
I believe this makes sense since we now also have nodes like “Set Position”.
Do you expect that we will loose a lot of functionality compared to what we have in master as of today? (With the first merge I mean)
Thanks for the answer 
Also interested in this,
but @JuanGea your question is not clear
Do you mean compared to current 3.0 alpha or current 3.0 field prototype?
No, you shouldn’t lose any functionality at all at any point in the transition to fields.
O was referring to master, so the alpha not the prototype, I know the prototype will have more things than master, at first at least
By the way, what’s the deal with set position ? Why is there a special case for position attribute ?
My guess is that It’s simply a very common use case, so It’s handy to just have a bult-in node to do that?
