Thanks.
I guess fireworks serve as a good example.
I would like to know how to make the complex fireworks around 2:40~3:00.
For example,
at 2:56 seems like a tough task.
2 Likes
Firework was actually the first demo I created last year already, when I wasn’t even working on it officially. See https://www.youtube.com/watch?v=HQi2BqlQtnI.
Obviously this is not as complex as the one in the video, but I feel like it is fairly easy to imagine how a more powerful Explode node can make this kind of stuff fairly easy.
1 Like
I believe the most difficult part of doing fireworks with the proposed designs is to interpolate the color change throw frame time(maybe I missed something).
I actually thought about this issue for quite some time already (generally interpolating particle attribute attributes over time). The main issue is that particles do not have a lifetime by default (which would be necessary to interpolate values over the lifetime). I have three possible approaches (all of which will probably be implemented at some point).
- Access the particle age in a shader and compute the final color there.
- Have a node like “Color over Time” that has a color ramp and an end-time input. The node could also trigger an action when the time is up.
- Do what is done in ICE. There you have to set the Age Limit for particles explicitly, and then you can interpolate attributes with it.
8 Likes
Yes, I do remember watching the video, and the excitement watching it.
If you have the image for some of the complex fireworks, it would be a great help to have it in the proposal. I mean, it’s quite difficult for me to imagine it. (Pardon me if I sound offensive)
1 Like
Speaking of other test cases, there should be one each from other common use cases (Smoke, Fire, Splash, Hair, Explosion, Game Effects)
I have a very limited experience in particles and hope somebody else could provide test cases.
My doubts are about how will work with other particle system like fragments of other objects to make destruction effects? With complex system like particles picking the shape of a character,…
2 Likes
The most basic firework would look something like this:
All the individual nodes might change of course. Here is how it works:
There are two particle types: Main and Secondary. The main particles are created using a mesh emitter. The source object is a ground plane. When the main particles reach a certain age they (1) explode and (2) die. The newly created particles are of the second type. When they reach a certain age, they will die as well.
The marked words map to the nodes in the image.
4 Likes
In the beginning it will not be able to do that. However, I do not see why this should not be possible in the long run with this design. I think it is extremely flexible, because it is declarative at the highest level. I’m not able to tell you how all these things will work exactly in the end, though.
We might also need different kinds of “Type”/“Output” nodes later on. Which ones? I don’t know.
Thanks for the example. That’s a great help!
I actually meant that I was interested in how the details are expressed in this particle system, like the light flickering, the physics changing from Newtonian to Boids, controlling the shape with images…
But maybe its too early to discuss them at second thought.
Thanks anyway.
Could not be better change the output node name to “solver”. And in the case that needs in the future new solvers change the name to “fluids/breakable/… solver”?
2 Likes
Maybe, have to think about the implications of that change.
I would absolutely love that! Even though that might make things a lot bigger than what Jacques may have initially planned, it really opens things up to a whole new level! Why stop at just particle behavior when we could also get rigidbody/particle-liquid/smoke. Who knows~
I will not call it solver for now, because:
- It would mean that different particle types are simulated by different solvers, which is not necessarily the case. In my proposal you’d rather have a separate solver node that can be linked to multiple types/outputs/entities/… to replace the default solver.
- It makes too many assumptions about the future that I’m not willing to make yet. Better keep things simple so that when we know more about where we are going, the versioning code will be simpler.
1 Like
After partially reading the thread, and more or less assimilating it, I made a flow proposal.
I am not a technician, so I have done what I could. I don’t know if it solves the exposed problems, but I think it’s quite understandable.
At least this is another point of view.
5 Likes
Please describe how we are supposed to “read” this node tree.
3 Likes
I guess it will be plagued with mistakes, but
as I see it there are three generators or emitters of particles. One of them generates the particles from a point, another that generates them from a grid, and another “Explosion” that generates them from the position of other particles.
The grid generator lacks the position parameters, but basically it generates a matrix of particles when changing frames between 33 and 66. These particles receive an impulse in the direction of a vector when they are born.
The generator per point generates particles from a to position while the A key is pressed, I suppose the rhythm needs to be indicated, and they receive a random impulse at birth.
These particles with their impulse join or group together and receive a pair of permanent forces, gravity and wind, which may accelerate, as they are constantly updated. When the particles exceed 30 frames of age they die, but at the same time they generate new particles with the explosion, and all the frames of these are rendered before they die.
The new particles generated after the explosion receive the force of a turbulence while they have between 22 and 45 frames of life, and if they collide with an object that is not specified, they bounce. I suppose the explosion should also generate an initial radial or inherited impulse from the original particles.
In the end, just as the rest of the particles have done, they are rendered using the shape of a cube.
Another thing that runs through my head is that although the particles do not use the position of the particle object itself, there should be an empty type icon or symbol that allows them to be selected in the 3D view.
I hope I have clarified something.
2 Likes
@wevon personally I like that design a lot. Maybe it’s just me but I find that node-tree fairly clear and easy to understand. And it seems like the same design could be extended to a simulation system for objects also
Off-topic
This could be done with signals like godot…
Although it may be outside of the scope of everything nodes…
Every NodeTree could have input and output signals and we could have a place to join signals from different NodeTrees…
I am not sure if it’s possible and it may break depgraph…
1 Like
Hi,
I take some time and make some proposed changes for the concept.
For me, the most important thing is color-coded symbols and flowlines (Not only for Particle node system but every node system). An extremely useful thing would be context-sensitive search, e.g. When I pull from node point there is a context search menu for every available node for this particular purpose.
I took your example and made some modifications (a little mockup) for the same purpose, and I hope better flow and visual indication of what is going on.
I am sure there are few nonsenses in my purpose or isn’t? 
2 Likes