The idea is that it’s not just the design team that figures out the right choice, but also the feedback from users using this in production. I can think of various examples where 3D apps released a complex feature like this, some early adopters use it in production immediately since it solves a real need, others wait for it to stabilize and become production ready for them.
How precisely this should be communicated can be debated, I personally would reserve the term “production ready” for when a feature has had a few releases to stabilize. But in the end I don’t think that makes a big difference or affects the development planning.
I completely understand that and have experienced that myself. I’ve used many new large features in their alpha/beta successfully in production. I was just aware of the risk of doing so, since they were not labeled as production ready.
And I also agree on reserving the term production ready for when a feature has had a few releases to stabilize is a good idea.
It’s just that from the outsiders perspective, seeing an iteration of GN with text based attribute workflow released as production ready, while also explicitly being claimed to be production ready on numerous places, sends a message of “this is the design direction we’re going with”, and then, proposals like Fields seem like something that “saved it in last minute”.
That may be completely wrong perspective of course. Perhaps this was the plan all along, but then it’d be odd to think that the original plan was indeed to significantly alter design of this production ready feature just half a year later.
When I read things like:
On top of the designs, there is work to be done for backward compatibility. This is all scheduled for Blender 3.0 and will be the focus of the Geometry Nodes module. That means the core developers and the community will prioritize this over adding new nodes/features.
After that, the focus will shift to expand the Fields design for future node systems.
I can’t help the feeling that had the GN remained experimental, it would be easier to focus on expanding new features of the winner Fields design instead of spending resources on mechanism for backwards compatibility of 2.93 and earlier GN scenes, and being constrained by it.
If I am wrong, I’d love to know. I guess my question is, since you said that you don’t think it makes a big difference or affects the development planning, you really wouldn’t say that if GN was still hidden under experimental features like asset browser, the dev team would be less constrained and had more freedom expanding the Fields version of GN, which would in turn get us to a truly production ready version faster?
Also, stop saying a feature is not production-ready when it’s been used in productions. I’ve done two with it. I think the phrase you’re looking for is “not robust enough for some productions”. It is, in fact, production-ready for people willing to use the latest features despite knowing there may be issues. Just because it doesn’t support some feature you need doesn’t mean it can’t be used in production. I’ve used the Loop Cut tool thousands of times in production even though it doesn’t have the spread parameter that I wish it did. On the other hand, Blender’s particle system has fallen short for me many times making me have to resort to other software, but it has been used thousands of times in other people’s productions, so I don’t refer to it as “supposedly production ready”.
I think that if geometry nodes had remained an experimental feature, you would not have had the same amount of contributions from volunteers or the levels of motivation and energy that the core development team has. And you might have ended up with a design that users don’t like as much due to less feedback.
Implementing backwards compatibility takes some extra time, but on the whole I don’t think it’s a big deal compared to other factors.
Now, this is interesting. So, all these users are complaining about an approach not being good for production and it turns out it’s probably the most production-proven paradigm in this case.
I don’t think so, the Fields in this proposal AFAIK is just an opened up version of the attribute processor. They are both basically different ways to deal with functions I think. It would not be neccesary to have attribute processor now that we decide to go with Fields.
What is fundamentally different between A. an attribute processor node group (envisioned to use only function nodes if I understand correctly), and B. a bunch of function nodes made into a node group ?
I believe the fundamental difference is that the Attribute Processor specifies context from the start, it has a “Geometry” green socket input. So the functions you write in the processor node group is actually dealing with an actual attribute data from a specific geometry. The expandable socket proposal was very similar in this sense.
Fields, however, does not specify the context from the start. For example, the “Position” Field input node does not have a “Geometry” green socket input, which means the “Position” node by itself is out of context. The context will not be evaluated until you plug it to a Data Flow node (term used in the blog post to refer to nodes with actual Geometry data).
This allows some interesting connections like you can plug the same “Position” node to two different geometries and they will evaluate their own position attributes on their own, resulting a more flexible way of working with nodes.
carry a “field” (the naming is of course open to debate, but I’ll stick to that for now).
I agree that field is not quite exact term for that.
Usually, in different software a field is a part of text, that changes its value according to some parameter.
Here they look more like “metavalues” - a value which type is evaluated on demand.
There is a certain difference between “something that can be used in production” and a “production-ready” terms.
If you can use some piece of code for something useful, it does not mean that it reached an appropriate core-level quality, since it is incredibly hard to make working but completely useless code.
The requirements of such a bar is too low.
Remember, that production is a business, not a couple of local concept-proving projects made by enthusiasts.
Business takes financial risks, and a “production ready” level assumes that business can trust tools to take an appropriate level of a production risks.
Thats why there are no production ready tools that are in active state of a development, since it assumes the possibility of a cardinal changes, which are deadly for any business.
No there’s no difference at all. If it can be used in a production it by definition IS production ready. Also, stop pretending you’re the only professional that uses blender. I’ve been doing this professionally for 30 years.
“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.
