The geometry created up to that point is baked and can be edited directly in edit mode. Any nodes leading to the checkpoint cannot be changed without invalidating the manual tweaks.
That means it’s no better than baking/applying the result of geonodes. It just seems like a more handy alternative to keeping backups of your procedural objects.
The idea of an edit mesh node is that it works on top of your node tree. Changing any previous node should affect the edit mesh operations otherwise there’s no point in having a node at all. That’s the idea behind proceduralism…
Is it really not doable to have the edit mesh node record all operators and the component ids they operate on, tie it into some sort of macro, and have it work like any other node ?
I am quite sure there is no generally applicable way for that without special rules and exceptions.
E.g. what should happen if a previous node is changed? Should all the modified data stay unchanged and everything that has not been touched gets updated? What should happen if the topology is modified by the previous nodes?
To have an implementation of an edit mesh node as you are suggesting it, all those cases need to have a very clear answer, as well as all other cases I have not mentioned. On top of that, the answers to those special cases need to be reasonable and practical in the sense that the user can have some sort of an intuition of what happens in general.
There might be a good solution for that, but I am quite confident it is not simple to find it. It appears quite likely to me that a compromise would need to be made which works for some use cases and not for others.
Geometry nodes are new to Blender and still need work. I am not sure whether it would be a good time investment in trying to solve such a tricky case right now in depth. The “baking” shortcut appears reasonable to me for now.
Freezing makes perfect sense. Its not possible to do what Hadriscus asks. It has been a long time ago since I used Max but if I remember correctly even there the edit mesh modifier had cases where it would “break”. If you changed its input (i.e. the geometry that it was fed) it would just spazz out and give unpredictable results. And that makes perfect sense because how would it know what face was extruded if the vertex count and order changes?
Freezing the node tree is one solution. Another would be to simply reset the edit mesh node if its input is changed. The latter approach would have my preference. It keeps the node tree up to it “live” but having an edit mesh node in it does mean that node will reset if you change the tree leading up to it. It would still be hugely beneficial over having to apply the node tree and destroy whatever logic was there to generate the geo up to that point.
I agree.
What I can imagine is use cases I haven’t considered for which it would work. Those would be quite narrow, like the topology is not allowed to change and other conditions and then a clearly defined thing would happen. There might be several such cases and all of those would need a different node (or one may switch between them in one node).
As of now, I am quite sure there isn’t a general solution, but narrow ones might do the trick (if really needed).
Edit: @Hadriscus: I see you are currently typing Do you have a specific use case you have in mind where you think it should work, or do you think there should be a general solution?
Of course, it would be expected that it cannot produce good results with a changing topology. As far as I understand it, Max’s edit poly is conceptually very simple : it works with component ids. Move vertex number 48, delete face number 71… If the upstream nodes (or modifiers) are adjusted, the components targeted by the modifier may completely change position, and it may become largely irrelevant. But that’s just the worst case ! Best case, the user moves, deletes, or rotates points from a simulated point cloud, and those changes, even if affected by a change in an upstream node, are not as breaking as a missing face on your character in a place you never intended.
Chronosculpt had really good ideas for tweaking simulations : https://www.youtube.com/watch?v=rV6fyfJolcI
AFAIK some tweaks could be made to target specific objects or components (by id), whereas other were space-based, creating a falloff, some sort of force by which any part of the input simulation would be affected.
@DeepBlender to be frank, I don’t think an edit mesh node would be very helpful if it doesn’t fit within the procedural workflow. If we want to art-direct a simulation result, I don’t see how we need to freeze anything as we can just branch out at that point. (Unless there’s a specific technical hurdle in entering edit mode at an arbitrary point… I wouldn’t know that)
But really, don’t you think tools that operate on space and time rather than on component ids would be a much better fit ? it’s like procedural selections in geonodes versus id-based selections in edit mode. One is procedural the other isn’t
Maybe I missed it, but as far as I can see, they haven’t changed anything in earlier nodes. They took the simulation and then made changes to it. They never recalculated the simulation or anything like that and expected their edits to be preserved (at least in the video).
Not sure whether we are not talking about the same.
Yes I figured you were thinking in this direction. The point is, once you are talking about “selection methods” like that: volumes, falloffs, forces (essentially directional falloffs) its no longer an edit mesh node. An edit mesh node, in my mind, combines those seamlessly. It allows the user to select (click on a face) and perform an action (extrude for example) and do this multiple times in multiple variations and its all stored in the single node.
Whereas what you refer to would be much more like two steps in a node tree. For example select by volume (whatever shape that may take) and displace (again many choices). At that point you are talking about a normal node tree where the input (to the select by volume in this example) can freely change without any unpredictable effects.
I love non-destructive workflows, which is very often true for procedural workflows as well. I would love it to have a solution that works in the way you are describing. However, I have no idea how this could be implemented, such that it is actually useful. Having an idea that sounds great isn’t sufficient.
I have a feeling Hadriscus and me just have very different idea’s about what an edit mesh node is/is supposed to do.
If I have an animated point cloud and I have it move through a lattice who’s influence I dial up and down would that not fit the case he describes?
The lattice is limited to an area in space, its assigned to a specific object so it only influences that (lets call that the id) and its influence is limited to a specific moment in time.
I don’t need an edit mesh node for that and neither would I want to?
Now I could really be off base here since I’ve done nothing with geo nodes yet except follow their development loosely but
Either way its fun to see this all coming together.
Agreed, a lattice works for that ! However, all aspects of a simulation could be influenced this way, not just component positions : deleting points, scaling them, freezing them in time, and so on, in the same “id-independent” manner as a lattice does for points positions.
Sure thing (almost) all that can be done right now in geonodes (apart from the time dependent operations which would need solvers to exist first), but in a rather indirect way : creating falloffs, manipulating attributes, etc. right now is kind of removed from the viewport, it would be nice if those things were abstracted away, made into “node tools”.
What I assume Dalai is getting at with this intermediate “edit node” is a way to have the direct manipulation benefits of edit mode, inside geonodes. However the proposed way seems so limited to me that I can’t help but try to think of something that really sits into the procedural workflow, ie without having to freeze the nodetree.
That being said, I’m a taker for any improvement in that regard. An edit node would be nice to have indeed, even if it’s just a way to freeze the upstream nodetree for later consumption. Food for thought ! Water to the mill ! Vertices to the slaughter !
Having a “freeze node” which would break with any topological change.
Having an “attribute edit” node which can be regarded as vertex group - (selection attribute) + shape keys - (position attribute) + any other attribute you can think of.
The changed data could be per id or any other indicator, a little bit similar to what @Hadriscus has said.
This way, we get more stability on newly generated topology.
For example, if we change the scale attribute per position with some threshold, the node would affect the geometry besides the modified vertex as well.
I imagine changing attributes in two ways:
In the Viewport (as shape keys and vertex color)
In the SpreadSheet (by double-clicking and editing values directly.
In houdini, you can make selections of points, faces, using volumes or with other meshes, and modify, delete, do whatever you want with the selected parts.
It’s non-destructive
If you select multiple points, can you edit each one individually or are they all move\deleted as one big geometry chunk?
What happens if you change the topology before the volume selection?
I think it’s a must in almost every fine-tuning.
For example - you scatter some trees in your forest, then you want to make a specific tree a little bit smaller.
You just insert the “edit attribute” node and type your desired scale in the SpreadSheet.
If you want to change the distribution, you can make your change per position, that way the location near the specified vertex will always grow smaller trees.
In 3ds Max you can select each point individually with a “edit poly” modifier and do with it whatever you want. You can transform points, delete points, add points and so on.
If the topology changes bellow this modifier you get a warning that topology changes might mess up whatever comes above. This works on the one hand with vertex indexes but it also uses some other technique to guesstimate what the user means. I forgot how it works in detail but it is hit and miss. Better than only going by index but definately better than nothing.
Or you can select a volume of points with a volume select modifier. You basically select every point that is within a volume (lets say a box). If a point is inside of this box it is affected by things you do after the volume select modifier.
If the point moves out of the box, perhaps because the point is animated it is no longer affected. Or if the box volume moves and some points are no longer inside the volume they are no longer affected.
Volumes can have falloffs (soft selection).
If you change the topology before the volume selection it does not really matter because the volume slelect will still only affect what ever is inside the volume and doesn’t care if vertieces with other indices were inside the volume before.
Do you have a specific use case you have in mind where you think it should work, or do you think there should be a general solution?
