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.
26 Likes
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
6 Likes
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”.
5 Likes
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 
1 Like
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?
1 Like
No, you shouldn’t lose any functionality at all at any point in the transition to fields.
5 Likes
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
1 Like
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?
Alright, fair enough. It seems overkill to me, since “set persistent attribute” is the same except for its extra text field specifying the attribute name. Maybe I underestimate just how often setting position is needed ?
1 Like
Yeah, more nodes means more data, and more results in the search menu, making it harder to find a specific node…
I would much prefer fewer multipurpose nodes than more nodes that only do one thing.
But then again, people have hated attributes from the very start as they are supposedly “unintuitive” even with the search feature.
That’s not to say that I don’t like fields (I think they are very quick and easy to work with ) , but I’m okay with using a string input every once and a while.
There are a few more nodes I would like to see merged, such as point separate and delete geometry. I also think the position, normal, and index could be merged into a single geometry info node.
1 Like
I believe the idea is to make the system less dependent on the store/extract nodes. I do think we can keep the store/extract nodes just for some user freedom, but idealy the users should not be forced to use a string input for attributes in the Field workflow. I think we are heading towards a direction where store/extract becomes optional and more of a user freedom thing.
It is needed very often indeed, especially in modeling. You can select part of the mesh and scale the part with this node. You can do solidify by using the extrude and move node with a set position node afterwards (although it would be more ideal for extrude and move node itself to accept field input). You can do displacement wth a noise texture and a set position node. It is indeed used very often.
I think the reason for them to be seperate should be avoiding nodes with large and chunky UI, I think putting them in one seperate category should be good enough
This suggestion was inpired by another earlier suggestion of the geometry info node, but Hans didn’t like that idea, so I suggested a seperate category instead.
2 Likes
When will field branch merge with master branch?
It has already been asked:
It’s probably going to be merged this week (since the quote was last week). Excited!
3 Likes
Hello,
I’ve been playing around with the index node and wanted to provide some feedback, so I recorded a video about it, you can watch it here:
Topics are:
- Get the Count (or Last Index)
- Reading the attribute of specific Index
- Storing and using that as a “constant” variable
- Transfer attributes via index
P.S. it is debatable if it’s better to get the Count or the Last Index. For most math we’d want to use the Last Index instead of the count, which is count - 1.
8 Likes