Yes, exactly. I wanted to write about Attribute VOP but I did not want to derail too much. While Houdini is a great example of a good node based workflow in general, I actually think that Blender can surpass it in some aspects by actually going down the route which does not limit vertex operation into a sub-network which uses different mechanism than the top level node network.
While Attribute VOP is a proven solution to this problem, I never really considered it Houdini’s strength. In fact, on few occasions I actually felt limited and slowed down by it, as it required spending extra time preparing the data to be brought into VOP and then taking additional steps to selectively output results of the VOP back to the top level network to be used by subsequent nodes. I think fields will make this much smoother.
And yet another cool thing about fields is that if you actually want to have the linear, modifier stack-like flow of the nodes, you still can. You can simply adapt a workflow of making your own node groups which input and output mainly just a single geometry socket, and a few top level, tweaking parameters, do all your fields stuff in it, and then think of that node as a modifier you’ve made yourself.
Dear passionate artists, early adopters. The conversation here is derailing from the topic over and over again. I’ve seen the same pattern happening with other threads and it is alarming.
Effectively this draws developers away from those threads. And what could be a nice feedback thread about the Fields prototype quickly turns into something that actually gets on the way of development.
If anyone has any specific feedback to give regarding how Fields work, this is the place for it (shortcomes, tests, suggestions - please share your thoughts). For anything else please move the discussion to one of the community sites.
I don’t think so, the closest would be XSI Ice. But really I agree it is a very elegant solution. And the actual attribute wrangling can always be collapsed into node groups which doesn’t mean they have to share the same (visual) context as “regular” geometry nodes.
Nice node group! It’s wonderful how simple it is to read.
I’ve seen lots of people using the regular math node to create selections. That works, but we also have the Float Compare node in geometry nodes for this purpose, with a few benefits:
Its purpose is more clear since it outputs a boolean
There are fewer choices in the dropdown, making it faster to use
The performance should be better since it doesn’t have to rely on implicit conversions later on.
Hey thanks! I didn’t know that, I just updated the node with the Float Compare! This Field branch is pretty funny to use, It would be great to have the latest nodes like remesh in the test branch, I have crazy things in mind to test it:
Dear devs please do not forget about a convert mesh to point node.
it’s a very simple node but it will make the experience of instancing on vertices/edges/faces many more uniform. i’m stuck this issue for months now
Is there a way, or is it yet planned, to implement the functionality of “delete only faces/edges” in geometry nodes?
Right now, we only have 4 options in the delete geometry node.
It would be nice to have all these options, as well as dissolves, although those might belong in a different node.
Also, especially with fields, boolean math is often used, and I would like complex boolean operations such as exclusive OR etc. For my own uses, I have had to make a nodegroup for them to be easily and quickly accessible. It would be great for these to be part of the boolean math node.
Boolean is broken in fields branch, can you guys confirm? I had to use multiple objects and modifiers to do this, but if I had booleans working (and fast option as well, this is really convenient and needed in some cases like this!) I probably could do it all in one node graph.
@HooglyBoogly Speaking of fast to use math nodes, I had this Idea today:
when using the search in the add node menu, it would be nice if, for example, searching “multiply” could actually match with various math nodes like “math” set to “multiply”, or “vector math” set to “multiply”, and actually one could select the node set on “multiply” directly from the add menu, to quickly create a multiply node, instead of having to search “math”, creating it and setting to the desired operation.
I felt the exact same! Especially since it’s such a common node to use. My guess is that this is not easy to implement right now. You would have to add a new concept like preset nodes or something so that the “Add” menu can find them.
Yeah, that’s not a priority of course, but It would be handy!
Yeah, I wanted to model a magnum, but i ended up doing a “cremino” ice cream, since I havent’ got the remesh node, the topology on the sharp corner of the magnum would not displace well, lol.
Cool, the original proposal was to have single nodes, but I agree that a math node with dropdown is ok, so the add menu is not too crowded by single operations nodes, as other have suggested lately in the task thread, the shortcut method sounds like the best of two worlds, let’s hope it gets done! Thanks for the link!
As a Brazilian Blender instructor, most of students are aware of Geometry Nodes and its future. Most found the old attribute workflow difficult, but powerful. After some discussion with a group of students of entry/junior level, most are pleased with how the new Fields approach works, because it’s better, easier, faster and makes sense on an “average user” point of view, at least at the start with simpler user cases.
However, some points to share with you guys:
It is really important to have GN to be shipped with some node groups. Yes, the new fields are easier, but most users won’t know how to use a dot product vector math in order to archieve some relatively simple effect.
It may sound like an exageration, but maybe you should consider to create some nodes that acts like a “shortcut”, in lack of better words, ou maybe somekind of node groups to archieve this “shortcut”. I mean, to create some node trees, most of the users won’t know about logical (math or vector nodes) to archieve what they want. So instead of an operation to create a sine effect using multiple nodes, or even a simple add operation using the Math node, some other naming for groups/simpler nodes could be used. In short, what I’m trying to say is: most people are really afraid of math, haha.
For instance: Random float is something that people tend to overlook. What is a float? By just seeing its name one wouldn’t know that can be used to generate random numbers. While I don’t think it’s a good idea to dumb down the powerfull low level nodes workflow, I really think that some better naming and/or group of nodes in order to create some common nodes interactions with easy to understand naming could help a lot of people.
Thanks for your attention and keep up the amazing work.
Also, to add to the above post, following the same “logic” (assuming there is one) of my idea, one thing that you should, in my opinion, prioritize is fall offs. Proximity, Less Than, More than, doesn’t appeal to most of users. Most people just want an object fall off, random fall off, linear fall off, the more… the better. Make as plug and play as possible to make GN gain traction with people, especially people doing daily motion, ad and VFX work where speed with tight deadlines is the key. Make it easy to use with simpler node groups and let the low level nodes for the hardcore people for more advanced stuff, more complex node groups, add-on creators, etc.
While I agree that the community will play a big hole here, basic stuff should come with Blender. For instance, when I told some students that in the near future they could download some presets for falloff effects, which is a pretty basic and common stuff for all kinds of projects, they didn’t look happy with basic stuff needing some additional (possible paid) download.
You have some great points! I expect the asset browser to play a huge role. The planned built-in asset bundle gives us a really nice opportunity to include those procedural effects like you mention. Falloffs, selections, noise, scattering with randomness, and more are all things we’ve talked about including higher level nodes for. The workflow could be browsing or searching in the asset browser editor or in a “mini asset browser” in the node editor, then a simple drag and drop. Ideally we could have some nice thumbnails too!
I think due to time constraints, supporting node groups well in the asset browser isn’t a goal for 3.0, but I’m guessing the release after would be a good time to work on this stuff.
I agree! Expecially when it comes to vector math and programming terminology like “float”, for non programmers it can really make no sense.
“Wrapper” groups and in general higher level groups, or even built-in nodes (if it’s worth it performance-wise) would be nice, but I would still keep low level nodes with programming terminology names, maybe well documented (so non coders can still learn), after all, nodes are a visual programming tool, and I see coders and more IT-oriented people complain about strange terminology.
Blender can be a great tool for both pure Artists and Pure Technical People. I think that Just creating a visual/logical separation between low level nodes with high level / wrapper nodes by color coding the nodes could be a nice start! Then as @HooglyBoogly said, Asset Browser/manager with nice thumbnails can be a great improvement for Artists friendly workflows in the future!
Yes, it is much easier for regular artists to operate with possibilities rather than math.
When artist start to operate with math abstraction level, he evolves as a technical artist.
More Shrinkwrap study, I’m trying to reverse engineer the modifier, so far I was able to match projected behavior, on surface, with limit, offset and positive culling options (off/front/back):
It got a little bit messy with switches and boolean math nodes to match the offset behavior on different culling options:
It’s the first time I used “Attribute Freeze” I believe, this is an essential node! I didn’t realize it’s role until i started thinking: “wait, now I need the normals before the points are displaced, how do I get that value if it’s evaluated back from the geometry the field is plugged in? I need a geometry to probe and freeze the attr… wait a minute… ” The fact that the node is named “freezed” helped me to figure out that that’s what I needed
I think someone already suggested it before, but having an enum input type socket and a multiple input switch compatible, would allow me to replicate this:
maybe with a dropdown, instead of having this:
Or is there a way to do that that I’m not aware of?
