Everything nodes

Please also read and preferably discuss in https://devtalk.blender.org/t/particle-nodes-ui/8808/.

I actually agree that it is less intuitive to have the actions plugged into the influences from the left. In fact, my first proposals worked like that (they are linked from the first post in the linked thread). Even more, I actually argued that it should work like that quite strongly (see https://devtalk.blender.org/t/particle-nodes-ui/8808/71).
Unfortunately, there were serious issues with this approach that are explained in the second proposal.

Since then I was looking for a solution that solves these issues. The current solution came from user feedback as well as from looking at how this is solved in Softimage ICE. After some thinking I decided to use the solution I’m using now (having the action nodes in the left side of influences). That really was not an easy decision, because I used to think the same way you are thinking now.
It was a trade off. In the end I valued more powerful node groups and a more structured node tree higher than the initial intuitiveness of the system.
Fortunately, after working with the system a bit, the mind adapts quite quickly to this approach.

@lsscpp This could be done relatively easily, but I’m not sure if it should be done. For now I think it should just be a single input. I actually like that this is the only socket that allows multiple inputs because 1) it signals that this socket type is very different from the others (and it is!) and 2) the influences do not have a natural ordering. I prefer not to present an order to the user if there is none.
Fortunately, if I change my mind, I can update it quite easily later on.


^ ^ This please!

I understood the original influence for this way way back, was the Softimage ICE node structure.
With ICE, you can have multiple inputs, which are evaluated top down. There’s also Particle States, but that a different discussion. :wink:

For someone who want to read up on how this works in Softimage look here:

I know Blender is different in a lot of ways, but a lot of workflow can easily be ported to Blender imho.
ICE was very accessible to users, as it laid on top of the regular workflow.


Edit: missed Luke’s answer :smiley:

Edit 2: As a particle based system within a 3D application, I think ICE is still king.
Houdini’s way of working with ‘everything nodes’ is overkill for a lot of users, and even the presets they provide are often too technical.
Maya’s new BiFrost system is heavily based on the ICE paradigms, and done by one of the old core devs on the ICE system, and the now dead Fabric Engine system. It shows, especially workflow wise.

The way ICE works, with clear color coding, specialized nodes, splitting of tasks and input flow are imho a thing to be seriously looked at. But I’m not a programmer… so… :wink:

1 Like

OK, thanks for clarifying.
That is a bit strange by just looking at it, but I think I can adept to it.
I guess I just have to play with it a bit when I have time.

@Jacques_Lucke: Is there going to be sth. like a way of ‘instancing’ (for the lack of a better word) one particle system on the particles of another (so to speak)?
Let me try to explain what I mean here with an example:
A while ago, I tried to find a workflow to make a bird’s feathers via a brute force geo-only approach (read: shader-agnostic and clearly without alphamapping whatsoever). I got mixed results using the tools available in 2.79.
Making a single feather is rather straightforward. You basically need an elongated emitter along the feather’s shaft and place many (hair-) particles one-by-one along it (manual placement and grooming/trimming in particle-edit-mode is the only way of getting enough precise control over length and direction here).
Then you can use a particle-instance modifier to get some properly renderable geometry for the filaments growing out of the shaft.
The real problem is placing those feathers in a controllable and effective way to make a bird. Stacking up several particle-instance modifiers using different particle systems (one on sub-feather-level as outlined above and one to instance the feathers onto the bird) doesn’t work in practice and leaves you with weirdly deformed, ‘broken’ feathers.
So on a small scale you can make it kinda work via workarounds like using curve-deform on a per-feather-level or applying the sub-feather-level particle-instance modifier:

In any case, I was wondering how such a case could get handled the upcoming particle-nodes. Though I suppose this specific case might play into stuff only planned for later stages of development (like modifier-nodes maybe or an overhaul of the hair-system, which I believe to understand is not part of the current particle-nodes project).

greetings, Kologe


Hi, I’m not into other nodes than the shader ones. I wanted to dig into something that involved nodes, just for the sake of learning for now, since I want to learn all the node available for blender at the moment at some point.

I have some questions…
Everything nodes is the same as the functions branch, which for now is just particles?
Animation nodes is a addon by the same developer, but nothing from that is on the functions branch either?
I’ve also seen there’s Sverchok nodes which might overlap in some cases with AN, is there any other node addon that has escaped from my radar? Seems like Sverchok might have some functions that could be very similar to the future modifier nodes.

There’s also Sorcar - Sorcar (formerly ProcGenMod) - Procedural modeling in Blender using Node Editor

SceneCity also has its own nodes. As does modular tree


Wow, Sorcar looks super easy judging by those node names.
I didn’t think about more specific node based addons, but thanks for those as well, I had seen modular tree before and it looks very nice too.

1 Like

Wow, Sorcar totally slipped my attention. Thanks for pointing it out!

1 Like

An interesting bit from the devtalk forum for those who don’t follow that thread:

My question for Jacques:

I remember you saying somewhere that particle collisions are not a near future goal, but how about a per-particle force that affects other particles, but only in a given radius? So that although the particles wouldn’t be “colliding” per se, they’d still sort of repel/attract each other inside the radius. It’d be immensely useful.

Jacques’ response:

Yes, I think implementing a per particle force so that particles repel each other is very useful, and should be comparatively easy to implement. I’ve never actually tested this though, so I’m not sure if it really works the way we want it to work.

Can we have realtime displacment for procedeual material creation.

And a cavity node please.

1 Like

That is more of a job for Cycles and Eevee nodes (and Eevee development in general), the current project related to Everything Nodes concerns revamping the particle system.

1 Like

A cavity node is relevant to particle generation too:


I fully concur - this sort of info/data needs to be easily obtained by the user, feed and understood by the particle system (along with few more physical properties like collision detection, camera/eye frustum, proxy mechanism, LOD…)

That makes sense if the purpose is a particle/instance distribution scheme.

Still wondering about the realtime displacement, I’m drawing a blank as to how a version for particles would work.

1 Like

Well, he mentioned it would be for procedural material development. Using displacement nodes in cycles is alright, but you still have a fair bit of latency when you are adjusting the nodes. Think of it as extending the modifier stack for creating geometry.

1 Like

How do we change the colour of tetrahedrons for trails particles?
setting material applies to all particles… :slightly_frowning_face:

i did this a month ago or so, i remember that i couldn’t have one color output for the first p.system and another output for the second p.system


Thanks a lot !!

Testing the new particle nodes:

Node setup:

edit: accidentally replied to SumitShekhar instead of the thread… well, doesn’t really matter :upside_down_face:


today Brecht created a Task for new volume object type :

i hope that this is related to the fact that jacques and sebass are working on how to have mantaflow nodes