Bomber Improvements

Would like to see a few extra features added to bomber:

* Mappable Particle Density: So you hook a pattern up to this feature and anywhere the pattern is black kills all particles, white means maximum particles, and grey means something in between.
* Grid Row And Column Distance: Would like the ability to increase or decrease the spacing between either rows or columns of Particles.
* Poisson Distribution: As well as the current grid pattern, or a random pattern by increasing the transform chaos values, I'd like to see a poisson distribution mode, that scatters the objects in an organic but relatively even manner, great for avoid interpenetrating and for achieving certain natural phenomena. Take a peak at the images below:

http://umbcgaim.wordpress.com/2010/06...rousel-275

http://umbcgaim.wordpress.com/2010/06...ing-stuff/

Thanks!

- Neil

RE: Chance parameter: thanks for letting me know, that works great!

- Neil

90 Degree Rotation-- You can already do this! Not with "rotation chaos", but with "rotation". Better see this example than me trying to explain myself. You can modify the tone curve to get other angle increments. A quick check-box would be convenient, though.

Poisson Distribution-- Reading the description, isn't that what other people here on the forums have been trying to do for a while? Like the close-packing sphere stuff? Well, FilterForge added the edge detector with several algorithms, so I bet they could do the same for this.

90 rotate.ffxml

I agree with the suggested improvements and I think that filter forge 5 should have the great and amazing bomber upgraded or updated with new features

One of them that I have already suggested is to be able to have a spacing and separation slider between the particles, so you can control them more precisely

And the best would be to have an option to avoid having overlapping particles, I mean that they always could be positioned in non-overlapping places.

Some examples in these threads

Pattern Filling

How would you make this variable dots pattern in FF?

Make this in FF? - Digital Circlism - Artwork with hundreds of circles

Is someone here capable of making a filter that can do this

Looking forward to trying out the new option. Is this in the next beta version?

Thanks Vladimir for the news and good to know, this seems to be interesting, although I really do not understand what it means to have bomber slaves, and what this will change in the way the bomber is used, will have to wait to see how it works and what it does

Kinda like a Particle ID node?

Quote
Vladimir Golovin wrote: the new Bomber with Slaves

Will it be possible to have an arbitrary number of particle slaves (i.e. will the Bomber+ be an "N-particles bomber")?

I'm asking because in your example image I'm seeing just one slave and - more importantly - just one particle input on the bomber.

@Dilla, on the other hand, good point. Since you can only vary green inputs using slaves, having a single Particle input limits you to only one set of gray parameter values in the Particle subtree, while in the original 5-particle bomber you had 5 such sets.

Here's another experimental slave for the Bomber+, Octave. It exposes the number of the internal layer (controlled by Details, Roughness, Layering and Layer Order) on which the particle resides. In this example, particles on the bottom layer (the bigger ones) are colored by the leftmost color of the gradient, while smaller particles take their color from the rightmost parts of the gradient:

@Dilla: I decided to include a Map Switch component to help with particle switching situation / N-particle bombers. The component will include 10 inputs and will allow both discrete and continuous switching between them based on a mappable selector. The component will be fully general, i.e. not limited to use with Bomber.

The spec, so far, is as follows:

Map Switch: HDR Color
Category: Processing.
Perks: Size_enabled = FALSE // for programmers.

Source 1: HDR Map (Color)
Source 2: HDR Map (Color)
Source 3: HDR Map (Color)
Source 4: HDR Map (Color)
Source 5: HDR Map (Color)
Source 6: HDR Map (Color)
Source 7: HDR Map (Color)
Source 8: HDR Map (Color)
Source 9: HDR Map (Color)
Source 10: HDR Map (Color)
Selector: LDR Map (Grayscale)
-------------
Max Source (IntSlider 1...10)
Mode (Dropdown: Continuous, Round, Floor, Ceil)


Logic: Lerp, not Blend.

