Not sure if I’m interpreting you correctly but here’s a setup mirroring the ear of suzane (here the mirroring is done by scalling -1 in the x axis, for more complex situations this would become a bit more complex accordingly):
Yeah kinda! Although I’m hoping to not have to use vertex groups. Since I might or probably have shared faces that I’d want to mirror or not. Unless this can work in that case.
So if you had a cube and wanted to keep the top face but mirror the left and right sides.
1 Like
Just a reminder that we have Collection Info and Object Info input nodes:
So it’d be cleaner if the Normal and Position nodes were replaced by a “Geometry Info” node, which more channels could then be added to in future if needed.
Also, in the input section, Float constant input is referred to as “Value”
where as everywhere else, including the very same Input section, Floats are referred to as Floats. I know the “Value” name is remnant from the Shader Editor design, however I think in this case, the unification of naming of data types within the scope of a single editor (Geometry Nodes) is more important than unification of equivalent nodes across multiple node editors.
Especially given that the “Value” Input it surrounded by names like “Vector” and “String”, so a person new to Blender but familiar with essential data types will naturally be seeking the word “Float”.
8 Likes
When blender will allow for realy procedural drawing.
Then shouldn’t it be more a descriptive language format as well, more how cad/cam works ?
I mean like, cube size with rounded corners (beveled radius), with triangle cut at position, where triangle has the dimensions…
As for final object drwas, one adds an output-draw node with arc treshold or 0.0x radials for new verticles.
So… blender would be able to handle the STEP format, instead output-draw one could have then a output-file to write step format (without arc defined) as well, a pure shape description.
I don’t know for the current field discussion, but having a final goal towards procedural (CAD CAM Description alike drawing), then it might help to dive into languages such as STP / FBX to see what would be needed for node types.
If you got such a base then you might at all kind of shape transformers, selections types, intersections, or distance effects, upon vertex groups, or object instances etc.
2 Likes
I tried doing this type of effect, here’s my feedback:
- I couldn’t use fields, because it was just missing nodes and attributes that I would have wanted to manipulate
- I wanted to use boolean operations, to clip the lines onto the mesh, but that wasn’t possible (I think), so I had to do raycasts (which aren’t available in fields yet)
- There is no way to smooth the normals of geometry generated in geo nodes, not even by trying to set the
normalattribute (I believe?!) - Boolean values are only being exposed as a float on the modifier
- Start- and end position modes would be a nice addition to the grid node
- That a geometry nodes setup is automatically available inside of other geo nodes setups as a node group is sooo good! I miss this all the time with shading nodes, so it’s great to see this done right in geo nodes.
- The performance is pretty good imo
- I only had to do very little attribute stuff
vertical lines.blend.txt (155.8 KB)
3 Likes
I would prefer just have all field input nodes to be in a seperate category to keep them organized and also prevent the node from having large UI, also with this big long node people tend to use one single of this node and do a lot of long connections making node tree looks more messy, while with these small Position nodes etc it is easier to shift D around and the overall tree just looks cleaner.
Yeah the nodes are under active development and more nodes are coming, BTW the material assign node and select by material node has just committed today.
It is traditionally done by setting the shade_smooth attribute, but I agree that this is not ideal, I had this suggestion earlier in this thread:
2 Likes
Thanks, I didn’t know, setting the attribute does what I want! A shade smooth node would indeed be nice though
I remember the set position node had a checkbox in the selection input in the last build, what happened to it? I loved it, I was trying to see whether the material assign node also has it but now it’s gone
I loved it because I had this seggestion from way back:
I thought my suggestion was taken into action and I was so happy. Please tell me you are adding it back😢
This maybe has to do with the newly committed Domain interpolation? Not sure why it would remove this nice little checkbox though, I thought it’s just the conversion between domains like vertex selection to face selection.
FYI:
Geometry Nodes: Hide values for selection inputs
Toggling the selection off in the node is the same as muting it, so exposing it there doesn’t help, and makes it less clear that it’s meant to be used as a field.
2 Likes
Thanks for the link. Now I see.
But I still think it can be useful. For example, in the “Shade Smooth” node I suggested, not checking the box would be flat shading. If you have a mesh that is alredy shade smoothed, uncheck this box can make it flat shading. (although the logic might not be selecion now in this case) I still believe the checkbox can be useful.
Another thought. Maybe the current nodes can stay without it, only those nodes that need it will have the checkbox, like the “shade smooth” in the future. The delete geometry node would need to change its behavior from deleting nothing by default to delete everything by default, etc. to satisfy the condition of “the same as muting it”.
There’s a “Hide unused node sockets” shortcut which makes the multi-output node look identical to the individual ones we have right now.
2 Likes
Yes but people still tend to use the big node and long connections with it, it’s more psychological I think. And don’t forget we have this compact node design: ⚓ T87009 Compact Nodes
So this big chunky node UI is an officially admitted problem. Although I would argue instead of having the N panel opened all the time workflow, I would prefer to just have collapsible parameters on the nodes. I am part of those who only open the N panel when I have to.
No one considers that a problem in the shader editor. Plus we are literally talking about just grouping geometry info nodes together like object info and collection info. It makes sense from the consistency standpoint.
The lowest common denominator for the design should not be people who don’t know how to use nodes properly. You will get the exact same problem with the Group Input node, where people tend to use one group input with many long wires instead of multiple group inputs with hidden unused sockets. Yet you don’t see anyone talking about group input node redesign.
3 Likes
I did a little experiment a while back with the prototype branch. I have two versions of the same node tree.
The first one tried to use less nodes but have some long connections.
The second one tried to eliminate long connections by using duplicated nodes.
And I took these two screenshots and ask people which of them they think looks less messy. Most people around me picked the “more nodes but shorter connection” one.
I started to duplicate the group input node around ever since.
So I would lean towards the smaller nodes, I beilieve having them in their own shift A category is already enough for organizing, now they feel all over the place just because they are mixed together with other types of input nodes. It would feel nicer after they are in their own category.
EDIT: I just recalled this, the reasons why Attribute Processor was abandoned:
So it is an officially admitted problem, and new nodes should avoid stepping in the same problem as the old nodes I think.
2 Likes
I think you are mixing up two different problems. Your solution just offloads the clutter somewhere else. If we have one unique node for each input then the total amount of nodes available in the add menu will be much higher and it will be harder to get started with GN just due to sheer amount of nodes.
I am still not sure you understand what I mean. The result will be the same:
And also keep in mind that the GN version of the Geometry Info node would have way less inputs than the Shader Editor one, but if some inputs needed to be added to the GN, we would not see a spike in the amount of clutter in the Add menu.
Furthermore, the Compact Node design you mention is from a significant part consequence of early inefficient Attribute based GN design which required many nodes to have excessive amount of inputs for the individual attribute operations as well as additional inputs for an attribute to store the result in. I reckon that with the Fields system, this issue will be way less pressing, and we will probably get around without needing such heavy machinery for customization of the slot display at all.
To me the compact node design really feels like a solution for a problem which has been artificially created by the initial, string attribute based GN design.
2 Likes
Having a Geometry Input node also seems like a good idea to me…
Currently one of my biggest hurdles with Geo Nodes is access to information that isn’t available yet, like Polygon Size (even though the old instancing already supports that):
We’re going to need to access a lot of data in the nodes, and this would really clutter/overwhelm the creation menu if each one is an individual node.
On the other hand with too many ports it would be an uber node so that could also cause problems, so I’m not 100% sure which is best here.
Maybe separate Point, Polygon nodes would be ok if each one of those would have several useful ports.
1 Like
The “compact nodes” idea has been around for longer than that. In some versions of it, it completely rids most nodes of all “non-essential” sockets and moves all settings, including those that are not exposed as sockets, to a different place (a different editor or the sidebar). It’s a change in paradigm rather than an interface cleanup (see Nuke or Houdini).
It was indeed a good candidate for helping see clearly through the rather complicated attribute nodes, but those were never the only targets.
That being said, I agree that different geometry variables should be accessible through the same node. We could even have a version of “compact nodes” that only pops output sockets on demand, by dragging from an otherwise empty node (that’s just an idea).
I am not convinced on compact nodes. I mean who decides which node sockets are essential and which not? As long as the node socket deserves to actually be implemented in the node, it means it has a reason. Then, the decision which node sockets are essential basically becomes (usually faulty) assumption of user intention, which no one can properly do in advance.
So if that really becomes implemented, then the easy workflow of “Add a node and start using it” becomes slower, more frustrating workflow of “Add a node, tinker with some UI panel to actually expose the inputs first, and only then start using it”.
You can already see it with the “feature” which automatically reconnects a node wire into the next input socket below if you drag a new wire into already occupied socket. The simple “Drag a new node connection into occupied node slot to replace it” workflow became more frustrating “Drag a new node connection into occupied node slot to replace it, then disconnect unintentionally created node link below”. Assuming user intention in advance almost never works.
If there are nodes so complex that they actually require some node input management system, then perhaps those should be broken down into smaller, more atomic functions. But I mean, throughout all those years we have complex nodes such as Principled BSDF shader, not many people have really considered this to be a problem. It feels like a solution in search of a problem, exactly like the automatic occupied slot node wire reconnect mentioned above.
2 Likes
The user, through deliberate inclusion. It doesn’t mean that sockets should be hard to access, though. Like I suggested earlier there could be a way to drag out a noodle from the compact node interface, choosing which node property to connect and making the connection all in one go.
I completely agree with this. I don’t like side-effects either. I mean not the company, they’re ok. But trying to predict user intention pretty much always gets in the way imho.
I have seen it brought up many, many times. The principled bsdf is too big for many, including me, and some nodes in gn are bound to get equally tall if not taller. I agree that in principle nodes should stay simple, and complex setups should be made into node groups. However that probably won’t be the case for all : the raycast node is a prime example of that. How do you even break it down ?
Are you familiar with M ? all its node editors including the legacy ones have a way to connect attributes in a very non-intrusive way. I used to not be fond of this, because it’s a little more hidden than having all sockets exposed right away, but now that I know my way around the node systems much better, I like having this little “plus” icon that expands and gives me a list of available sockets to drag from.
I should mention why I think there is a problem. Node trees can become extremely large, as you know, and even my best efforts to pack every utility into a node group, the use of frames, reroutes, etc. doesn’t get the tree to nearly the level of readability of, say, a Nuke node tree.
I guess this could be improved through simple visual changes, such as the node title size, and so on. but I think the issue goes deeper : scanning a node tree is harder when you’ve got plenty of properties and checkboxes in the way, at least it is for me. This is why I think a compact node design is worth pursuing.
AFAIK there’s no raycast node in the Fields GN version that’s currently in master, and the raycast node in the old, attribute based GN was actually a prime example of the string attribute workflow being the cause for excessive amount of nodes.
If you look at it actually:
https://docs.blender.org/manual/en/dev/modeling/geometry_nodes/geometry/raycast.html
You can’t really perform a raycast without source and target geometry, ray direction and ray length. So for you to be able to use that node, all those 4 inputs would have to be immediately available anyway. Otherwise you would always have to manually expose additional inputs to even be able to use the node correctly. That would not make sense. All the inputs prefixed with Hit would actually be outputs in case of Fields solution. That leaves us just with the “Target attribute input being the one that could not be exposed by default”. If even one of the most complex GN nodes would have only one of its inputs hidden by default, would that be really worth it?
I still feel like everyone keeps forgetting about the “Hide Unused Node Sockets” feature. I mean the resulting state we all want is exactly the same in both cases. We just want more readable node trees by not seeing visual clutter caused by unused node sockets and their values. Something like this:
But there is significant difference in way this can be achieved:
A. Existing “Hide Unused Node Sockets Feature”
- You create nodes with all the sockets
- You connect all the sockets you want to use together
- You can select one or multiple nodes, press one hotkey (H in my case) and instantly get the result on the left looking like the result on the right.
- If you want to revert it, you can just press the hotkey on the same selection again.
B. Using the Compact Nodes proposed design
- You create nodes which may or may not have all the sockets you need exposed.
- In some case, you need to go to some UI panel and expose the sockets yourself
- You need to do this individually for each node, you can’t perform this operation on multiple nodes at once.
- If you want to revert/adjust it, once again, you can’t do it in a batch easily.
In the solution A, there is no room for error by assuming how users want to use the given node in advance. Solution A also does not require adding whole new functionality to Blender, with it’s own relatively complex user interface. Both solution A and B will in the end result into node network trees of the same readability.
I am not familiar with M. I suppose it’s something similar to Compact Nodes, but something that addresses this issue better than the ⚓ T87009 Compact Nodes ?
Anyway, I encourage you to try following: If you have any complex GN node tree which uses fields, try to just select literally all the nodes and use the hide unused node sockets operator. I use custom keymap but I believe the stock keymap hotkey is Ctrl+H. You should see a cleaner node tree instantly. Then, after you try this, ask yourself, how much different would the final result be to what you’d get with the proposed compact nodes?
(It won’t work with the string attribute one, as if I remember correctly, the attribute field with a string in it is still considered unused because the node socket doesn’t have any wire going into it)
2 Likes