Login - Create Account

Bomber Improvements

Messages 1 - 45 of 120
First | Prev. | 1 2 3 | Next | Last 
Login or Register to post new topics or replies
Neil Blevins

Posts: 27
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
  Details E-Mail
Skybase
2D/3D Generalist

Posts: 3895
Filters: 74
Mappable Particle Density - The chance parameters currently deal with the particle density allowing you to control where particles should be and where they shouldn't.

Grid Row And Column Distance - This doesn't exist as a single parameter but if you use the repeat params and scale, these should compensate a little bit of what you're getting at. Again, not exactly to description.

Poisson Distribution +1 for this. lol come on FilterForge, you can do it.
  Details E-Mail
Neil Blevins

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

- Neil
  Details E-Mail
Neil Blevins

Posts: 27
Oh, and added wish...

Ability To Limit Random Rotation to Increments of 90 Degrees: for architectural, grid related patterns.

- Neil
  Details E-Mail
Indigo Ray
Adam

Posts: 1336
Filters: 79
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. smile;) 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
...or something like that.
  Details E-Mail
Skybase
2D/3D Generalist

Posts: 3895
Filters: 74
You can also round values via RGB math if you don't want to use the curves component for whatever reason.
On the round node, set the granularity to this hex color: 404040

It does the same thing as the tone curve + stairs.
  Details E-Mail
SpaceRay
SpaceRay

Posts: 9735
Filters: 33
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
  Details E-Mail
Vladimir Golovin
Administrator
Posts: 3314
Filters: 55
Quote
Ability To Limit Random Rotation to Increments of 90 Degrees: for architectural, grid related patterns.


Neil, this will be possible when we release the new Bomber with Slaves. Essentially, you will be able to customize each particle individually, and, in your particular case, this customization may include a randomized 90-degree rotation via the Transform -> Rotate component.
  Details E-Mail
Rachel Duim
So Called Tortured Artist

Posts: 1134
Filters: 70
Looking forward to trying out the new option. Is this in the next beta version?
Math meets art meets psychedelia.
  Details E-Mail
Ramlyn
Ramlyn

Posts: 1870
Filters: 312
It sounds very interesting. Looking forward to try it. smile:)
  Details E-Mail
SpaceRay
SpaceRay

Posts: 9735
Filters: 33
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
  Details E-Mail
Vladimir Golovin
Administrator
Posts: 3314
Filters: 55
Here's an illustration of how it works, except the Slave is not yet finalized, it will be called Randomizer and behave exactly as the one in Loop does:

  Details E-Mail
Skybase
2D/3D Generalist

Posts: 3895
Filters: 74
Kinda like a Particle ID node?
  Details E-Mail
Sphinx.
Filter Optimizer

Posts: 1587
Filters: 38
That looks great, Vlad! Thumbs up for the simplification of the Bomber particle/chance inputs too!
  Details E-Mail
Crapadilla
lvl 52 Filter Weaver and Official "Filter Forge Seer"

Posts: 4360
Filters: 65
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.
--- Crapadilla says: "Damn you, stupid redundant feature requests!" ;)
  Details E-Mail
Vladimir Golovin
Administrator
Posts: 3314
Filters: 55
@Dilla:

1. As with Loop, you can have any number of copies of each slave, each with different parameters, and you can even feed slaves into each other.

2. Even with one slave, you can achieve any number of particles. You are not limited to a single component between the slave and the particle input, which means you can include a subtree that parametrically produces any number of particles, of any shape or form. The only limitation is that you have to build all your variation using Map (green) inputs only, because the gray inputs cannot be affected by slaves.

@Sphinx: We've simplified it even further: we removed Tint, Tint Amount and Tint Mode inputs. All this can now be done in the Particle subtree.

@Skybase: Yes, that's the general idea, but the final Bomber+ won't include Particle ID. The slave will be exactly the same as Randomizer in the Loop.
  Details E-Mail
Vladimir Golovin
Administrator
Posts: 3314
Filters: 55
@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.
  Details E-Mail
Vladimir Golovin
Administrator
Posts: 3314
Filters: 55
@Myself: We could cram multiple sets of gray parameter values within a single subtree if we had a Switch component with mappable Selector input, as opposed to a gray Selector input in the current switch. I think this can currently be done via a hierarchy of Blend components, but having a dedicated component would make this easier.
  Details E-Mail
