I attended the plugin coding workshop for noobs at node10 today and after roaming around the addon pack thought, a proper particle engine might be useful.
I put some thought into this and came up with the idea to have a particle workflow in vvvv which starts at emitters, can be modified by effectors and ends up as a spread of transformations which you can then apply to geometry or images or anything you like. I have already started on a framework for this which I have attached to this post. You can already see the basic particle-flow there, although there is not much more than a gravity effector at this point. I thought I’d show this to everyone to collect some comments if this kind of stuff is actually needed around here, or if I have missed some other fantastic particle suite out there. A demopatch is in the plugins folder, I was not sure how to distribute this properly.
A few words about the concept:
You can see that I have emitters who’s particleflows can be split up by splitnodes (you see AgeSplit in action here) and joined together again by joinnodes. The idea being you can seperate out certain particles based on certain conditions like age, orientation, position, scale, color, id, patterns etc. to kill them, perform different effectors on them or even use them to generate new particles at this point. Effectors could be gravity, radial forcefields, scalers, transformers, radial velocity appliers etc. etc. Once the framework is in place writing aditional plugins for the Particle Suite should be pretty easy.
About the code:
This is my very first vvvv plugin (and also almost the first time I have actually used vvvv), so comments about the coding and patching style are very welcome. I seem to get into a lot of trouble with inlets not being connected and strange spreads with a slicecount of 1 but nothing in it.haunting my nodes. Any thoughts about that would be quite apreciated. Also what are the coding conventions about variable names? All with capital starting letters? Or only objects capital and primitives starting small. Let me know :)
also it would be good if your particle would inherit from VVVV.Utils.Animation.Particle. its a base class which has an update logic, which depends on the current time of vvvv, which is important for non realtime renderings. see the Spray.cs in the plugins folder for proper use… Particle.cs
impressive for a quick hack. hope you find the time to continue on this as i think it has quite some potential.
here some thoughts:
i’d suggest a naming like this
Emitter (Particle Sphere)
** Radius (if 0 makes a point emitter, else a spherical)
** Radius Deviation (just to give it a more random feeling)
** VelocityXYZ (shouldn’t a velocity-vector replace the SimulationSpeed?)
** VelocityDeviationXYZ (just to give it a more random feeling)
** Mass (just to complete the parameters)
** Mass Deviation (just to give it a more random feeling)
** Lifetime (was: MaxParticleAge)
** Lifetime Deviation (just to give it a more random feeling)
** Count (was: ParticlesPerFrame)
all the Deviation pins could probably be set to 0 and hidden by default.
Emitter (Particle Cube)
** same pins as above only instead of Radius a SizeXYZ
Effector (Particle Gravity)
Split (Particle Age)
Split (Particle Pattern)
GetDetails (Particle) (box2d has similar GetBodyDetails and GetJointDetails… was: Particle2Values)
should be all in the codingconventions link tonfilm already provided, but in short:
fields of a class, ie. class variables start with an F. so FParticles, FParticleCount, etc.
classes, properties, functions start with a capital letter
local variables and function parameters with a lower letter
also all such spaces should be removed:
ResultParticles.Add ( Particlesj );
to look like:
ie. no spaces before and after round braces.
there is a comfortable
function that does exactly this:
new Vector3D (Randomizer.NextDouble() * 2 - 1, Randomizer.NextDouble() * 2 - 1, Randomizer.NextDouble() * 2 - 1 );
ah right and seems nobody told you about our
class which would have saved you some coding as it does the basics for you already and you can easily inherit from it.
seems not all the particles actually die after their lifetime has passed. simply connecting a pointemitter to particle2values and emitting once (for one frame) should kill the particle after its maxAge has passed, right?
a fundamental problem is, that you’re always operating on the same particle system. if from an emitter you have 2 outputs and downstream on both connections the particles get effected you’re influencing the result of both connections at the same time. see attached patch. so if an output has two connections you actually need to provide a copy of your system downstream.
I just wanted to say thanks, I´ve been playing around with that for quite a while. Really looking forward to get more Effectors, can be alot of fun.
And i got one (noob…) question: Is there a way to use the position information your plugs spits out into the ParticlesGPU Shader Library?? This would be really nice, I managed to render 1 million particles at once with about 50 FPS with this patch.