Bomber Improvements

Quote
Perhaps data related specifically to the octaves?

Which ones exactly?

this Bomber+ will not appear in any beta version, and will only be available in the final version of FF 5.0 sometime next year?

If this is complex as it seems, and can have multiple combinations of components, I think it would be better to test it first and see if there could be some bugs so when releasing the final version is good and well done.

Quote

Vladimir Golovin wrote: @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.

Thanks for the answer and details, it looks very interesting and useful, specially that you can use ANY number of source particles instead of 5, I really wanted to have that as you can build more things with more source images.

(In other news, for Bomber+ we increased the maximum Density from 5 to 20).

i wonder that if the new bomber+ is going to have lots of possible source images, the PROBLEM I See is HOW TO LOAD these images into bomber+?

You have to load 25 images, one by one in each setting slot? So you have to open 25 times the image selection? This would be awkward, boring and time consuming, at least for me

And as Skybase said, if you would want to have 100 images, you would die before filling the 100 images slots by hand

I can think that there could be a way for the filter to be able to SEL ECT A FOLDER and load all the images that are inside into each image slot of bomber+ so you would not have to load them yourself by hand.

They would be loaded in the order that they are found in the folder, so first image goes on the first slot, second image, second slot filled, and so on.

I do not know how difficult it could be to do this, but be able to pick files fr om a folder I think it can't be too difficult to include

Since there's no more "Tint", does that mean the Bomber+ is HDR-out (no separate HDR mode)? (Your example images don't show the yellow lines for HDR inputs/outputs, I'm assuming the developers just haven't gotten to that part of the UI yet )

About the slave components: The loop slave components are visually useful since you can preview their output with the "Iteration (preview)" slider. But bomber slave components don't show any useful information because the bomber displays all of the particles at once. You don't need a "particle preview". It's just that seeing FF render a black square for each slave component can only confuse the user.

For example, the rotation slave could look like this (notice the change in the downstream tone curve as well). Now we can clearly see how particle color = f(rotation).

Quote
Vladimir Golovin wrote: Dilla, and everyone, can you come up with any other data you'd like to be exposed via slaves?

What about Total Element Count? I assume ElementID outputs "HDR" integers, so its output would be hard to normalize without knowing the element total. On second thought, maybe the slave's Output Mode already does that?

Quote
SpaceRay wrote: i wonder that if the new bomber+ is going to have lots of possible source images, the PROBLEM I See is HOW TO LOAD these images into bomber+?

We'd probably need a specialized Color Control component to automate that: It would read fr om a numbered/frame-padded image sequence (as opposed to a single image like Color Control does) and choose its output according to the ElementID signal attached to its Selector input.

That way, you only need to point FF to a path and filename once and be done with it.

Also, such a component could open up FF for all sorts of artistic possibilities wh ere you're "condensing" a multitude of input images (or an animation) into a single output image.

(Actually, I have an idea for another slave component for Bomber+, with an interesting use case, but I need to validate it first.)

Quote
Vladimir Golovin wrote: The preview of slave components isn't just an arbitrary icon, it's a real example of what the slave would output...

After thinking some more, I see what you mean. In retrospect, my mock-up is much more confusing, especially when multiple slave components are involved.

Quote
The new Center X and Center Y slaves fix this by letting you create customizations that aren't based on randomness

Control!

Quote
Crapadilla wrote: Along the same lines: What about particle spin, i.e. the difference between a particle's "resting" rotation and "current" rotation value.

Isn't this precisely what the Rotation slave outputs?

Quote
Crapadilla wrote: Hooking those two values up to blur components in a particle's subtree for some motion blur effects? Viable?

Unfortunately, not viable due to the implementation of slave components: bitmap-based components kill metadata needed by slave components, so you can't use them in the subtrees between slaves and slave-accepting inputs.

Uhm... sudden thought. Can you nest a bomber in a bomber? That kinda sounds like ridiculous but it sounds like a potential issue.

Skybase, they should nest perfectly fine. Bomber slaves use the same underlying infrastructure as Loop slaves, and Loops can be nested, see the Nested Loops section: https://www.filterforge.com/features/v...sions.html

And since bomber is not recursive, I don't think there will be any limitations to nesting - though I'll need to check that.

(Note to myself: include an example of nested bombers into the release article and help).

Speaking of usage cases:

Does this mean that the slave components outputs will be generalized, i.e. you'll be able to plug a (compatible) Bomber+ slave component into a Loop input?

And would it make any sense to do so, meaning would the slave component of a Bomber+ be able to send a different output to a Loop input for each loop, or would it just use the first (or last) Bomber+ slave output value?

Quote
Crapadilla wrote: Looping a Bomber, then feeding the result into a Bomber+ whose slaves parametrically modify the Loop...

Head...Spinning...Looping.

I wrote below in the quote that the new bomber+ will not be limited to the 5 source images, so then I think I could use now the WHOLE excellent ThreeDee Alphabet awesome letters or this other lovely and well done ThreeDee alphabet to feed the bomber+, so then I could include all the 26 letters at once.

Would I then have to put a slave for each source letter? or how it would work?

So, if thi sis possible I could update my Alphabet creator filters

Quote
Crapadilla wrote: Looping a Bomber, then feeding the result into a Bomber+ whose slaves parametrically modify the Loop...