Vladimir Golovin
Administrator
Posts: 3314
Filters: 55
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:

  Details E-Mail
Crapadilla
lvl 52 Filter Weaver and Official "Filter Forge Seer"

Posts: 4360
Filters: 65
Quote
Vladimir Golovin wrote:
[...] you can include a subtree that parametrically produces any number of particles, of any shape or form.


What if the subtree for each particle was different (i.e. they are not parametrically produced variants of a single sub-tree "procedure")?

Will there be a "particle selector" slave that feeds a "particle switch" component (which would possibly be polymorphic, because of variable number of map inputs)?

What about per-particle Chance?
--- Crapadilla says: "Damn you, stupid redundant feature requests!" ;)
  Details E-Mail
Vladimir Golovin
Administrator
Posts: 3314
Filters: 55
@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.
  Details E-Mail
Vladimir Golovin
Administrator
Posts: 3314
Filters: 55
@Dilla: Regarding the implementation of Chance using the Map Switch / Bomber+ combo, you can plug Bomber's Randomizer slave into the Selector, which will get you a uniform probability distribution over the Source inputs being used (limited by Max Source), each of which can have a completely distinct subtree.

To modify the distribution, you'll need to modify the Selector signal you feed into this component. For example, running it through a Tone Curve / Bias combo will let you bias the probability distribution towards higher or lower Sources.
  Details E-Mail
Crapadilla
lvl 52 Filter Weaver and Official "Filter Forge Seer"

Posts: 4360
Filters: 65
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. smile:beer: smile:loveff:

It occurs to me that chaining/nesting particle switches should provide enough "room" for all my "expansive particle set" needs.
--- Crapadilla says: "Damn you, stupid redundant feature requests!" ;)
  Details E-Mail
Crapadilla
lvl 52 Filter Weaver and Official "Filter Forge Seer"

Posts: 4360
Filters: 65
@Vlad:

So currently you've shown ElementID and Octave data being exposed via the Bomber+ slaves. What other data do you plan to include?
--- Crapadilla says: "Damn you, stupid redundant feature requests!" ;)
  Details E-Mail
Sphinx.
Filter Optimizer

Posts: 1587
Filters: 38
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? smile;-)

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

Posts: 9735
Filters: 33
Thanks for the news and showing it, good to know

As I personally understand all the technical parts that has been put here and how this new bomber slaves will be able to help I would like to ask

What benefits and advantages will bring the new bomber+ with slaves?

What thing can be able to do with bomber+ that was not possible before?

How will it change the way the bomber is used?


Thanks for any help and hope is it explained less technical that it is usually done.
  Details E-Mail
Ramlyn
Ramlyn

Posts: 1870
Filters: 312
Just wondering... Will the new bomber be faster than the normal one?
  Details E-Mail
Vladimir Golovin
Administrator
Posts: 3314
Filters: 55
@Dilla re: Other data to expose via slaves: I thought about this a lot, but at the moment I can't come up with anything reasonable other than Particle ID (exposed via Randomizer slave) and octave / layer (exposed via Layer and Normalized Layer slaves).

@Sphinx re: Slaves for particle-level data: At the moment we don't plan to add slaves for exposing things like actual particle rotation, actual particle scale etc. This can be done, but the complexity / usability ratio seems to be low for these slaves.

@Ramlyn re: Speed: No, I don't think the new bomber will be radically faster. Maybe there will be some very minor speed improvements due to the fact that we removed fixed-function logic for tint, chance, particle switching etc, but I wouldn't expect anything drastic.

@SpaceRay re: Benefits vs the old bomber: Any number of particles instead of just 5; each particle can be customized / randomized individually, and such customization may depend on particle center, rotation, scale, squash and the internal layering of particles within the bomber. To achieve all this, you need to use the new slave components, that's why we're releasing it as an advanced version of the basic bomber.
  Details E-Mail
Vladimir Golovin
Administrator
Posts: 3314
Filters: 55
New slaves + Map Switch in action:

  Details E-Mail
Vladimir Golovin
Administrator
Posts: 3314
Filters: 55
Quote
Vladimir Golovin wrote:
@Dilla re: Other data to expose via slaves: I thought about this a lot, but at the moment I can't come up with anything reasonable other than Particle ID (exposed via Randomizer slave) and octave / layer (exposed via Layer and Normalized Layer slaves).


