Slave components are a special kind of components. They are permanently linked to their master component and cannot be detached. Their outputs should be connected to the subtree of slave-accepting inputs of their master component, otherwise they will have no effect on its output.
The key idea to understand about slave components is that their output changes depending on what their master component is rendering at the moment. For example, slaves of Loop change their output depending on the number of the current loop iteration; slaves of Bomber Plus change their output depending on the particle currently being rendered, and slaves of Result output different values depending on the coordinates of the pixel which is currently being rendered by the renderer.
To sum up, slave components expose some internal variables of their master components (e.g. number of loop iteration; or parameters of the current particle, tile or brick) to their subtrees, thus enabling the subtree to produce different output depending on the data from the master component.
The main benefit of slave component is to allow subtree customization per rendering element. This kind of customization is impossible without slave components. For example, using slave components in the subtree of the Particle input of Bomber Plus lets you customize each individual particle, based on its actual size or rotation, random numbers unique for this particle, or the coordinates of the particle center and corners. Similarly, in Tiles Plus, Bricks Plus and Pavements Plus, slave components allow you to customize each individual pattern element, i.e. brick or tile. And in the Loop component, you can customize the output of the loop subtree for each individual loop iteration, based on its number, the combined output of all previous iterations, and random numbers unique for that iteration.
Examples
This example uses three Randomizer slaves of Bomber Plus to assemble a random HSY color, which is then assigned to each particle:
The next example uses two sets of Randomizer slaves to assemble two random HSY colors (a warm one and a cool one) and another Randomizer for randomly switching between these two colors for each brick:
The final example uses the Position slave of the Loop component to define the rotation of the star depending on loop iteration. The Accumulated slave outputs the combined result of all previous iterations, which is used as a background for the current iteration, i.e. each new rotated star is painted over all previously painted rotated stars:
Using Slave Components
Slave components are created from their master’s properties
Slave components cannot exist separately from their master component, and you can’t find them in the Components bar. To create them, use the appropriate buttons in the properties of the master component, or copy / paste existing slave components.
In most cases, you can have multiple copies of the same slave component with different settings, which allows you, for example, to have multiple Randomizer slaves with different Variation setting (i.e. random seed), which provide the subtree with multiple random numbers per rendering element (i.e. particle, brick, iteration, pixel etc.)
Connect slave components to slave-accepting inputs
Each master component has so-called slave-accepting inputs, that is, the inputs that send additional data to slave components. In order to have desired effect on the output of the master component, its slave components must be connected to subtrees of slave-accepting inputs. Connecting them to any other inputs will have no effect. For example, all slave components of Bomber Plus must be connected to the subtree of its Particle input, which is the only slave-accepting input in Bomber Plus:
Avoid using bitmap-based components in slave-to-master connections
Generally, bitmap-based components, such as Blur or Motion Blur, cannot be used in slave-to-master connections because they destroy the data that are sent to slave components by their master, thus preventing the slave components from altering their output according to the data their master sent them. In order to have desired effect, the connection between a slave component and the slave-accepting input must not be routed through a bitmap-based component.
In the example below, the Randomizer slave won't have any effect on the output of Bomber Plus because the connection between it and the Particle input is routed through Blur, which is a bitmap-based component.
The Result component is a notable exception from this. Slaves of the Result component will affect the output of a bitmap-based component, however, any further components on the path between the output of that bitmap-based component and Result's Surface Color input will not be affected. For more information about this case, see the 'Using Slave Components' section of the help article for the Result component.
For technical details about the relationship of Filter Forge's sampling process and bitmap-based components, see the section 'Sampling and Slave Components' in Filter Forge's sample-based architecture.
Nesting
Slave-supporting components can have another slave-supporting component inside the subtree of their slave-accepting input. The example below shows two nested Loops, where the inner loop creates a row of 5 circles, which is then duplicated 5 times by the outer loop. Note that slave components of the outer loop can affect components in the subtree of the inner loop:
Preview Controls
You cannot actually see which values the output of a slave component would assume during the actual rendering. For example, the Bomber Plus component can theoretically output an infinite number of particles, and there’s simply no technically feasible way to allow you to see what the slave would output for each one of those particles.
As a workaround for this, most slave components have controls for manual preview. These controls allows you to preview output values of a slave component, which may be useful for creating and debugging the subtree the slave component is connected to.
The limitation of preview controls is that they are unrestricted, which means that you can configure the preview settings in various slaves into a combination that would never occur during the actual rendering. For example, despite the fact that your Bomber Plus has renders all its particles with zero rotation, nothing prevents you from setting the preview slider in the Rotation slave to a non-zero value. Furthermore, you can have multiple Rotation slaves, each with different value of the preview slider: such situation can never occur during the rendering because all copies of the Rotation slave will get the same rotation data from the master component.
On one hand the technical situation described above is limiting because you cannot preview your slave-to-master subtrees on combination of slave outputs that would occur during the actual rendering. On the other hand, free control over the slave output previews gives you more freedom in building and debugging the subtrees.
Currently, the only exception from the above is the Loop component, which synchronizes the preview settings for all its slaves, so they all output their preview values for the same iteration. Therefore the slave-to-master subtree of a Loop component always receives a set of slave output values that will actually occur during the actual rendering.
Technically, preview controls define the output of the slave component in situations when it is sampled by any input other than its master’s slave-accepting input. For details, see the section ‘Sampling and Slave Components’ in Filter Forge's sample-based architecture.
