Bomber that would depth Z combine particles?

Do someone have an idea how to make kind of "deep composing" from Nuke on Bomber
particles?
I mean not just sort flat particles in a stack like what Bomber can do with its depth input currently but rather use particles own depth grayscale pairs to then have them intersecting with each other properly.

That's the easy part. But what about masking colors so particles colored differently would intersect to each other properly. Like what Zcombine node in Blender, or Merge node in Fusion do.

In fact we would need to generate a mask for each particle based on its depth intersection.
I already broke my head trying to figure out how to do so.

Maybe not each particle but each layer of them at least.

Thanks for interesting example but looks like the color comes from random tint values while I want to scatter particles with existing color values. Fragments rendered in Zbrush paired with their depth companions. Not just randomly tinted.

The bomber does make correct depth based masking for the different tints. It makes an impression it could probably do the same for particle own RGB colors somehow.

Oh, I think I get the idea. Thank you very much.

Looks like itself Bomber doesn't make any sophisticated particle masking at all. Saturation and hue separations do.

How to do so for every single particle when the color info has varying hue and saturation within a particle picture is still a mystery for me.

Here are some tricks with the bomber - check out the internals: there are many different "auxiliary" outputs which you then can use with Lookup, Offset etc to map colors from an image.

(note: the filter does nothing interesting on the front end side of things.. open it up and take a look)

Bomber Tricks.ffxml

Thanks a lot, Sphinx for interesting examples. I does learn a lot from them. But It's not exactly what I am looking for.

I guess you are trying to re-map same image to each and every particle in the first example and re-color particles according to input image XY coordinates in the second one.


I want to scatter a number of rendered pictures of stones having already each own color/alpha plus corresponding depth image . And I want it be scattered the way they would intersect each other. And not to re-color them but rather have them using it's own color info

Perhaps I am still missing something?

Quote
How can stones intersect?

Same way stars in your example do with only difference each stone is not taking the tint from some third picture but rather uses its own untinted color picture.

https://www.dropbox.com/s/kah5rapiuwkq...s.jpg?dl=0

Here is a stone example png+alpha
https://www.dropbox.com/s/880e21bwv2dv...1.png?dl=0

and its depth also with alpha
https://www.dropbox.com/s/ngv3w7auwbgs...h.png?dl=0

A second stone
https://www.dropbox.com/s/xpyg58ml30mz...2.png?dl=0

its depth
https://www.dropbox.com/s/xbuhvzknvucw...h.tif?dl=0

An example

The output (I'm just playing a bit with the possibilities here)

Btw I had to get rid of those minute alpha changes - the limitation of this concept is that the bomber rendering has to be opaque - otherwise you get coordinate "spill" and what not from other particles. Use several bombers to get alpha-blendable layers, if it is important.

How does this "black magic" work?
The idea is simple: since the bomber runs in HDR mode, it is easy to combine integers and fractions using the math components.

To get the lighten combining correct, the main integer signal is carrying the "depth map" of the particle. We simply replicate that value across the channels (but you could really process three particle variation layers at once here).

So the depth info goes in values 1,2..1000000 (or something), pure integers. To get a normal 0..1 range afterwards, we simply divide that by the large 1000000 value. Since it is reduced to integers using Floor, the fractional part i.e. 0..1 is available for another purpose: the x,y particle coordinates (either particle x,y or particle texture x,y as seen in the above examples). The red channel holds the X coordinates and the green channel holds the Y coordinates. The blue channel is available to carry other stuff, like e.g. a random value.

Temporary combined samples could then look like this:

R: 111121.345
G: 111121.045
B: 111121.000

Which means a depth integer value of 111121 (not normalized), a X value of 0.345 and a Y value of 0.045. The X and Y values are extracted by subtracting the integer part.

Thats pretty much it.

Well.. It is not like you can't do alpha blending at all; the limitation is only about *semi transparent* particles. Alpha channels with 100% opaque and 100% transparent (alpha = 1 or 0) regions are all good (that is why I had to hard mask those edges with the threshold). And if you have to do semi transparent blending, do it onto the particle before the bombing..

Post your progress and challenges here and I'll help out if possible ☺

Kirk, thank you for keeping up as we spout all this technical stuff. My understanding increases as I write this, so don't expect too much clarity from me.

My filter works the same way as Sphinx's, as far as hiding a decimal value for color inside a large integer for depth.

In Sphinx's filter, the bomber acts on a red and green gradient. The lookup component later "transforms" or "maps" red and green into X (left/right) and Y (top/bottom) of the image (of a rock, for instance). In my filter, the actual image is added before the bomber. It's not bombing "space", it's bombing the image, no lookup necessary.

Sphinx's filter also has a third channel (blue), which he chooses to use as a random number generator per particle. My filter doesn't have that feature.

You can use multiple images if you modify either filter, with only 1 bomber component. Well, ok, mine is limited to 5 images because there are 5 particle inputs. Any more, and you'd need more bombers, or if you are feeling adventurous and you own Filter Forge 5, you can use the new Bomber+ component.

Quote
kirkl13 wrote: It makes a little bit of black fringe although.

This is because of a bug related to alpha handling in FFs antialiasing functionality.

The workaround is easy:

Instead of specifying a black transparent "background color" use the same source as the opaque foreground/particles but set the alpha to zero using the Set Alpha component under the Channels category.

Your "Smooth" setting on the Threshold is also causing additional "bleed" of that black color. Try reducing it to zero.