Quote
Vladimir Golovin wrote:
@Sphinx re: Slaves for particle-level data: At the moment we don't plan to add slaves for exposing things like actual particle rotation, actual particle scale etc. This can be done, but the complexity / usability ratio seems to be low for these slaves.


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.)
  Details E-Mail
Betis
The Blacksmith

Posts: 1207
Filters: 76
This is gonna be so rad, Vlad. smile:-p
Roses are #FF0000
Violets are #0000FF
All my base are belong to you.
  Details E-Mail
Crapadilla
lvl 52 Filter Weaver and Official "Filter Forge Seer"

Posts: 4360
Filters: 65
Quote
Vladimir Golovin wrote:
I'm exposing the actual center of the particle after all offsets and chaos via Center X and Center Y slaves


I'm really hoping this will help with a little issue I've been having... smile;)
--- Crapadilla says: "Damn you, stupid redundant feature requests!" ;)
  Details E-Mail
Sphinx.
Filter Optimizer

Posts: 1587
Filters: 38
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..
  Details E-Mail
Skybase
2D/3D Generalist

Posts: 3895
Filters: 74
I was wondering about tint.

Would it be like XY coords from a bomber --> Lookup hooked up with some input --> blend with a the particle image--> bomber?
  Details E-Mail
Sphinx.
Filter Optimizer

Posts: 1587
Filters: 38
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
  Details E-Mail
Vladimir Golovin
Administrator
Posts: 3314
Filters: 55
It worked.

There was one thing that bothered me about bomber slaves, namely that the particle customization was basically limited to randomization. The new Center X and Center Y slaves fix this by letting you create customizations that aren't based on randomness:

  Details E-Mail
Vladimir Golovin
Administrator
Posts: 3314
Filters: 55
@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:

  Details E-Mail
Sphinx.
Filter Optimizer

Posts: 1587
Filters: 38
Sweet! That currently requires two bombers to achieve.

Will you be adding a Depth / Layer Index slave too? (i.e. what you draw from the Depth Map input)
  Details E-Mail
Sphinx.
Filter Optimizer

Posts: 1587
Filters: 38
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..
  Details E-Mail
Vladimir Golovin
Administrator
Posts: 3314
Filters: 55
Quote
Sphinx. wrote:
so if you remove Tint, but don't implement all particle level input properties as slaves, then you limit the actual possibilites..


Quote
Sphinx. wrote:
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


Plug the new slaves Center X and Center Y into a Lookup, and plug "the same input as you use for some other particle property" into Lookup's Source input. See my examples in this thread. Simpler and cleaner than the trickery with Tint.

(Or am I missing something?)
  Details E-Mail
Vladimir Golovin
Administrator
Posts: 3314
Filters: 55
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:

  Details E-Mail
Vladimir Golovin
Administrator
Posts: 3314
Filters: 55
Another cool trick with the Rotation slave: despite the fact that the particles are randomly rotated (via Chaos), their fill pattern always stays vertical. That's because the particle rotation is compensated by rotating their pattern backwards by the same amount (get the rotation via the Rotation slave, then subtract it from 1.0):

  Details E-Mail
Vladimir Golovin
Administrator
Posts: 3314
Filters: 55
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.
  Details E-Mail
Vladimir Golovin
Administrator
Posts: 3314
Filters: 55
Speaking of the general strategy for exposing bomber data via slaves, we want to expose only thosee per-particle data that are calculated inside the bomber, and cannot be replicated outside of it.
  Details E-Mail
Sphinx.
Filter Optimizer

Posts: 1587
Filters: 38
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 smile:D

Perhaps data related specifically to the octaves?
  Details E-Mail

Messages 1 - 45 of 120
First | Prev. | 1 2 3 | Next | Last 

Join Our Community!

Filter Forge has a thriving, vibrant, knowledgeable user community. Feel free to join us and have fun!

29,333 Registered Users
+5 new last day!

137,525 Posts
+18 new last day!

13,400 Topics
+13 new in 7 days!

Online Users Last minute:

8 unregistered users.

Recent Wiki Edits:

Follow filterforge on Twitter