I actually personally used it in production, even if only a subset of nodes. It was great but while I do agree that bad decision were taken, I don’t mind relearn any new paradigm, if it will bring to a usable, maintainable and scalable toolset with good foundations.
Probably this first iteration has been necessary to test and figure out the limitations of the node system and have a base to make a better one. If it was any other software, the users would probably be able to test the new feature when it would be too late to change the foundations.
So I don’t know if this possible design change is due to poor planning or I’s just how it is supposed to go, but I hope it will be better planned in the future.
I used the software that starts its name with H, honestly, I’m not saying that devs should copy other software , but at least take a look on how other software work to take inspiration and do even better. I hope they already do!
Also used them in production here! The tools that are available are definitely robust and production ready. The issue is only really around scalability and expanding into the other desired workflows outside of scattering.
Hi, please let’s keep the discussion focused on the proposal. I mentioned in the proposal that backward compatibility should be supported if possible. There is no need to digress further.
Geometry nodes have already been used for professional projects, including for some big name clients. In the worst-worst case scenario artists can stick to 2.93 LTS for 2 years until having to worry about that.
Great proposal with the latest examples! Im only missing an “interpolation method” dropdown (or something similar) in the set attribute node and the nodes that interpolates new geo (subdivide, resample). If the attribute list and the geometry doesnt have the same amount of data, we could control a bit better the data flow in our geometry.
ie: If i subdivide a line, but previously i created a boolean “tip” attribute in it when it was only 2 points, i will loss that “selection” if i have no control over how the attributes are mapped again to the geometry.
Thanks for all what you are doing! You are creating something so powerfull…
A little thing i did yesterday trunk+roots. Its much much faster, but you know, remesh and eevee
GN, as any generative tool, is also limited with creative/artwork design workflows by its scope.
Artwork is indefinite by its nature, to create decent artwork you can use whatever generative tool (GN, Sverchok, Grasshopper, Dynamo), you can to not to use computer at all (there are a lot of known cases), so there is always “you can use”, but there is never “you have to use”.
Artwork tools can be evolved infinitely in infinitely many ways - no matter how much artwork is improved, there will be always a space for even more improvements.
So all of them are always just proof of concepts, that are formalized at some point.
There is no bedrock here.
Just as Sverchok was developed, collecting all possible concepts and realizations in order to reconcile and redesign them later, when the critical mass was reached.
That strategy works for addons.
However, I would like to ask @dfelinto , from a user and training maker POV, how much will be lost with the future direction of the Geometry Nodes. I’m afraid of creating training if the workflow can or will change in the near future. Can you give a clear statement about how the currect knowledge will translate to Geometry Nodes 2.0?
Oh, right, yeah. I almost forgot they are in 2.93 given how primitive state they are in. I am still perplexed they were actually called production ready in 2.92
I hope that the new version will make it easier for me to track and define attributes. There are too many nodes and too confusing. Once more than 30 nodes find and modify the node tree is a huge problem (even if the frame is added, how uncomfortable it is when I try to overlap 2 frames)
In my opinion, both methods are good (although they have something common). The design of field reduces the difficulty of people tracking attributes, and the scheme of getting atttribute makes certain things clearer. I think we need to do the subtraction first, and then do the addition.
The essence of the node tree is to make things simpler rather than more complicated. I prefer the attribute processor because it separates two different levels of things（It is a best design first , a simliar design to Hou’s design second）. For most users who do not have a programming mindset, this seems easier to understand. When I am at level a, I don’t need to worry about things at level b (I don’t need to spend more energy to remember what attributes I put in place)
It’s starting to get really demotivating to read for the N’th time, that benchmark for the GN production readiness is something as trivial and as arbitrary as a non-commercial studio which the workflow has been tailored specifically to using it on one non commercial project, and one no name studio having used it for an indie student level short movie.
Instead of admitting that calling GN production ready in 2.9x versions was a mistake, doubling down on it with phrases like “This is the definition of production-ready I’m abiding to.”
It shows significant level of detachment from what the real, high end production scenarios require. After all, if it was really the case and GN was production ready, we would not have to read posts about “Disruptive Changes” and juggle between two significant overhaul proposals, both of which fundamentally change how already supposedly “production ready” geometry nodes work.
I’d say majority of us are unhappy with the current state of GN, but we are happy about its future potential. That’s what keeps the atmosphere positive. Hearing that GN are already considered production ready completely wrecks that positivity because it sounds like goes against the idea of significant changes geometry nodes need to actually become production ready.
Simmer down, it’s only a matter of semantics… I never saw Dalai or anyone else wave away feedback from users who stress-tested the system harder than the Blender Studio did, quite the opposite in fact. Maybe “production-driven” would be more accurate ? but then again I don’t see how calling it this or that is an actual problem.
