More than 'just' Particles...

Alright, I am treading unknown territory here, as we obviously know next to nothing about how Particles are going to be implemented.

The limited info on particles hints at two basic component types that we will probably see: Particle Shape components (i.e. NGons/Stars, Text hopefully) and a Particle Bomber/Generator component that will distribute the particle shapes across the image in various modes (say... in grids, inside of primitive shapes, at random, according to regions defined by image luma/chroma/alpha etc.).

Now, I am hoping the devs are three steps ahead of me here. What I would love to see is that particles are not simply slammed into their final position on the image, but that instead they may be influenced by various force-fields that force them to 'move' away from their birth position, thereby defining trails. This would be a kind of 'animation under the hood', where we only ever see the final state of the particles in the image (and depending on the number of particles, this can become quite heavy to render).

There could be the usual types of force-fields (like directional forces, turbulence, vortex, friction, etc.) and special ones like image and gradient based force-fields. These are basically maps that would contrict particle trails to certain regions or along certain features of the image. A bricks component used in this fashion could force the particles to form trails roughly along the mortar lines, allowing effects such as moss growing or blood running between the bricks. If the particles had the ability to spawn additional particles along their path, the creation of grass, furs and hair might also be possible. In effect, the particles become procedural brushes, and their trails the brush strokes, all defined by the forces acting on the particle system.

I'll probably get killed for mentioning something that can be done in other software, but I'll do it anyway: Project Dogwaffle's 'Optipustics' are a good example of what I am trying to convey here. They are painted instead of procedurally placed, but they do make spectacular use of image forcefields.

Well, that's my ideas and hopes for Particles... for the moment!

WOW

Quote
Vladimir Golovin wrote: A possible problem with the ideas you're suggesting is of course the speed

I agree. While even complex optipustics-strokes can be painted interactively, generating an interactive preview of the whole 'paint job' at once would certainly not be all that speedy, even with a proxy view that used a largely reduced particle count. I dare not think about what would happen if the user dared pipe a complex particle setup through a highpass...

Still, completely procedural particle brushes are not too commonplace in programs these days, so this might be an area well worth delving into, especially if you plan to introduce animation capabilities into FF someday. Just speculating about all the nice things we could do with those particles makes me feel all warm and fuzzy inside...

Quote
Crapadilla wrote: especially if you plan to introduce animation capabilities into FF someday.

Animated particles is an entirely different story -- we'll have to watch out for temporal discontinuities, which aren't a problem for a non-animated package.

They are on the Optipustics panel (see image below).

To use forcefields you first need to open a forcefield image, then fire the forcefield plugin via the Optipustics palette. Finally, swap the image buffers via the layers palette, so that your image ends up in the forcefield buffer!

That's how it's done in the full version at least, the demo might be feature restricted...

Yes and no. I am using PD Pro 3.5 as well, but the full version. I guess the demo is restricted then.

Still, if you are willing to dig into it, the commercial version is VERY cheap.

Quote
Crapadilla wrote: Furthermore, I'm hoping that the bomber tools won't be introduced as a separate component 'category' (with a completely new type of input required)

Definitely not. Both the particles and bombers will be regular map components. Introducing a new component/input type would ruin learnability.

Quote
Crapadilla wrote: Will we have an 'all-in-one' bomber component with a large amount of controls

Yes, I'd prefer it to be this way. It would have a map input for a particle (or even multiple particles in one input, but I'm not sure about this one), and mappable inputs for placement, size, rotation, stretch, opacity, density, etc. Maybe something like this:


Particle Noise: Map Component
-- Particle: color map
-- Background: color map
-- Size: grayscale map
-- Stretch: grayscale map
-- Angle: grayscale map
-- Opacity: grayscale map
-- Density: grayscale map
-- Roughness: grayscale map

-- Details: slider
-- Fill Mode: combobox

-- Variation: random seed


Particle Grid: Map Component
-- ...
-- ...
-- ...

Quote
Crapadilla wrote: The fact that all the parameters can be mapped has me in very high hopes.

If they were unmapped, that would result in a pretty dumb bomber, wouldn't it? We always try to make as many map inputs as possible -- this is the key to FF's versatility.

Quote
Crapadilla wrote: what exactly does 'Roughness' do?

Exactly the same what it does in all noises (together with Details). Details controls the number of octaves, Roughness controls their relative transparency. I hope that we will be able to use the layered octaves approach in the bomber as well. I think this is feasible, but there may be problems with brightness normalization.

Quote
Details controls the number of octaves,

i'm not familiar with your use of 'octaves' here. i know it in music and i'm guessing there's a similarity in graphics, but not sure what that is. i looked it up and still didnt really find anything. care to elaborate?

Quote
Vladimir Golovin wrote: Particle Noise: Map Component -- Particle: color map -- Background: color map -- Size: grayscale map -- Stretch: grayscale map -- Angle: grayscale map -- Opacity: grayscale map -- Density: grayscale map -- Roughness: grayscale map -- Details: slider -- Fill Mode: combobox -- Variation: random seed

Looking at the parameters again, where does the user set the number of particles that are created?

The 'Density' parameter - as I understand it - sort of does this, but it does not allow precise control over particle counts, does it? Black areas spawn zero particles, but how many are spawned in white areas? And what if I wanted exactly 10 particles spawned randomly within a white circle on black ground? Can I set a total particle count for any given bomber component?

Some more questions...

- The 'Fill Mode' controls the mode that the particles are blended with?

- 'Angle' controls rotation around the Z axis I presume. Will there be X and Y rotation as well?

Quote
Crapadilla wrote: does the user set the number of particles that are created?

Don't think this is a good idea, at least for a Particle Noise component. This might be implemented in other bombers (for example, a particle grid or even a specific placement component).

Quote
Vladimir Golovin wrote: Yes, I'd like to see this parameter implemented.

Indeed! Blend modes for particles are indispensible, IMO.

This is being added right after the Mac version, right???

Okay then.....I'll hold Vlad to that promise

Yes, we'll do an open beta -- our first beta was very helpful.

According to the current plan, the major items to be included into 2.0 are bombers, shapes, full range of math components with unclamped output, local search for filters, and grouping of components in the Editor.

Bombers and shapes are relatively easy to do. Math components may pose certain difficulty since they will require control components with numeric input, which, in turn, may require serious infrastructural changes. Grouping of components within the Editor is also a difficult task.

Wow, that sounds great!!!

I don't mean to sound like a "Greedy Gretchen".....but by any chance are "lockable controls" going to be added to the next release???

I know that I sound like a broken record .....but I think that having the ability to "freeze" control values in randomization would be extremely useful in trouble shooting during filter construction.....while also turning the randomizer into an extremely useful tool for users to zero-in on desired effects.....especially in control-laiden filters.....

It's just one of my personal "love to have" features

To be honest, I'm just happy to see FF continuing to grow.....more goodies and a new beta release planned.....life is good!!!