The Slave Component Paradigm

With the release of FF4 and its Loop component, we've all been witness to the birth of a new type of component: the Slave. Then came Beta5, and it brought slave-based pixel-awareness plus an interesting discussion about how Bomber+ will conduct its very own breed of extensive slavery.

With slaves becoming firmly established as an entirely new paradigm inside FF, I'm thinking it is time to start discussing this system with the goal of wrapping our heads around its potential applications, its possibilities and future prospects.

So what are Slaves?

Quote

- Slave components are permanently linked to their master and cannot be detached. - Slave outputs should be connected to the subtree of their master component, otherwise they will have no effect. - Some master components cannot work without their slave components. - A slave component's output changes depending on the current "iterative stage" that its master component is in. Examples: 1. The current Loop iteration -- FF4 Loop component. (see Loops and Recursions). 2. The pixel coordinates currently being rendered -- FF5 Result component. (see Pixel-Awareness). 3. The current particle's ElementID -- FF5 Bomber+ component. (see this discussion).

That's three distinct cases of the Slave component paradigm at work, each time operating in a slightly different iterative context. That begs a few questions: What is the potential reach of this new system? And where will it go fr om here?

Quote
Vladimir Golovin wrote elsewhere "Eventually we'll introduce slaves wherever they make sense."

The Question is: WHERE do they make sense? I've been thinking about this lately, but I'm still finding it hard to what other components might benefit fr om "slavification".

Quote
Vladimir Golovin wrote elsewhere "Another direction for improvement is making other components slave-friendly."

This reads like the new paradigm could potentially have far-reaching consequences for all of FF's components.

Quote
Vladimir Golovin wrote elsewh ere "The obstacle to such wider introduction of slaves is that the GUI is currently lagging behind."

I get the feeling that Vlad has thought about this extensively, and that it's a direction he's planning to take FF.

So, with the wall-O-text critical damage threshold most definitely reached, I'll cut it short and write: Let us speculate!

So, slave components are used to control iterations? Then, any component that iterates something can have slave components.

For example, the Multiblend component currently operates on 7 sources. But it could operate on any number of sources, and each layer could have its own opacity and blend mode. So, there would be a "layer" slave, which outputs the integer value of each layer (1st layer = 1, 2nd layer = 2, etc.). But honestly, can't we already do this with a Loop?

Polygon (and Free Polygon) uses discrete points for the corners of the shape. How about a Polygon+ where we can control the location of each point, and the shape gets auto-filled? Like this filter, but with straight edges? Then there would be a "point ID" (point count) slave.

As an extension of Polygon+, how about a line-drawer?

Or heck, ThreeDee's filter as a component! Bezier+!

3-Color (and 5-Color) Gradient: How about an n-color Gradient? Here, the slave would be "color index" or whatever you want to call it. Useful for people who don't have Photoshop.

Bricks, Pavements, and Tiles... do they have particles like the Bomber? Something tells me, no.

Worley noises (blocks, cells, etc.)... they work by generating discrete points, and then calculating the distance from those points. But then, we can already replicate worley noise with the Bomber, with more control...

Quote
Indigo Ray wrote For example, the Multiblend component currently operates on 7 sources. But it could operate on any number of sources, and each layer could have its own opacity and blend mode. So, there would be a "layer" slave, which outputs the integer value of each layer (1st layer = 1, 2nd layer = 2, etc.). But honestly, can't we already do this with a Loop?

This would be very good to have an improved multiblend with any number of sources AND be able to have it's own custom configuration blend mode layer, cool

Would this be possible with a Loop component?

Missed this one...

Noises, Noise gradient and Noise Distortion
The internal combination of internal layers/octaves could be useful to promote as slaves. It will allow for different curves and textures per octave..

Quote
Vladimir Golovin wrote: Bingo

You forgot to quote the script part

Quote
Sphinx. wrote: since most components have several fixed gray inputs, it would be rather useful to be able to post back these values through slaves

