Bomber Improvements

Quote
Vladimir Golovin wrote: you'd need to extract one element from the List of Colors first, using any extracting method you want

And what's more, the list extraction components, ideally, should be polymorphic. That is, they would not just work on List of Color, but on List of Anything - of Curves, Strings, Integers or whatever else. In Haskell, the type signatures would look like this:

Code
--The bad non-polymorphic version getLastElementFromList :: [Color] -> Color --The good polymorphic version getLastElementFromList :: [x] -> x

Edit: whoops, I forgot that lists can be empty, and that we can't extract anything from an empty list

One more slave (actually two) for Bomber Plus: Corner X and Corner Y. They output the X and Y coordinates of each corner of the particle in world space. In this example, I sample the color of the source image (lifesaver) at each of the four corners of the particle, and use a custom-made 4-point gradient to fill the particles. This approach can be used to create painterly effects:

Quote

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

Maybe there should be some visual cue that distinguishes slave-accepting inputs from regular ones. For example, slave-accepting inputs could be marked by a little feedback loop icon immediately to their right (but still left of their input name).

Also, if a master component requires a closed slave connection to work (such as Loop), you could give all connecting pipes between the master and slave components a red color plus an additional "!" icon for as long as the feedback loop is not closed properly.

You could also color pipes red if the connection is made in a wrong way (i.e. a slave connected to a non-slave-accepting input), and hovering over/clicking the "!" would present further details on the erroneous connection.

Same filter as I posted before (particles are colored by a gradient between 4 colors sampled at particle corners), but I added a custom profile to the gradient. Looks cool:

Checking our current set of Bomber+ slaves against some older feature requests for the Bomber...

Here's one by uberzev: "Fog" option for bomber

This issue appears to be solvable with the Octave slave, right?

Following the Skybase quote below I wonder if

COULD BOMBER+ HAVE LESS PERFOMANCE AND SLOWER THAN OLDER BOMBER???

If the new bomber+ will have only one single input, and it will be able to have infinite sources that will feed this one single input, could it happen that it will be slower than the normal bomber that has 5 source input?

I mean that there could be a perfomance bottleneck problem, if there is 25 (or more) sources and only one input, and it depends all on a input switcher to control the flow of the inputs one by one.

Why not keep using the 5 input of the previous bomber? so it could rise the flow of incoming data from the slaves.

Quote

Skybase wrote: Quote SpaceRay As I understand it from your answer Vladimir, you are telling a way to input ONE LETTER selected 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.

Thanks for the answer, and is well explained and understand it well this way, but I prefer the first answer you have put (and deleted) that is simpler, Bomber+ only has ONE input. so then you of course need to have a input switcher because there is only ONE input and can´t input more than one instruction each time.

What you have written, remembers me of how it was explained the single and multicore CPU chips with cars waiting in a queue to enter the processing and a "police" controlling the traffic

Among all these talks......

Just now I'm making a filter with a complex particle and a bomber.
It asks me to use a particle adapter..............
Hufffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff

BEFORE OF ANY OTHER IMPROVEMENT TO THE BOMBER, THIS SHOULD BE THE FIRST.

Sorry.
It is really not not not nice that, every time we use a bomber, we have to check if a particle adapter is needed or not.
It is really boring and uneasy.
Why isn't included in the bomber itself???

Please, can you make the components being able to be connected with a bomber without that we have to worry where a particle adapter is needed?
THANKS

I have no idea what the other people thinks, but for me it is a problem.

Quote
Ramlyn wrote: Why isn't included in the bomber itself???

It is a limitation of the Image component, not the Bomber. You can use Image 2.009 that doesn't require a Particle adapter.

Ramlyn, this happened to me too that when making some filters it tells me that it requires particle adapter AND even adding it, it STILL was telling me that is was required, and I thought it was a bug, and it was not, it was that it must be positioned correctly in a specific place

Please see this thread and maybe will help you to understand how to use the particle adapter with bomber

FF 4.0 Particle Adaptor WRONG warning with shapes and bomber?

Although be aware that using groups with particle adapter is not as easy as it may seem

To SpaceRay : yes, I'm aware of that. The particle adapter must be added just after the component that requires it, otherwise it doesn't work.
It would be nice if in the new bomber we hadn't to use the particle adapter.

Quote
Crapadilla wrote: ... which presumably would require a rewrite of the whole FF component infrastructure that could take several months? Years?

Yes, years, if not decades

(On the other hand, getting from zero understanding at all to a working type-checked visual node-based prototype took us less than a year, so far).

Quote
Loading lists of images into FF

The one thing I don't want this turning into are filters with 100s of inputs with ridiculous amounts of options etc etc. I personally think that's just a silly filter. It's a cool concept but it should be approached with care... if it were to be done that is.

Quote
Skybase wrote: Quote Loading lists of images into FF The one thing I don't want this turning into are filters with 100s of inputs with ridiculous amounts of options etc etc. I personally think that's just a silly filter. It's a cool concept but it should be approached with care... if it were to be done that is.

As far as I know from what I have understood from the lists and images is that the inputs for images with a list would not appear in the settings, although I may be wrong.

I agree that it would be silly to have ridiculous amount of options and is not good.

Also I think that this kind of filter could be also done in a private and personal way, without having to share and make it public in the forum or FF library, so is only a problem for the author and not anybody else.

Quote
SpaceRay wrote: YES!! This would be really interesting and useful to be able to load lists of images from a defined source to be feed into the bomber+

To avoid possible confusion, what I mean with this is that a way to load automatically from a defined folder of images (maybe easier to load all the images inside the folder instead of selecting individual ones) into the list and then feed it into bomber+ and the inputs of images would not appear in the settings panel, or maybe only once.

The order of the input of the images would be the same as the order found inside the images folder

I'd like the particles having color+alpha+depth (fr om exr files for example) being Z combined properly with anti-aliased edges wh ere one particle intersect another.

Like what Zcombine node in Blender do.

https://www.blender.org/manual/composi...mbine.html



Actually would be nice to have proper depth combining in regular blend node too.

This seems to be interesting, and I agree that it would be good, but maybe I think that any bomber improvement may be only for FF 6 and not available in any update of FF 5, and I wish I would be wrong,