Oh, nonono, what I said is that I hoped it could be faster, what I said now is that I actually tried it finally and my findings about it, but don’t worry, I won’t mention it again
Ok, understood, seems logical, just knowing that you have that in mind is enough.
Not at all, that’s why I have a lot of confidence that you will achieve an awesome system in the end, and you know that I love AN.
I also think that many situations present in production cannot be imagined without having a wide background in particle and fx productions, and AFAIK (and with all respect, and correct me if I’m wrong, this may sound a bit hars but i don’t want it to be, it’s just that I don’t know how to say it more softly) you don’t have that background in fx production where a high amount of detail is required.
You are not alone, I include myself in that group up to some point too, while I have exprience I have not done any Game of Thrones shot, in fact, not many Blender users have that kind of experience specially because it was not something that could be done in Blender easily.
I have confidence in that it will be possible in the near future (2.83 maybe? hehe)
Of course I understand not everything is implemented it’s just that I understood a different thing with the declarative way, and even after your explanation I’m not entirely sure I fully understand the final way of doing complex systems but with this:
The design implementation and execution of Softimage’s ICE Tree system was years ahead of its time, and there are probably several things that could be adapted from that system into the Particle Nodes overhaul. The basis for any successful project like this is good background research, and I think you would be hard pressed to find a more apt example of a good node system, than ICE Trees. I emphasize good, as the ICE Tree system was the killer feature for Softimage, and is what set that software package apart from the rest of the pack 5-10 years ago. At very least, I’d at least like to see some of the ICE components considered in any future proposals, even if they aren’t adopted.
I checked a couple of videos about Softimage’s ICE, but my understanding of it is still fairly superficially.
If you know ICE better, please point me at specific concepts that I should consider.
off-topic,
I had a stupid idea
I don’t think if it is possible, but it will be nice if there will be a node similar to Particle Condition with Condition(e.x. named split) as float that would split particles into two particle groups. In this example if set to 0.4 it should kill 40% of particles and change the rest to a direction. Maybe it can be done with an action node to move some particles from a particle type to another particle type.
p.s. it can also be done with an influence in Age Reached event.
Sure! The Node Tree is almost the same as last time, just with a couple more nodes in the “preliminary forces” section
(TonR: removed image, mot allowed to share screenshots of commercial apps here)
I’m no houdini genius, but this was a simple way I got this to work. its happens in 3 steps.
Pop Collision Behavior
Pop Group
Pop Force
Pop just stands for “Particle OPeration”, and doesn’t really matter. The explanation goes like this:
The Collision Behavior node has a set of built in responses, I chose “stop”, which sets the particles velocity to 0 if it collides with something.
The PopGroup node groups particles, just like vertex groups. This node usually brings everything above it into a group (even dead particles can be stored), but it also has an area where you can use an expression to group things. Essentially I’ve told it to group every particle with a velocity of 0 into a group which I called “0Vel”.
Finally, in PopForce, I give it a force of my choice. The trick is this node allows for groups. In other words, I tell it the node to only apply this force on the group “0Vel”.
Done. Now, I’m not sure if this is the best way in houdini to do this, I feel like maybe using a “switch” node could do the same, regardless maybe this could help? This might be overcomplicated for what we would plan in blender, especially with a PopGroup node with an optional expression box…However, I feel like this could all be simplified into a general “Particle Event” node. These nodes might already be close to achieving this:
The node at the very top is a particle type name - just a string I guess. What I was trying to get at is that if the “Particle Type” node is inside a node group, then you would want to be able to have a way to have its name be an input, so that the node group would be reusable.
I have played around with the functions branch several times and had a query. Was wondering why the main node is called “particle type” and not “particle group”?
Maybe I am missing something, but are these not particle group nodes allowing several emitters to act as a group? Maybe there is a plan to group several of these “type” nodes into groups?
Over here all the particles that are created from the mesh emitter are colored blue, and once their age reaches 3, they are colored green and explode. This makes it super easy to see what is happening, debugging etc. It can also be used in the final render for the desired color perhaps.
Maybe we should start a “Particle Node Ideas” thread for this kind of stuff? What do you think?
In general, I am quite skeptical of the new proposal. It partially defeats the purpose of having node based system at all. There are number of other 3D packages, which have successfully implemented node based particle systems without the node tree growth issues this proposal: https://wiki.blender.org/wiki/Source/Nodes/UpdatedParticleNodesUI is trying to address. I’d rather refer to how they have done it instead of watering down proper node based workflow with tons of dropdowns and buttons.
Houdini and Blackmagic Fusion both do node based particles really well.
Thank you very much, that is good information.
Yes, we could easily have an action that puts particles in a group, and a force only affects particles in a certain group. It might even be more obvious what is happening just by looking at the node tree.
This node does exist already. It’s the Change Particle Color node (yeah, we need better names^^). To change the color directly after the particle has been emitted, you have to connect it to the “On Birth” output in the emitter.
@jacqueslucke Maybe a little bit off topic, but will you build solvers (grain, fluid, cloth etc.) from scratch?
Or does it make sense to use existing ones for inspiration. In Houdini for example, all solvers and how they work, are more or less easy to discover when diving into a popsolver node. Solvers there are build from other nodes and some vex code.
I am glad that you mention being able to create a behaviour with data from the previous timestep : I think that’s important to have that kind of control.
Right now, is there a way to control assignment of custom attributes to particles (either on event… or linearly) ? eg size, color, rotation, etc. the user might want to trigger those things in arbitrary and intricate ways.
Secondly is there a way for the user to make their own events ? Say once a particle reaches a certain position in space, or when they enter a volume, etc. basically put a variable ‘under watch’ and flip a switch when it reaches an arbitrary value.
I strongly like I idea of going a approach similar to nuke (or houndi which looks similar). They both seem to have the flow: object to emit/particles -> particle emitter -> forces -> particle output. I like this as to start a simple particle effect you just need a particle emitter and the output. Then you can add inputs to the emitter such as objects or other particle systems and effect the output of it with forces.
This sort of flow seem quite natural.
I would also be interested in some sort of particle add node which nuke has.
Reading through the " Updated Particle Nodes UI" wiki page … i"m wondering, is node tree growth really a problem? I work with Nuke on daily basis since several years (together with many many artists in several companies) and i never heard anyone complain about “node tree growth”.
Complexity, yes, that’s a problem. But removing links doesn’t solve that.
Grouping helps.
I see what you mean, but I’m not sure I agree. These particles system trees are more like materials, in the sense that materials can be attached to many objects and are shown under the object data of an object. Houdini shows it it in the object that it’s attached to, and Cinema4D quickly shows a particle icon beside the object and has it, once again, below the object. My opinion is we should just add a particle system icon beside the mesh data icon and modifier icon, and then have it below in the modifiers drop down as well, like usual.
And here is Houdini for reference:
It just seems weird to make it have it’s own slot in the outliner, like it is it’s own object. But perhaps we could have a different section in the outliner for Graph Trees?