Rather than doing this, which would add even more ugliness to an already ugly system of gray components / inputs, I'd look for a way to make the gray stuff more palatable.

I recently had a radical idea about turning gray inputs into green ones by adding to each previously gray input a remapper that would specify the method of rounding, e.g. round, ceil, floor etc. Obviously, some of the gray inputs that are used for defining precalculation stuff will stay gray, but I guess that many others can possibly be greenified by this method.

I'm far from understanding all implications of this idea, though.

Uh, I'm not sure I understand what you mean. Please clarify.

Quote
Sphinx. wrote: the final value

1. How do you get the final value for Bomber's particle ID, given the fact that it has an infinite number of particles, and there's no way to predict which particles will end up getting sampled during the rendering and which ones won't?

2. If you have just a single fixed value as the preview for the slave, then how do you debug the subtree between the slave and the master? How will you see the reaction of the subtree to various possible inputs?

3. Given your idea, how would the preview for Loop slaves look? Would it just output the number of the last iteration / the random number corresponding to the last iteration?

What would you say to having a checkbox that DID have the noise sample texture per-octave. It is probably slower but if it was optional, or implemented as a Noise+ component, I think people will intentionally make that decision. Unless it's not really possible?

Isn't all of this Slave-logic a big rewrite and rethinking though?

Quote
Vladimir Golovin wrote: I recently had a radical idea about turning gray inputs into green ones by adding to each previously gray input a remapper that would specify the method of rounding, e.g. round, ceil, floor etc. Obviously, some of the gray inputs that are used for defining precalculation stuff will stay gray, but I guess that many others can possibly be greenified by this method.

Wow. So if we take Perlin Noise as an example, does it even make sense to "greenify" gray inputs like Scale, Stretch, Angle, Details or Variation? If these inputs were map inputs, they would certainly need to be mapped with great care so as to not produce any discontinuous or nonsensical results.

Furthermore, would the method of rounding be hard-coded, or would you expose that setting to the user? (thus making the component UI much more complex by creating an additional control per "greenified" gray input.)

Also, what about out-of-range handling? If OOR-behaviour is not hard-coded, then we would end up with yet another control on the UI, no?

On the other hand, we already have all the necessary RGB math components (Round, Ceil, Floor, Min, Max) to correctly "massage" the data going to these greenified inputs, do we not? So this could also be taken care of by the advanced user.

Quote
Vladimir Golovin wrote: So, to recap, the dilemma is more power versus less sensible behavior of randomly made connections for a novice user.

Since I never make connections randomly, I'll cast my vote for... the 'more power' side of things.

Edit:

What about an "Advanced" mode for all components, like you did with Result (or with LDR & HDR Bomber)? Toggle it on, and the dilemma-free novice components become fully pimped-out advanced components that sport the new "greenified" map inputs.

I HATE modes, but I was thinking about some kind of a safeguard against making nonsensical random connections. Advanced Mode seems to be a good candidate for that role...

Edit: this would solve another problem with greenification. Greenified components will generally be slower because the stuff that was precalculated during the Prepare step is now calculated for every sample, since the inputs are now green. Advanced Mode would allow a deliberate choice between speed and more power.

(But I still hate modes.)

Quote
Skybase wrote: So basically, for each iteration, pick an image from a list, and blend? How do we choose the image? Huhm...

I also wonder how it will work this of picking an image from a list.

Will there be a new list component?

How would the list be built?

Would be able to make a list with images taken from a folder?

Some follow-up thoughts on mass greenification:

1. Checkbox inputs should be easy to greenify. Just make them mappable, with a single fixed (non-adjustable) rounding logic: clip any HDR into 0..1, or just make the input LDR-only, then Round. This way they should behave pretty nicely even when a newbie connects random stuff into them. Darker zones mean that the checkbox is off, brighter zones mean that the checkbox is on. Pretty visual and self-explaining. We should be careful with the AAZones though, as the new rounding code will inevitably introduce additional AAZones.

