Wishlist/Particles

From VFXPedia

New features or tweaks for the particle system.

Contents 1 Particles 1.1 Interface and General Requests 1.2 Particle Style 1.3 Regions 1.4 Dynamics 1.5 Particle Forces and Auxiliary Tools 1.6 Rendering 2 Workarounds 3 Completed Requests

Particles

Interface and General Requests

• Particle direction tool should have an on-screen widget for making it easy and simple to set it's direction, much like other 3D tools have.
  • Actually, now that I think of it, the particle vortex tool could really use an onscreen control widget as well. Even if it is not something you can move but just illustrated with curved arrows which way the vortex is spinning. It always takes some trial and error to get that figured out. But if one could see directional arrows in the view wndow would make it obvious straight away in which direction and n axis the vortex is spinning in. --andromeda_girl

• Ability to deinstance splines like Size over Life or Blur over Life for instanced pEmitters --Gringo

• Branching for particle tools --Gringo

• Import Transform button in pEmitter. --Gringo

• It's strange that all rotations in Fusion are measured according to the common 3D concept (2D rotation counterclockwise is considered as positive Z rotation) while pDirectionalForce.DirectionZ is actually negative rotation around Y. The same old-fashioned 2D-style is in pEmitter.VelosityControls. --Gringo

• Now, if you RMB on any parameter in the Region tab except X/Y/Z Offset, the menu offers Animate Cube/Rect/SphereRgn Group instead of expected Animate Rotation/Pivot Group. --Gringo

-If you look at the input IDs you'll see why that is. The X/Y/Z Offset inputs have IDs SphereRgn.Translate.X/Y/Z so they're all part of the "SphereRgn.Translate" group, where X/Y/Z Rotation inputs have IDs SphereRgn.X/Y/ZRotation, so they're part of a "SphereRgn" group, ie. the whole SphereRgn. Doesn't really seem like something that should be in a wishlist. --Stuart

-What if groups in pEmitter were arranged just like in any other tool from the 3D suite so that you could "Animate Translate Group", "Animate Rotate Group", "Animate Scale Group"? --Gringo

• Config tab for the pCustomTool just like in general CustomTool to rename the controls and hide unneeded ones. And also, connectible point controls. --Gringo

• An option in the pEmitter to use Variance parameters not as values which are added or subtracted from corresponding parameters, but as a fraction of them. If the Variance = 0, there is no variations, otherwise the corresponding parameter (CP) changes from CP-CP*Variance to CP+CP*Variance. Now, if you don't connect a Variation to the corresponding parameter with a simple expression, you always have to adjust it manually to keep the proportion and to avoid undesirable negative values. So I always end up with simple expressions like LifespanVariance=Lifespan/N which makes the slider unusable.

