“production-ready” assumes stability and continuity in time.
If the whole design is abruptly changing only 6 months after initial release, then no, it was not ready.
We can’t play with the industry feeling like this.
I’m very afraid that this abrupt direction change will hurt blender credibility toward professionals.
Why would large companies and professionals invest time and money in adopting blender if everything will become obsolete in later versions?
Don’t get me wrong the dev team is absolutely doing an absolute amazing and astonishing work.
This is foremost a marketing/communication issue and should be discussed by the team in charge of this matter, the devs should focus on dev instead of wasting time reading all this mess
This little discussion we are all having right now is only the beginning of the storm imo.
The communication/marketing team should be cautious upon 3.0 relases.
The fact that geometry nodes is in an LTS release COMPLETELY proves this statement false. Please realize that you are basically arguing that the blender developers are all liars. Childish. You should be embarrassed.
The fact that geometry nodes is in an LTS release COMPLETELY proves this statement false. Please realize that you are basically arguing that the blender developers are all liars. Childish. You should be embarrassed.
First of all, VEX nodes allow you to just write vex scripts. It was basically a script editor node. GN could not do anything like that.
Second, in Houdini, you are able to write any custom expression into an attribute field, so if you wanted to take a red channel and multiply it by 0.5, you could just write Color.R * 0.5. In GN, it became a frustrating affair of creating attribute separate node where you had to break vector into three individual floats, and then you had to use math node to multiply the float, and store the result in another attribute, and only then you could use it. The efficiency of these two workflows is incomparable.
Third, Houdini has the whole UI framework and infrastructure built around this attribute paradigm, so it’s actually comfortable to use. They have advanced features like for example being able to populate attribute field by a list of vertex (or other mesh element) indices based on select tool selection in the viewport, or advanced toolset to visualize node graph features inside of the viewport. Blender has no such infrastructure and it’d take quite a while to build up.
Houdini was designed around its node system from the very beginning, while Blender was designed with a different set of choices, which result in Fields solution just being a better fit. Even if we got attribute processor, expression evaluation in attribute fields and so on, I still don’t believe it’d became as smooth, easy to use and efficient workflow as fields are.
So if a developer releases Alpha version of a software, let’s say Embergen, and then some user overcomes a little bit of trouble, uses Embergen to produce some VDB simulation for some VFX in a movie, and the shot then makes it into a final movie, who is right? The developer, who released the software as unstable alpha version, or the user, who was able to use it in a commercial setting?
Exactly why I used geometry nodes instead of Scatter to scatter grass for a recent production. Scatter is not production ready. It crashes constantly. Thanks for the assets though.
I Think the similarity between the attribute processor is more with the attribute VOP , Wich actually has an internal node system incredibly similar to the blender one (It basically like the attribute wrangler but instead of written VEX you code through nodes). But yeah, Houdini is huge, geo nodes are young, maybe in the future we will have similar expression handling.
A very good pro of the fields (compared to Houdini workflow, and 2.93 gn workflow) are actually the anonymous attributes sockets workflow, it’s so easy to pipe , say multiple extrusion nodes , and pass the selection to the next node without caring about naming the attributes. I don’t know if there is a way to do that in Houdini. That’s really handy.
I assumed that since Brecht himself was the one who brought Houdini and VEX up and few users after him before me did so as well, then it should be okay.
I mean, after all, the discussion right now is about Blender having taken the direction that’s not similar to Houdini instead one that is, so it’s hard to make a case that Blender is somehow copying it.
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.
