Isn’t the concept of a Directed Acyclic Graph violated with the position of the influences? Shouldn’t the particle system flow through a series of influences?
It could be that an influence is treated as an input value, which would keep the position in the DAG correct, but an influence feels more akin to a blur applied to an image buffer for example.
Hi,
I just read through the UI concepts overview and, noticed some similarities between this conceptual structure and, Notch’s approach to describing particle systems. The conventions of Blender’s node graph means that it has to be left to right instead of right to left but, the concept of the particle root/endpoint with emitters and affectors/influencers seems essentially identical.
The action concept is novel and, I’m interested in playing with an implementation of this.
I’m curious if real-time and interactive applications are being considered as something that this new particle system might be used for.
The core concepts seems really nice !
I’ve been trying to test all that but I seem to fail for some reason, after setting up a very basic tree with just a mesh emiter on a plane and a gravity node, both influencing a particle system node.
I then apply a Bparticles modifier with the correct particle system linked to the plane but then the mesh of the plan disapear and all is left is a single vertex in the center of the viewport, tested and same for any other primitives than a plane, giving the Bparticles modifier to any object seems to make the object disappear, and when I click on play nothing happens.
What am I doing wrong ? some help would be much appreciated.
(I’m using the lastest available functions branch build of sept27)
EDIT : Fixed =)
I’ve been playing a bit with particles nodes and i like how straigh forward it is, and imo it can have a more intuitive ui for exemple why the particles system does not have an output ?
@lvxejay Emitters and forces run entirely in parallel, I don’t see how it makes sense to order them in any way. Most events are also ordered precisely. Only when two events happen at the exact same time, we might need more control.
@troy_s No need to ask me the same question in two public places at the same time.
@flowb I didn’t check Notch before actually. I agree, there are some similarities.
I think the presented core concepts could work with interactive applications as well. That won’t be the primary focus for now though.
@Nago I’m not sure what is wrong. Please contact me in blender.chat and send me your file so that I can have a look.
@NizarAmous There are a couple of benefits of having no output in the Particle System node. For example, it forces the node to be at the end of the tree, where it can be found more easily. People actually requested having something like an “output” node before. It is easier to define node groups with the current solution. Furthermore, while not particularly useful in most cases, it can be useful to connect both Particle System outputs to the same Particle System.
if the particles system is in a subgraph yes, but, imagine if i need to instance a sphere on a particles system, if the system doesn’t have an output how do we do that ?
here’s how we can do that in houdini
in the screenshot there’s 4 windows, the 3d viewport and 3 views of the network,
In the middle network you can see that we are instancing a sphere on the result of a particles system that’s emitting from a cube ( box ), and if i had another particles system that generate a trail of the first one, i could instance a cube on the first system and instance another object let’s say a torus on the second one and merge them to have 1 output from that object.
I’m just wondering how is it going to be with everything node & particles nodes to do those simple setups
The particle node tree is conceptually similar to the Particle Network in the image. Just with possibly multiple outputs (I guess houdini supports that as well?). The thing in the middle is more like modifier nodes and works on a separate level. You can instance spheres on particles already, by using a temporary solution I implemented some time ago: the BParticles Output modifier. It allows you to access the particle data of individual particle systems. Then just use normal object instancing.
This is of course not an optimal solution, but the best I could implement for now given the limitations of the modifier stack.
I don’t think houdini does actually, or at least technically. You can use a switch node to jump between node setups right before the output node, but technically you can only have one output, as far as I know. It allows multiple inputs, but that is just so that you can have multiple objects interacting called into the particle node, which we already can achieve with “mesh emmitter”.
I don’t want to sound hard, but wouldn’t it be a good idea to check houdini for yourself so you can see in general how things were done by the program that works best with nodes?
If the objective is to have a good interface, UX, functionalities… the best thing would be to contrast ideas with a program like that and see how they faced the same problems. More when this in the long run will lead to everything nodes.
We can tell you things, but in the end the decisions are always yours, so I think it would be best if the experience of using another program had you too.
Pretty sure that’s not OK. Not that @jacqueslucke is trying to reverse engineer any of these other solutions, but I recon a lot of this still applies:
No one is asking Jacques to copy anything and then go to a lawyer to see if everything is legal.
I’m telling him to check other ways of working and ideas because it will be beneficial. Not that I copy houdini.
USING A PROGRAM IS NOT COPYING IT
it’s to analyse a design of another program so he can use as an example or as a counter example, as i find Bparticles much more intuitive and easy to use than houdini, and i’m just showing houdini to illustrate what i have in mind
@jacqueslucke i couldn’t get the color node to work, am i doing something wrong ?
It’s a bit hidden currently. The color is written into a vertex color called “Color”. So in the shader editor you have to use an Attribute node to access this data (note, you cannot use the Vertex Color node currently).
Hello again,
so i got the colors to work
but i can’t shade as i like in bparticles ( limited nodes ) and i can’t neither in cycles because i can’t export attributes as i like and the particles info node is not supported yet,
i guess the futur workflow is :
Anyway i have a question
The “Size Over Time” node is a very specific thing indeed. I implemented it just to make a point in a discussion of how this could work in the future 
The Node is not doing exactly what your node setup does, but it is close.
My current plan is to have a “Derived Attribute” node.
It is more generic than the Size Over Time node, but also more specific than the Always Execute node. Being more specific helps the Uber Solver to decide what to do.
There is a mockup of this node in the version you are using (it is not working). To see it, open the N sidebar in the bparticles node editor. Then go to the Node tab and open the Tree panel. Inside you can activate “Show Mockups”. Then use Ctrl+A and search for “Mockup”.
Maybe a silly question, but where can I find a build for this, so I can have a look at it 
It’s currently in the “functions” branch: https://builder.blender.org/download/branches/
Cheers! Something to play with this weekend 
It’s great to see how the development progresses! Hope to see some more short videos with different cases of particles maybe more on the VFX side