This is especially important for the color variations. For example, if you want to start and stop emission of a sprite-based smoke smoothly, you need to animate the emitted particle Color values from 0 to 1 and then from 1 to 0 (you won't be satisfied with the Number animation getting separate sprite puffs instead of growing and decaying stream). Now, when the Color is 1, variance of 0.5 will change it from 0.5 to 1.5, but when the color is 0.1, it will be changed from -0.4 to 0.6, so you have to animate Red Low, Red High, Green Low, Green High, Blue Low, Blue High, Alpha Low, Alpha High proportionally. --Gringo 14:29, 19 November 2011 (EST)

• Non-linearity for variations in particle parameters to have a few big particles amongst small ones or to emit a few particles off axis whilst the others fly in a stream. It could be an additional parameter like Variation Bias which would work as a power function applied to the variations array. --Gringo 16:16, 19 November 2011 (EST)

Particle Style

• In particles system Make the Bitmap and Brush Styles produce particles based on multiple images file.

-It would be great if particle bitmap could be selected from image sequence or image matrix based on particle direction, rotation and velocity in addition to particle time. This way several animations could be created for different particle states, allowing chaotic and organic systems, like flames in the wind. Blending between sequences would probably be needed in this scenario.

-Also it would be good if bitmap could be scaled on particle vector based on velocity.

• Now that we can emit from geometry it would be nice if we could convert vertecies to particles and drive geometry back from the simulation. This would result in softbodies dynamics. Since particles have ids this should be possible. --bFloch

• Possibility to set pEmitter.ParticleStyle.ColorVariance less than -1 and more than 1. Would be useful in the cases of very bright particles with color value >10 which are used for sparkles, fireworks and so on. I know, it can be solved with a post-color correction, but it's not so elegant. --Gringo

• Color Variance values are now added to the particle color instead of being multipliers. It makes problems when, for example, the initial color is 0.5 and the variance value is -1. --Gringo 09:27, 1 September 2010 (EDT)

• Opacity over Life graph would give us much better control over non-linear fade in/out being more handy and easy to adjust than Fade Controls + Color over Life, especially, if the particles should change not only opacity, but also their color. --Gringo 09:27, 1 September 2010 (EDT)

• Transparency to Size parameter which would adjust particles' transparency according to their size. This control would be extremely useful for making sprite-based smoke, where the transparency of each sprite should quadratically increase with the size as the smoke dissolves. It would be also great for simulating out-of-focus suspended dust (the bigger the defocused particle - the greater the trasparency). If the parameter would be set to negative, it could help creatind fade in/out effect for the particles like highlights which need to emerge from transparency, grow and then fade out decreasing the size. --Gringo 11:06, 3 October 2011 (EDT)

• Animatable Style. So we can either keyframe it, or more likely, modify with expressions. --Chad

• Ability to define compositing mode, ala the 3D objects. Additive, subtractive, etc. --Chad 13:22, 18 November 2009 (EST)

• SOLID NGons. The NGon Solid style still produces a <1 alpha at the edge. I'd rather let supersampling take care of the edges so Z Buffer sorting works with them. Seems as though the NGon is actually mapped planes, not triangles, so this may be difficult for NGons with sides != 4. Emitting the NGons as geometry would actually be nice, too. --Chad 13:22, 18 November 2009 (EST)

Regions

• Bitmap Regions in 3D

The ability to use an image plane in 3D space as a bitmap region for particles.

--Then it could be any textured 3D objects, not only image plane.--Gringo

• Another, simpler suggestion: a Scale control in the Bitmap region. It would be very useful in case the same particle setup needs to be added to shots with different framing. Now, if you use long shots and close ups as the source for the Bitmap region, the scale of the emitting areas changes in 3D and there is no possibility to align the shots apart from scaling particle size and forces' parameters. --Gringo 07:01, 21 October 2011 (EDT)

• Ability to smooth regions. For example, smooth decay of particle generation according to softness of a bezier region or multiple gradations based on a bitmap region. --Gringo

--In some cases you can animate the region size with a frequent sub-frame shake in order to smooth it.--Gringo 08:26, 26 October 2011 (EDT)

--Description of the technique. --Gringo 14:00, 24 January 2013 (EST)

• pImageEmitter should emit a rectangle of particles scaled to the image input. An image 1000x1000 @ 1:1 should make a particle system larger than one from a 500x500 @ 1:1 image, but should make the same size particle system as a 500x500 @ 2:2 input. The density seems to be related to the input image size, so why shouldn't the position? --Chad 13:25, 18 November 2009 (EST)

• pImageEmitter needs a Filter Method (even a basic one, Nearest Neighbor / Linear) for the particle-to-image sampling. Right now, and black/white input map will make grey particles where the black and white regions meet, even if there is no grey pixels. --Chad 13:28, 18 November 2009 (EST)

• An option to make regions renderable. It's important in case the regions have to be synchronized with objects in the BG plate. For now, the only option is to create a Shape3D and connect it's parameters to the region's parameters. --Gringo 16:30, 31 August 2011 (EDT)

Dynamics

• Per-particle collisions or "incompressible" particles to simulate sand and similar solid particles or incompressible fluids, like water. PCollision node or something similar would probably be most flexible way to implement this. Game technology has created pretty fast ways to detect collisions, maybe these algorithms could be used.--Hevonen

• Interparticle Collision (GPU based) where the you can define a polygonal collision shape around the particles where the collision will occur

• Smoothed Particle Hydrodynamics for fluid-like particle systems or some other method that makes particles to act in more fluid-like manner (meaning that particles move together as one and break away only when tensions get too high, hum, "sticky" particles that get clustered to each other?).

-Doesn't pFlock solve this? --Gringo

-No. PFlock models flocking behaviour of autonomous creatures, this is fluid simulation (smoke, fire, water etc).--Hevonen

• implementation CUDA to accelerate particles generation / interaction

• 3D curves to control/emit particles (e.g. writeOn effects in 3D Space)

• Possibility to define particles' trajectory by a 2D path. X axis of that 2D path should be oriented in space according to each particle's initial angle. Additional parameters like Path X Rotation and Path X Rotation Variance would be useful. --Gringo

• The Spin parameter in the pEmitter should affect the Point Cluster particles just like it does with other particle styles. --Gringo

• A possibility to connect the emission direction to the Region rotation. It's needed, for example, to simulate exhaustion from bottom nozzles of a flying object which has a complicated trajectory.

Now there are several ways to solve this task, but all of them have their disadvantages.

1. Connect pEmitter.Angle to SphereRgn.Rotate.Z and pEmitter.AngleZ to -SphereRgn.Rotate.Y. This works for Y and Z rotation separately, but if you rotate both axes it won't produce desirable result because the emission direction rotates in not the same axis order that region does.
2. Adjust the pEmitter.InheritVelocity. Works only in case the object emits particles forward and backward according to its trajectory.
3. Attach a Transform3D after pRender. Rotation works perfectly, but it rotates the complete particle system with all its forces and obstacles.
4. Animate pEmitter.Angle and pEmitter.AngleZ by hands. The only comprehencive solution, but it's not intuitive and implies complete reworking each time you change the object's trajectory.

An example: PEmitter_RegionRotationToAngle.comp --Gringo 07:13, 21 November 2009 (EST)

• An option to emit particles along the normals of Mesh emitters in case of emitting from surface. --Gringo 08:33, 26 October 2011 (EDT)

• A Mass parameter for all the particle generators. It would define how quickly particles respond to the forces. This is especially important when an effect consists of different types of particles like sparks, debris and dust/smoke as well as when your forces quickly change the vector. pFriction doesn't solve this problem. --Gringo 16:21, 27 November 2010 (EST)

• A possibility to preview the particle dynamics itself separately from the final rendering would tremendously speed-up the process of tweaking. Now the user has to wait for slow rendering every time he/she plays with forces. It's getting much worse when the motion blur is used. And particle cache should be able to store dynamics separately as well. --Gringo 15:52, 2 December 2010 (EST)

Particle Forces and Auxiliary Tools

• pGF support for vector fields, not just scalar fields. Use RGB to represent XYZ magnitudes. It's trivial for us to make the vector fields, but making a scalar field that can represent the vectors is difficult and not efficient/accurate. --Chad

-Is this solved by means of Theo's technique http://www.pigsfly.com/forums/index.php?showtopic=5340 ? --Gringo

-No, it doesn't appear to be iterative. And it's really slow. The pGF is internally using vector fields, so I would just like to override the conversion and just input my own. --Chad

• Would be great if the pSpawn.StartAge/EndAge parameters were turn into Number over Parents' Life to control the quantity of particles that are emitted during the main particles' life. --Gringo

The same for other Start Ages /End Ages in the Conditions tab of different forces. So, a force can start/end affecting particles smoothly and can change its magnitude several times during a particle's life. Currently only pTurbulence has such a possibility --Gringo

• It would make more sense if the Use Color from Parent Particle option of the pSpawn inherited the actual color of a parent particle considering its Color over Life and Fade. Now this option copies the parent particle's style, which can be done by just copying the pEmitter's style properties to the pSpawn. To not break the compatibility, I suggest adding another option so that the user could choose between Use Style Color, Copy Style Color Properties from Parent and Inherit Actual Color from Parent. --Gringo 09:09, 17 November 2010 (EST)

• It would be great if the pSpawn had a parameter like Number to Velocity, which would increase the number of generated daughter particles for fast parent ones. This would be useful to create trails of different kinds. pSpawn has to generate enough particles to make trails continuous, but if the general Number is increased, lots of particles are generated in vain, because slow parents don't need a great number of daughters :))) --Gringo 04:21, 4 February 2011 (EST)

• It would be more intuitive if the Power parameter in pVortex and pPointForce was called Strength Decay. --Gringo

• A Temporal Frequency parameter in the pTurbulence. First of all, it would help eliminate the jerky motion the pTurbulence introduces to particles. At the moment, the pTurbulence is nearly useless for realistic particle effects and I have to create setups based on the pCustom instead which are slow, cumbersome and have their own flaws (not as obvious though) in the result. --Gringo

• A possibility to shift the Turbulence pattern in space. --Gringo 09:11, 25 October 2011 (EDT)

• Possibility to apply Transform3D and Duplicate3D directly to pEmitter (to affect only pEmitter coordinates, not particles' coordinates) so that it could participate in hierarchy and could be instanced in a special way. --Gringo

• pCustom "Set" output. So we can use "if" statements to move particles into a new set. --Chad

• A possibility to refer not only current resulting size, position, color of particles, but also all these parameters before they are modified by a pCustom.

For example, I want to set size variance, size over life properties and animate size itself in the pEmitter.

Then I want to modify particles size by multiplication. If I use "size" in my expression it means size modified by pCustom in the previous frame and modifications accumulate which isn't always desirable.

Now, if I want some properties variations, I need to define them completely in my pCustom which makes the expressions more complicated and slow.

See also: http://www.pigsfly.com/forums/index.php?showtopic=6199&view=findpost&p=23957 --Gringo 05:57, 5 May 2010 (EDT)

The problem with that is that there is no "before they are modified by a pCustom", particles don't get evaluated one tool at a time, but are integrated over time. So the input for a pCustom is meaningless except for setting up the order of operations for the integration steps. The only way you could access that information is if you had cached it somewhere. Perhaps in an image buffer, or to some persistent user data. You could probably do this with a fuse, but I haven't tested to see how ID's get "recycled" if at all when you change the particle counts over time. --Chad 09:36, 5 May 2010 (EDT)

• Config tab in the pCustom just like in the Expression modifier to name and hide the controls. --Gringo 06:40, 9 September 2010 (EDT)

• A possibility to change the particle style from a pCustom. It would make mimicking 3D particles much easier and if the pCustom could also address any frame from a sequence, it would tremendously simplify particles look variations. --Gringo 11:26, 14 September 2010 (EDT)

Rendering

• Volumetric particles for creating realistic natural phenomena (clouds, fire, smoke etc)

• Absorbing and emitting particle types, also varying with lifetime (changing from other time to next). Possible solution would be to use float textures and treat values from 0 to 1 as absorbing and over 1 as emitting.
• Either volumetric particle emitter or volumetric particle renderer. With latter method particle system would be set up just like ordinary one, then converted to volumetric system, assigned with volumetric textures and properties and rendered out.

• Particle Set to object or material buffers

It would be great to have the ability to mask glows etc. to material or object channels based on the set of a particle.

• There is a bug with motion blur: Quality, Shutter Angle and Center Bias parameters affect particles' position. --Gringo

-Why would this be a bug? --Chad

-Motion Blur should just blur particles (maybe with some shift) and shouldn't completely change their position. It prevents to make combinations of blurred and not blurred particles that must have the same position. Also, it's wrong when you quickly tune particles without MB and then need to turn it on for the final render.--Gringo

-Motion Blur is supposed to be based on motion, which requires the particles to move. EVERY tool in Fusion works this way, not just particles. --Chad

-Try to create a pEmitter, connected to a pRender (2D). Set Number=1, Velosity=0.1 in the pEmitter. Go to the 10-th frame. Drag'n'drop the pRender to a Display View. Turn MB on. Set Quality=3 in the pRender. Set Quality=4. Set Shutter Angle=179...--Gringo

-I think it happens because particles are born not exactly in a particular frame, but somewhere about regardless the Sub-frame Calculation Accuracy setting. You can get certain of it if you animate the Number in pEmitter so that it was 0 in all frames and 10 in frame 15, then compare particles' position when Global In of pRender is 1, 14, 15 --Gringo

• An option in the pRender to inherit the motion blur settings from a Renderer3D in 3D mode (on by default). For correct results, these settings should be the same, so why to set them every time manually in both nodes? It's not obvious for the beginners and confusing, not to mention that it takes time to re-enter the settings or to make connections via expressions. For the cases when the particle system is connected to multiple Renderer3Ds, there could be a drop-down list to chose, where to copy the settings from. --Gringo 13:31, 19 November 2011 (EST)

• An option for motion blur to calculate particles' positions between frames not as independent samples, but as interpolation (spline or linear) between whole frames. It would eliminate the complete change in particles behaviour when you switch MB on and off or adjust its properties. The point is, for a user MB has nothing to do with the dynamics calculations precision, it's rather one of the aspects of particles appearance. It's usually switched on after you've set up everything and want to get the final rendering. With the current approach users get completely unexpected results with motion blur. Particularly when they use a pCustom, whose expressions are calculated not once per frame but once per a MB sample. --Gringo 11:11, 14 September 2010 (EDT)

• Change shading parameters of particles.

• Ability for particles to cast shadows but not be visible (or not to be shaded and cast shadows)

Workarounds

• Option to emit with rate on ImageEmitter

-Doesn't animatable X/Y Density solve this?--Gringo

• I had the problem, that if a particle uses an animated bitmap as style you cant get random states of the animation cause the emitter creates all the particle on the first frame

--ShadowMaker SdR 05:14, 4 January 2007 (Central Standard Time)and related to the above: a way for bitmap type particles to randomly select an image from a sequence without having to resort to 'birth time' and pregenerate workarounds. PI has always worked this way, which is really handy for those 10 frame explosions: you just have 4 or 5 different particle shapes that are all created randomly at the same time, resulting in a less uniform 'cloud' or whatever you want to call it.

--A workaround: Topic at Pigsfly. --Gringo

• Particles Follow path. A "Follow Path" Operator where you can control the direction and traveling time of the particles with a spline

--Solved with a setup based on the pCustom in Fusion 6.1 build 697 and later: http://www.pigsfly.com/forums/index.php?showtopic=4976&view=findpost&p=26003. --Gringo 16:21, 27 November 2010 (EST)

Completed Requests

• Particle ID #'s

An ID attribute that could be used in pCustom expressions to create (for example) individual particle goals.

--Izyk Available in Fusion 5.2 and later.

• Particle Emitter - inherit velocity attribute == To get emitted particles inherit the velocity of a moving emitter (in other words: particles would follow their emitter by the amount of this attribute).--Ata

--Gringo Available in Fusion 5.2 and later.

• Allowing an FBX Mesh to be a particle bounce surface = heavenly

--Gringo Available in Fusion 6.1 and later.

• Ability to emit from shapes / geometry.

Ideally, particle color /rate could be derived from object texture or color from a projection.

--Gringo Available in Fusion 6.1 and later.

• Ability to cache Particles, ideally so that you can change the style without it having to recalculate the particles' position every time.

--Gringo Available in Fusion 6.1 and later.

• 3D Motion Blur on 3D Particles
  • Note: motion blur does work on 3D particles, even in Fusion 5.02, if and only if you have identical mblur settings on both the pRender and Renderer 3D tools.

• Time Variance parameter in Bitmap Style, Over Time mode to make particles unique when they are born at the same time. --Gringo

--Gringo Has been solved here.

• Position Variance for each axis separately in Particle Emitter

-This could be done easily with the pCustom node. theotheo

-Just enter expressions like if(age>0, px, px+rand(0.01,-0.01)) to the Position X/Y/Z Expression fields of the pCustom. See also: PRandomizeInitialPosition.setting. --Gringo

• Bitmap attractor for (nearest) particles

-pGragientForce solves this: PGFAttractor.comp pGFAttractor.mov --Gringo

• New particle node to convert one object to other such as text converts to blob and the blob join in new text.

-I think it can be done by dissolving both textes to blobs and combining them together as sequences (one of them reversed and time-shifted) --Gringo

• Animatable motion blur parameters in the pRender. Not to animate them, but to connect, for example, to a Render3D motion blur parameters. --Gringo

--Available in Fusion 6.3 and later.--Gringo 09:42, 5 November 2011 (EDT)

• 3D shape particles
  • Houdini's copy SOP is a good example of how this could work. Would be super nice if we had a kind of "stamping", meaning controlling parameters upstream the instanced geometry based on the current instance particle's attributes.--bFloch

-- Available since Fusion 6.4 by using Replicate3D