2. Same with Lists / Dropdowns. They will accept HDR input via a single rounding logic: they will Round the incoming HDR value to the nearest integer. Ranges: Black (and any negative value) to 0.5 means Item #0, 0.5 to 1.5 means Item #1, 1.5 to 2.5 means Item #2, etc. Any out-of-range signal is simply clipped, i.e. means the Last Item. The need for HDR signal will protect such inputs from newbie-induced randomness: if they plug a simple non-HDR signal into such input, they'll just get zones for Input #1 (black to half-gray) and Input #2 (half-gray to white). Again, pretty safe, pretty visual and self-explaining. And again, we should be careful around new AAZones that will be introduced by rounding.

3. Technically, greenifying Slider / Angle / Spinner is trivial. The only obstacle here is newbie-friendliness / sensibility of random connections. Take, for example, the Rotation and Size sliders in Perlin Noise. Edit: They don't even need to be greenified because we already have their green counterparts: standard map inputs!

(A note on remappers: all these greenified inputs should have the same remappers as their gray counterparts, in case when we connect a gray control to these newly green inputs.)

To sum up, I see no obstacles to greenifying applicable (i.e. not involved in Prepare-stage precalculation) Lists and Checkboxes, but I'm not yet sure about greenifying the rest of gray controls, mostly due to newbie UX reasons.

(And I still think that modes are ugly.)

Open problem with greenification: how to deal with established / idiomatic controls such as Repeat (usually IntSlider 1...100) and Variation (always IntSlider 1...30000)?

In case of Repeat, the 1...100 range limitation is arbitrary, and in most cases it can be increased if not removed altogether.

The case of Variation is more complicated. On one hand, the 30000 limitation is arbitrary as well, and it can be removed. On the other hand, Variation is often involved in pre-calculation that happens before sampling begins, and in many cases it can't be greenified.

The question is, if we can greenify Variation in some cases, but cannot in other, should we have some components with greenified Variation, while leaving others with gray Variation?

Just curious. Why do you hate modes?

Before this thread was greenified the topic was slave components..

So what hinders slaves fr om being used to generally provide additional special purpose outputs? I.e. instead of thinking them as something that has to be plugged in somewh ere down the source side of things, it may simply be thought of as the possibility to provide additional outputs. So will that angle change things?

For the script I definitely think this has potential - with several of my scripts I wanted to output more than three "channels".

I guess many other components have interesting "free" stuff to output..

Quote
Sphinx. wrote: So what hinders slaves fr om being used to generally provide additional special purpose outputs? I.e. instead of thinking them as something that has to be plugged in somewh ere down the source side of things, it may simply be thought of as the possibility to provide additional outputs. So will that angle change things?

I think channels should be done as channels. Or perhaps as multi-output components. The concept of Slaves is, in my opinion, completely orthogonal to the concept of channels, so I'd prefer not to mix the two.

I have just seen this thread, and wonder if all these will be going further or not

Quote
Vladimir Golovin wrote: Greenification also opens the possibility for adding new control components, such as Mapped Checkbox, Mapped IntSlider, Mapped Angle, Mapped List etc., for use in filter interface, groups inputs and script inputs, but I'm not yet sold on this idea.

One thing I would love to have is slave-components for image-accepting control components (i.e. Color Control and Grayscale Control).

Example: In my Chalk-a-Dilla filter, I implemented a "custom default image" for the Source Image input (see attached image). However, the control logic for this requires a Switch setup using 2 control components - a Color Control (user image input) and a Checkbox Control (for toggling between default/user image).

Now, if the Color Control had a slave component that would output its "image load state" as a boolean value and that component was connected to the Switch's greenified Selector, this setup would just have ONE control, and thus be much less confusing to the user.

In principle, this is similar to the 'Override' feature that was redacted from Color Controls when support for multiple images was first introduced to FF, and I would love to have it back in a different (more elegant) form.