Everything nodes


(Hadriscus) #104

This is mighty interesting ! :]
At some point it sounds a bit like what the depsgraph does doesn’t it ? Take it from a noob, I don’t know what I’m talking about. :slight_smile: However you seem to have thought this through and it’s nice to see things are advancing. Do you think that intermediate representation would be human-readable ? Would there be a “script” node ? (thinking of the “wrangle” node in Houdini which allows writing VEX code to modify geometry, attributes, etc)
I’m also all for having different node frontends/contexts so that the purpose is clearly defined but there should be easy ways to get data from other contexts (say you need a pose bone transform or a specific polygon normal from within the particle context, you should be able to import that and use it).

Godspeed Jacques !


Btw are you just doing the groundwork or are you starting on the procedural modeling front ? Or something else ?

(Jacques Lucke) #105

A node system basically represent a (localized) depsgraph already.
However it is important to get all external dependencies from a function so that it can be used in Blender’s depsgraph. So that e.g. when an object moves, all the right functions are reevaluated.

The intermediate representation is a node graph as well. There will most likely be a .dot exporter for debugging purposes. Users usually should not have to care about there being an intermediate representation.

I’m pretty sure that there will be some kind of script node. However, it is still unclear how that will look like in the end.

I’m mostly doing the groundwork for now like setting up the basic code architecture.
At the same time I’ll start developing small nodes just to test the system.
Over time I’ll just add more different kinds of nodes and data types.
Modifiers/procedual modelling will probably be the main direction to explore first.

(Joel_nl) #106

Awesome to see more information on this project, thanks!
In regrads to the future of this project; particles. Do you have any idea if this would mean a re0write of the current particle system so it’s purely based on nodes, or would you adapt the current system to fit it into a node system? I’m wondering the same in regrads to Physics.

(Jacques Lucke) #107

I do have some ideas for particles and physics, but I need more time to test them in practice.
One goal of this “generic functions” project is to implement a lot of the code that is necessary anyway without making big assumptions about how everything will work in the end.
That does not mean that I have no ideas for how things can work in the end. One step at a time.

(sundialsvc4) #108

The thing that excites me about nodes, as a generalized concept, is how it ties-together pieces of (Python and/or C) source-code … visually. In particular, it describes the flow of information and events in such a way that a “generic node-runner” layer of software within Blender can dispatch events using it. (The nodes themselves don’t have to specifically be concerned about how-when-and-why they will be invoked by the system, nor exactly where the information comes from or where it goes. Meanwhile, the dispatcher doesn’t have to specifically be concerned with what each node is doing.)

This reminds me very much of the “RAD = Rapid Application Development” systems which very quickly appeared after the Macintosh and Windows “GUI” systems first appeared. (Koff, koff … “these ‘kids’ today” …) There were many successful experiments, not only in constructing the user interface elements (forms, reports, and such) pure-visually, but also with describing the underlying logic, particularly “visual [SQL] database-query builders.” Many developers today, in those areas, couldn’t imagine not doing things this way.

These RAD systems work by pre-supposing a layer of “generic” software foundations, which can then be “customized” to build a unique deliverable – quickly. Well then, in an easy but not-exact analogy, “so does ‘nodes.’” That’s what makes the principle so powerful, and universal.

And so it was that a [very experienced] developer was, in the OP video, able to create new features and to get them working within the Blender environment “in a matter of a few days.” The developer could concentrate on implementing one node-type at a time, using existing infrastructure to link them together, to create a new feature which could be deployed as a plug-in and subsequently installed by any Blender user. Blender exposes the same metaphors for anyone to use in this way. That’s huge.

(noki paike) #109

reading your notes I can think of a system that evolves fractally …
from a generic basis, the “nodes” added, build a more specific branching … something like neural systems that then go to build the various specific tools and different types of functionality …
and then from this little by little all the existing tools will be converted to the new system …
… will be something very interesting to see evolve :)))

(Funny1048) #110

would it be possible to increase the svm stack limit with everything nodes because when I created a complicated procedural node based material I hit the svm stack limit

(SynaGl0w) #111

They will probably say no again, but on that note…

How about a display in menu bar showing how much stack space is used by the current material:

  • SVM Stack: 47 / 256

(Ace Dragon) #112

The commit logs recently showed code from a new “functions” branch that appears to be related to the Everything Nodes project.

As usual, no one should try to play with it until the developers give the all clear.

(Hadriscus) #113

Hah ! This is the start of something great. Looks like Jacques is starting very low-level, very abstract-y, to build a base for all the node systems to come (so I understand).

(dimitribastos) #114

At this point, I hope the design of the everything nodes system to be easier than Animation Nodes, which is very mathematical.

(Thinking Polygons) #115

I wouldn’t hold my breath. For this to happen, the design of this system would need to be made by non-devs, which is not the case.

Animation nodes has a lot of potential, but unfortunately it’s not artist friendly, it almost feels like true programming if you campare it to something like c4d’s mograph/xpresso.

(drgci) #116

agree, animation node is pain in the ass its in the opposite direction ,far from artist friendly

(dimitribastos) #117

I don’t know. After the 2.8 design, I think the team is focusing on easy to use tools.

(Ace Dragon) #118

More puzzle pieces are falling into place.

Node to functions converter.

Actual nodes.

It looks like things will get pretty interesting in the next couple of months.

(BlackRainbow) #119

Just one word - Houdini. Used in every single film with vfx nowadays. Not very artist friendly.

(Lumpengnom) #120

What is the difference to C4Ds Mograph/Expresso? I´ve never used it.

(zeauro) #121

Who would say that Cycles or EEVEE material creations are not artist friendly with there principled shaders ?
A node system will not stop community to provide nodegroups that could act like principled nodes.
It does not imply so much maths.
It is a little bit ridiculous to explain that dealing with addition, subtraction, multiplication, …etc : it is artist friendly for painting blend modes of layers but it is not for locations,vectors defined by nodes .

(Lumpengnom) #122

The alternative are systems like drivers which are fine for simple stuff but as soon as it gets a bit more complex nodes are a lot more useful.

(Jacques Lucke) #123

It is true that the flexibility of node systems often come at the cost of ease of use. I’m aware of this and Ton likes to remind me of that :smiley:

I agree that high level nodes that just work like current modifiers are very important and make the node system easier to use than e.g. Animation Nodes. If you’ve followed the progress of AN, you’ll know that it got more and more “high level”, meaning that you can do more with less nodes. The same will be true for what I’m currently working on. I hope that I can skip some steps, because I know better what I’m doing compared to when I was developing AN.

The problem is that one has to start with something. And developing a framework for nodes is easier when nodes are simple in the beginning, otherwise I just spent all the time developing and fixing nodes and there is not even a good system that can execute them.

High level nodes + the ability to manipulate stuff directly in the viewport are key ingredients to make node systems more artists friendly. We will have both eventually.

One thing that makes AN relatively hard to use that there is no clear output. Therefore you always start with a blank node tree and it is hard to get started. This will be different in the new system. There should always be an output node that you can connect stuff to and see things change, even if you don’t know what you are doing.