Slave-Komponenten sind eine besondere Art von Komponenten. Sie sind fest mit ihrer Master-Komponente verbunden und können nicht abgetrennt werden. Ihre Ausgänge sollten mit dem Teilbaum der Slave-akzeptierenden Eingänge ihrer Master-Komponente verbunden sein, da sie sonst keinen Einfluss auf deren Ausgabe haben.
Das Wichtigste bei Slave-Komponenten ist, dass sich ihre Ausgabe in Abhängigkeit davon ändert, was die Master-Komponente gerade rendert. So ändern z. B. die Slaves von Loop ihre Ausgabe in Abhängigkeit von der Nummer der aktuellen Loop-Iteration; die Slaves von Bomber Plus ändern ihre Ausgabe in Abhängigkeit von dem Partikel, das gerade gerendert wird, und die Slaves von Ergebnis geben unterschiedliche Werte in Abhängigkeit von den Koordinaten des Pixels aus, das gerade vom Renderer gerendert wird.
Zusammenfassend lässt sich sagen, dass Slave-Komponenten einige interne Variablen ihrer Master-Komponenten in ihren Teilbäumen offenlegen (z. B. die Anzahl der Loop-Iterationen oder die Parameter des aktuellen Partikels, Kachel oder Ziegelstein), so dass der Teilbaum je nach den Daten der Master-Komponente unterschiedliche Ausgaben erzeugen kann.
Der Hauptvorteil von Slave-Komponenten besteht darin, dass sie die Anpassung von Teilbäumen pro Rendering-Element ermöglichen. Diese Art der Anpassung ist ohne Slave-Komponenten nicht möglich. Zum Beispiel kannst du durch die Verwendung von Slave-Komponenten im Teilbaum des Partikel-Eingangs von Bomber Plus jedes einzelne Partikel auf der Grundlage seiner tatsächlichen Größe oder Rotation, zufälliger Zahlen, die nur für dieses Partikel gelten, oder der Koordinaten des Partikelzentrums und der Ecken anpassen. In ähnlicher Weise kannst du in Kacheln Plus, Ziegelsteine Plus and Pflastersteine Plus mit den Slave-Komponenten jedes einzelne Musterelement, sprich jeden Ziegelstein oder jede Kachel, individuell anpassen. Und in der Komponente Loop kannst du die Ausgabe des Loop-Teilbaums für jede einzelne Loop-Iteration auf der Grundlage ihrer Nummer, der kombinierten Ausgabe aller vorherigen Iterationen und der für diese Iteration einzigartigen Zufallszahlen anpassen.
Dieses Beispiel verwendet drei Zufallsgenerator-Slaves von Bomber Plus, um eine zufällige HSY-Farbe zusammenzustellen, die dann jedem Partikel zugewiesen wird:
Das nächste Beispiel verwendet zwei Sets von Zufallsgenerator-Slaves, um zwei zufällige HSY-Farben (eine warme und eine kühle) zusammenzustellen, und einen weiteren Zufallsgenerator, um für jeden Ziegelstein zufällig zwischen diesen beiden Farben zu wechseln:
Das letzte Beispiel verwendet den Positions-Slave der Loop-Komponente, um die Rotation des Sterns in Abhängigkeit von der Loop-Iteration zu definieren. Der Akkumuliert-Slave gibt das kombinierte Ergebnis aller vorherigen Iterationen aus, das als Hintergrund für die aktuelle Iteration verwendet wird, d.h. jeder neu gedrehte Stern wird über alle zuvor gedrehten Sterne gezeichnet:
Slave-Komponenten können nicht getrennt von ihrer Master-Komponente existieren, und du kannst sie nicht in der Komponentenleiste finden. Um sie zu erstellen, verwende die entsprechenden Schaltflächen in den Eigenschaften der Master-Komponente oder kopiere/einfüge vorhandene Slave-Komponenten.
In den meisten Fällen kannst du mehrere Kopien derselben Slave-Komponente mit unterschiedlichen Einstellungen haben, so dass du z. B. mehrere Zufallsgenerator-Slaves mit unterschiedlichen Variationseinstellungen (sprich Zufallssamen) haben kannst, die den Teilbaum mit mehreren Zufallszahlen pro Rendering-Element (sprich Partikel, Ziegelstein, Iteration, Pixel usw.) versehen.
Jede Master-Komponente hat sogenannte Slave-akzeptierende Eingänge, d.h. die Eingänge, die zusätzliche Daten an Slave-Komponenten senden. Um die gewünschte Wirkung auf die Ausgabe der Master-Komponente zu erzielen, müssen ihre Slave-Komponenten mit Teilbäumen von Slave-akzeptierenden Eingängen verbunden sein. Der Anschluss an andere Eingänge ist wirkungslos. Zum Beispiel müssen alle Slave-Komponenten von Bomber Plus mit dem Teilbaum des Eingangs Partikel verbunden sein, der der einzige Slave-akzeptierende Eingang in Bomber Plus ist:
Im Allgemeinen können Bitmap-basierte Komponenten wie Unschärfe oder Bewegungsunschärfe nicht in Slave-zu-Master-Verbindungen verwendet werden, da sie die Daten zerstören, die von ihrem Master an die Slave-Komponenten gesendet werden, wodurch die Slave-Komponenten daran gehindert werden, ihre Ausgabe entsprechend den Daten zu ändern, die ihr Master ihnen gesendet hat. Um den gewünschten Effekt zu erzielen, darf die Verbindung zwischen einer Slave-Komponente und dem Eingang, der den Slave akzeptiert, nicht über eine Bitmap-basierte Komponente geleitet werden.
Im folgenden Beispiel hat der Zufallsgenerator-Slave keine Auswirkungen auf die Ausgabe von Bomber Plus, da die Verbindung zwischen ihm und dem Partikel-Eingang über Unschärfe, eine Bitmap-basierte Komponente, geleitet wird.
Eine bemerkenswerte Ausnahme hiervon bildet die Komponente Ergebnis. Slaves der Komponente Ergebnis wirken sich auf die Ausgabe einer Bitmap-basierten Komponente aus, alle weiteren Komponenten auf dem Pfad zwischen der Ausgabe dieser Bitmap-basierten Komponente und der Eingabe der Oberflächenfarbe von Ergebnis werden jedoch nicht beeinflusst. Weitere Informationen zu diesem Fall findest du im Abschnitt "Slave-Komponenten verwenden" des Hilfeartikels für die Komponente Ergebnis.
Technische Details über die Beziehung zwischen dem Sampling-Prozess von Filter Forge und Bitmap-basierten Komponenten findest du im Abschnitt "Sampling und Slave-Komponenten" in der Sample-basierten Architektur von Filter Forge.
Slave-unterstützende Komponenten können eine andere Slave-unterstützende Komponente innerhalb des Teilbaums ihres Slave-akzeptierenden Eingangs haben. Das folgende Beispiel zeigt zwei verschachtelte Loops, wobei der innere Loop eine Reihe von 5 Kreisen erzeugt, die dann von dem äußeren Loop fünfmal dupliziert wird. Beachte, dass Slave-Komponenten des äußeren Loops Komponenten im Teilbaum des inneren Loops beeinflussen können:
Du kannst nicht sehen, welche Werte die Ausgabe einer Slave-Komponente beim eigentlichen Rendering annehmen würde. Zum Beispiel kann die Bomber Plus-Komponente theoretisch eine unendliche Anzahl von Partikeln ausgeben, und es gibt einfach keinen technisch machbaren Weg, um zu sehen, was die Slave-Komponente für jedes einzelne dieser Partikel ausgeben würde.
Um dies zu umgehen, verfügen die meisten Slave-Komponenten über Steuerelemente für die manuelle Vorschau. Mit diesen Steuerelementen kannst du eine Vorschau der Ausgabewerte einer Slave-Komponente anzeigen, was für die Erstellung und Fehlersuche in dem Teilbaum, mit dem die Slave-Komponente verbunden ist, nützlich sein kann.
Die Einschränkung der Vorschau-Steuerung besteht darin, dass sie nicht eingeschränkt ist, d. h. du kannst die Vorschaueinstellungen in verschiedenen Slaves in einer Kombination konfigurieren, die während des tatsächlichen Renderings nie auftreten würde. Obwohl dein Bomber Plus zum Beispiel alle Partikel mit einer Null-Rotation rendert, hindert dich nichts daran, die Vorschau-Steuerung im Rotation-Slave auf einen Wert ungleich Null zu setzen. Außerdem kannst du mehrere Rotation-Slaves haben, jeder mit einem anderen Wert der Vorschau-Steuerung: eine solche Situation kann während des Renderings niemals auftreten, da alle Kopien des Rotation-Slaves die gleichen Rotationsdaten von der Master-Komponente erhalten.
Einerseits ist die oben beschriebene technische Situation einschränkend, weil du deine Slave-zu-Master-Teilbäume nicht in der Vorschau auf die Kombination von Slave-Ausgaben sehen kannst, die während des eigentlichen Renderings auftreten würde. Andererseits gibt dir die freie Steuerung über die Vorschau der Slave-Ausgaben mehr Freiheit bei der Erstellung und Fehlersuche in den Teilbäumen.
Derzeit ist die einzige Ausnahme die Loop-Komponente, die die Vorschaueinstellungen für alle ihre Slaves synchronisiert, so dass sie alle ihre Vorschauwerte für dieselbe Iteration ausgeben. Daher erhält der Slave-zu-Master-Teilbaum einer Loop-Komponente immer einen Satz von Slave-Ausgabewerten, die während des eigentlichen Renderings tatsächlich auftreten werden.
Technisch gesehen definieren die Vorschau-Steuerungen die Ausgabe der Slave-Komponente in Situationen, in denen sie von einem anderen Eingang als dem Slave-akzeptierenden Eingang ihres Masters gesampelt wird. Einzelheiten hierzu findest du im Abschnitt "Sampling und Slave-Komponenten" in der Sample-basierten Architektur von Filter Forge.