Pablo and Dalai discuss/demo it in this stream (starts ~26:40):
I hope the Open Movie artists tell the devs. that they will have high standards in areas like usability and power. Far too often I think they are willing to work around shortfalls in the initial implementation of features in order to make it easier for the dev. team. In short. the massive funding the BF now has by FOSS standards should be seen as a sign that they can think bigger on their requests.
On the list of initial use cases, the tree bark generation looks interesting to say the least, such a material can be hard to perfect even in the various texture authoring packages, and there are a lot of scene ideas that can make use of trees.
I actually cant say what the scope of the project is. It a particle system with nodes for modelling and so…
I hope they can tackle after that or when the basics are there the new rigid body system so the fracture modifier can be implemented… Because they dont have to do all the nodes that can be anyone really when the system is good.
I understand why they’re keeping trees as handmade assets and only aim at procedurally generating the bark, but I would love to see entirely procedural trees with leaves.
This allready looks fantastic.
Modifiers are cumbersome to use and coupling them with drivers is an annoying hassle and not very transparent wheras nodes are a lot clearer to read.
“Stacks” or “layers” are just a very limited concept in general, imo.
The scope of this looks terribly limited. It will probably turn into another half-assed, incomplete feature when they promptly abandon it a little while after the movie’s done. I mean, I hope it doesn’t, but it’s the way these things go.
It’s usually a bad sign when they pick a goal that is too ambitious, but I think this time they’ve overcorrected the other way.
Heh, yeah, that has happened before. But has this happened after the big moneyz came in?
The money is really not that big at all, but to answer your question, yes, see VR support. Peter Kim is the only one still doing anything in that department, on a volunteer basis AFAIK.
Same. Animation nodes are not a “one blender film” project.
What concerns me even more is that when I looked at discussions on fixing existing issues with current blender constraints the argument was made that not too much work should be put into the current system since animation nodes are going to replace it eventually.
…
I just hope I’m overly cynical and ill be proven wrong.
Well, compared to what they had before it is enormous. So perhaps there the available resources make a sufficient difference.
Regarding VR: I think it is going as planned. They implemented a framework and a basic implementation and left the rest to volunteers.
Making particles nodes or procedural modeling nodes may offer a vast new territory to play with.
With simulation nodes, they really were trying to expand Blender capabilities and introducing something new.
Resulting issue is that a developer may pass a long time in an abstract new field where most of users won’t go.
So, the idea of making an open movie is to bound imagination of developers to expectations of a common production, to validate basis that would really be employed by everybody.
So, geometry nodes are not supposed to be a fully functional new system but just the first milestone.
At least, geometry nodes should be able to deliver basic set dressing, basic procedural modeling, basic fluids and particles simulation.
And then, from this basis, system should grow.
And it should grow quickly.
The blog article is not just an announcement of what is the plan.
It is also a call for contributions from volunteer developers ( like the one that was successfully done to accomplish Copy On Write tasks and multi-object editing tasks during 2.8 codequest).
That’s a pretty crappy plan if you ask me.
Really ? it actually ticks so much from my wishlist !
- flexible data types (conversion within the nodetree from and to mesh, volume, etc)
- static scattering (pebbles)
- dynamic scattering / particles (snails)
- procedural modeling (tree bark)
- fluid simulation integration
Hmm… not sure about that. The way I understand it is that they did the heavy lifting which is implementing the basics and leave the easier things to volunteers.
The nodes equivalent would be to do the heavy lifting by implenting the nodes sytem and necessary nodes but leave creating easier or more high level nodes to the community.
I mean, it’s nice if you really want to scatter stuff I guess. When you hear Geometry Nodes, you expect it to be useful for so much more though. Like someone else mentioned, they’re not even generating the trees, just the bark, which is sort of hilarious. And even that’s a maybe.
Like they’ve left baking antialiasing and grouping support to the community? Yeah, there’s Bake Wrangler and Group Pro that will give you those features, but they’re weak implementations with no guarantee that they’ll be supported a year from now.
The particle system needed an overhaul for a very long time. That is not an “abstract new field”. Particle nodes would be immensely useful and people were waiting for it.
We have seen examples such as basic fireworks which, while not very advanced, are not possible right now with blender’s particle system and would be a practical example that would be of value to both old and new users.
But I bet the people salivating for a decent particle system are super happy that code was scrapped to focus on “scattering”. While being able to solve that with nodes IS a good thing its not like there weren’t other options available for it. There are plenty of powerful scatter addons for blender.
Are there alternatives to the limitations for blenders current particle system?
I am certain new insights were gathered that required a new (and hopefully better) approach to nodes but lets not pretend particle nodes were not an incredible useful and desired feature.
I hope not, as I assume that nodes will have to be implented in C not as python nodes.
I believe I said that ? anyway, it’s procedural modeling all the same. I’m not surprised since they’re working within the constraints of a film production.
What do you mean by grouping support ?
I am one of the salivaters but I’d rather wait longer and have a system that is decently implemented with the other nodes systems suchas geometry nodes than have a bunch of separate systems that don’t work together as good as they could.
It was pretty heartbreaking to see that particle nodes got postponed, though.
It was not scrapped, though. And a bunch of the code was used in geometry nodes.