Infinite Creativity explosion

Quote

Crapadilla wrote: Quote SpaceRay wrote: I wonder that if the new bomber+ is going to have lots of possible source images, the PROBLEM I See is HOW TO LOAD these multiple images into bomber+? one by one would be boring and tiresome if you have 25 or 40 We'd probably need a specialized Color Control component to automate that: It would read from a numbered/frame-padded image sequence (as opposed to a single image like Color Control does) and choose its output according to the ElementID signal attached to its Selector input. That way, you only need to point FF to a path and filename once and be done with it. smile:) Also, such a component could open up FF for all sorts of artistic possibilities wh ere you're "condensing" a multitude of input images (or an animation) into a single output image.

Thanks very much for your answer, I think that would be really good to have a new color control that could read automatically from a feed source, and that you could load them without having to do it manually one by one. If I had to load 40 images one by one manually in each color control, it would be awkward, boring and bad.

Let´s hope that Vladimir can think something about this.

Quote
Vladimir Golovin wrote: (In other news, for Bomber+ we increased the maximum Density from 5 to 20).

Sorry to ask this maybe silly question, but if bomber with Density 5 is already much crowded and have lots of particles, what would be at value 20? Or the density has been made more fluid and with less amount in each one?

Quote
Would I then have to put a slave for each source letter? or how it would work?

Based on what I can tell from the screen caps we have so far you basically would be nesting a couple of those new switch components with a random slave from the Bomber+.

-- Am I even right on that? Kinda making assumptions from those images that were posted.

Quote
Skybase wrote: Based on what I can tell from the screen caps we have so far you basically would be nesting a couple of those new switch components with a random slave from the Bomber+. -- Am I even right on that? Kinda making assumptions from those images that were posted.

If the task is to make 26 different kinds of particles within a single Bomber, each of which is formed by a separate subtree, then yes, you first implement a 26-input switcher using any approach (for example via a hierarchy of Map Switches) then you plug a Bomber+ slave into its Selector input.

Quote
Crapadilla wrote: It looks like the Bomber+ slave's output changes per particle ID called, while a Loop slave's output changes per Loop iteration.

Exactly. A slave component outputs different values depending on some aspect of its master component. A Loop slave output depends on the loop iteration, a Bomber+ slave output depends on the particle ID, a Result slave depends on the pixel coordinates, a Perlin Noise slave depends on the octave, a Bricks slave depends on the brick ID, etc etc.

Quote
Crapadilla wrote: It should be possible to hook up a Bomber+ slave into a Loop, but I'm guessing that - for a given particle ID - the slave's output will remain constant during all iterations of the Loop. In essence, it looks like the Bomber+ will only be able to modify the Loop once per particle ID call, but probably not per iteration (since iteration is internal to the Loop).

What you said above is correct: in the attached example the color of each sun thingy (provided by Bomber's Randomizer) stays the same for each Loop iteration:

Learnability of slave complnents and their relationship with their master is an important thing. Slaves are just too powerful to be relegated to the domain of Filter Forge academics dwelling in their ivory towers. We need to find a way to explain them to users, preferably via some user interface aids, rather than via help pages. Any ideas on how to explain them better?

One of the things that needs explaining is the fact that slave components should be connected to the subtree of the relevant slave-accepting input. For Loops, this wasn't a problem because a Loop has only one input and you simply had no choice but to plug the slaves into the right subtree. But with Bomber+ (and hopefully other masters we'll release with FF5.0) the situation is different: for example in Bomber the only slave-accepting input is Particle, but there is a lot of other inputs. How do we explain to the user that the slaves should (must?) be connected to the subtree of Particle?

Dilla, the problem is not related to loading of multiple images, that is an UI / UX problem. The actual problem lies in feeding the loaded images into other FF components. I would not like to limit this thing to just Bomber+, I want it to be fully general.

Quote
As I understand it from your answer Vladimir, you are telling a way to input ONE LETTER sel ected fr om the 26 available? Why would I need to use a input switcher?

So basically for each time a particle is called, a letter is sel ected at random fr om a bank of images. [am I right?]

Imagine asking the guy next to you for the next picture to load at random. You're the bomber, he's the selector. You're saying "hey, I want the next image, here's a random number." and the guy says "yeah, here's the image corresponding to that number" and you pick that up and you ask again for however many times necessary.

Quote
Crapadilla wrote: So you're envisioning a more generic system were all FF components would be capable of accepting lists of colors/images? For example, in that system, 3-Color Gradient and 5-Color Gradient would be replaced by a generic N-Color Gradient that would adapt to whatever the incoming list of colors/images would be?

Yes. Ideally, I want a fully general system where the generality level is more comparable to that of full-blown functional programming languages than to simple dataflow languages such as Filter Forge and other similar node-based tools.

Quote
Crapadilla wrote:As in: What would the Color Control's output be if I connected it to a component outside of the Loop / Bomber+ structure?

In my ideal system, you could connect a List of Colors only to inputs that accept List of Colors. You couldn't connect it to a plain simple Color - to do that, you'd need to extract one element from the List of Colors first, using any extracting method you want (access by specific element number, the last one, the first one, the biggest one, the third from the left etc). That is, you'll need a component that takes List of Colors and outputs a single Color.