Optimization: when Max Source == 1, Selector can be safely ignored (because the component degenerates to a lerp between Source1 and Source1). Just pass through the Source1 along with its aazones.

AAZones, continuous case: combine aazones of the 2 Sources being lerped (and I'm not sure we should bother with checking wheteher the lerp amount is 0 or 1).

AAZones, discrete case: originally I thought about just passing through the aazones of the Source being used. BUT, since the Selector is mappable, in discrete cases we can have sharply-bounded regions of Source A and Source A+1 in the image. We need an aazone for each of these two regions.

Quote
Vladimir Golovin wrote: I decided to include a Map Switch component to help with particle switching situation / N-particle bombers

Glad to read that.

It occurs to me that chaining/nesting particle switches should provide enough "room" for all my "expansive particle set" needs.

Dilla - since they removed the Tint option and thereby our only option to piggybag data used at particle level for rotation, ordering, squashing and what not, we can expect them to add slaves corresponding to all particle level inputs, right Vlad?

(by particle level I mean data sampled once per particle and not per output x,y, like for example rotation)

Just wondering... Will the new bomber be faster than the normal one?

New slaves + Map Switch in action:

This is gonna be so rad, Vlad.

Quote
Vladimir Golovin wrote: Scratch that. I'm exposing the actual center of the particle after all offsets and chaos via Center X and Center Y slaves; and the actual rotation, size and squash of the particle after chaos via Rotation, Size and Squash slaves. (I just had a very interesting idea of what's possible with Center X and Center Y. Let's see if it pans out.)

That is good news. The way I've been using the bomber lately is by using opaque particles with "local coordinates", i.e. red channel = particle x, green = particle y and blue is all black. Then here comes the piggyback trick: if I want to get the actual particle size, rotation, squash, depth index etc I plug in a map input into the relevant particle property AND a copy into the Tint input (blue channel only) which is set to 100% and Tint mode is Linear Dodge. The output of the bomber now contains coordinates I can use with lookup to map the actual particle texture and some other property, like e.g. the depth index of the particle. Nice.

The slave component version I asked for is much nicer and allow you to work with more than one additional particle property and use the blending of the bomber more conventionally..

Btw. you do not expose all possible particle properties as slaves, please dont remove the Tint..

Well, the Tint is fetched once per particle, so if you feed Tint the same input as you use for some other particle property like depth map, size or rotation, you can extract that from a channel afterwards like I described

The particle input is simply contructed from two gradients (representing X and Y coordinate space for the particle) into an assemble RGB (with only R and G used, blue remains zero). The tint then takes another Assemble RGB with R and G = 0 and B = the source you use for a particle property

@Sphinx - you don't need the fixed-function Tint anymore, nor do you need any extra slaves to implement one. Here's a crude implementation of Tint using Blend together with the Center X + Center Y + Lookup technique:

I don't use Tint the intended way - what I mean is that Tint currently makes it possible to get the same sort of functionality as the slaves... so if you remove Tint, but don't implement all particle level input properties as slaves, then you limit the actual possibilites..

A cool trick with the new Rotation slave: All particles are randomly rotated and by default are black, but the particles whose rotation approaches 90 degrees are colored white:

Dilla, and everyone, can you come up with any other data you'd like to be exposed via slaves? For example, particle bounds in some form (as four points, or in some other form), or perhaps the center coordinates of the grid cell in which the particle resides (that is, the particle center before Offeset H/V and Chaos H/V are applied)?

The only other thing I can think of at the moment is exposing the actual opacity of the particle, after chaos / roughness / details / layering method adjustments. That is, the slave could expose the exact actual opacity that will be used to render the final particle. But is this necessary? What are possible use cases?

Technically, it's possible to expose all these data, but we're risking over-complicating the component.

Vlad, you're right, my bad. With a coordinate for the particle it is easy to lookup those values. Bye bye Tint, you served me well

Perhaps data related specifically to the octaves?