Realtime Compositor

The Realtime Compositor is a new GPU accelerated compositor introduced in Blender 3.5 and is currently used for viewport compositing. This compositor is currently more limited and not all Compositor Nodes are supported, such nodes are marked with the CPU Compositor Only label along with notes about other limitations. Moreover, MacOS is not supported due to missing support for modern OpenGL.

Données

Dimensionnalité

Les nœuds de composition fonctionnent sur des données qui sont soit une image ou une valeur unique sans dimension. Par exemple, le nœud Levels sortira une seule valeur, tandis que le nœud Render Layers sortira une image. Les entrées de nœud qui s’attendent à une valeur unique supposent une valeur par défaut si une image est donnée et ignorent complètement l’image, par exemple, le nœud Transform attend des valeurs uniques pour ses entrées et supposera des valeurs par défaut si des images sont données à ces entrées. Les valeurs par défaut sont celles qui sont considérées comme une identité et n’ont donc aucun effet sur la sortie, donc pour le nœud Transform, les entrées X, Y et Angle auront une valeur par défaut de zéro, tandis que l’entrée Scale aura une valeur par défaut de 1. D’un autre côté, si les entrées de nœud qui s’attendent à une image reçoivent une valeur unique, la valeur unique sera supposée couvrira l’ensemble de l’espace de composition. Par exemple, le nœud Filter s’attend à ce que son entrée Factor soit une image, mais si une seule valeur est donnée, elle sera supposée être la même pour tous les pixels.

Type

Il existe trois types de données, qui sont tous stockés dans des formats half precision :

Float: Un nombre floating-point signé. Les données entières sont également stockées sous forme de flottants car aucun type entier n’existe.
Vecteur: Un vecteur 4D. Bien qu’il soit 4D, il peut avoir des interprétations différentes en fonction du nœud qui l’utilise. Il peut être traité comme un vecteur 2D avec les deux derniers composants ignorés, par exemple, l’entrée Vector du nœud Displace est traitée comme un vecteur 2D. Il peut être traité comme un vecteur 3D avec le dernier composant ignoré, par exemple, l’entrée Vector du nœud Seperate XYZ node est traité comme un vecteur 3D. Il peut être traité comme deux vecteurs 2D consécutifs. Par exemple, Velocity Pass comme prévu par le nœud Vector Blur est supposé avoir 2D Previous Velocity dans les composants X et Y du vecteur et 2D Next Velocity dans les composants Z et W du vecteur.
Color: Un vecteur 4D stockant le rouge, le vert, le bleu et l’alpha de la couleur. La couleur est une forme libre et ne se conforme pas à un modèle d’espace colorimétrique ou à un modèle de stockage alpha, au lieu de cela, les nœuds appropriés auront des paramètres pour contrôler la représentation de leur sortie et des nœuds existent pour des convertions entre les différentes représentations.

Conversion implicite

Dans le cas où une entrée de nœud reçoit des données de type autre que son propre type, les conversions implicites suivantes sont effectuées :

Source	Cible	Conversion
Float	Vecteur	f => Vector(f, f, f, 0)
Float	Color	f => Color(f, f, f, 1)
Vecteur	Float	(x, y, z, w) => Moyenne (x, y, z)
Vecteur	Color	(x, y, z, w) => Color(x, y, z, 1)
Color	Float	(r, g, b, a) => Moyenne(r, g, b)
Color	Vecteur	(r, g, b, a) => Vector(r, g, b, 0)

L’exemple suivant démontre une conversion implicite entre un type de couleur et un type float, car le nœud Math s’attend à des entrées float.

../_images/compositing_realtime-compositor_compositing-space_data_type_implicit_conversion.png — Un exemple qui démontre une conversion implicite entre un type de couleur et un type float, car le nœud *Math* attend des entrées float.

Composition spaciale

Domaine de l’image

Le compositeur est conçu de manière à permettre la composition dans un espace de composition infini. Par conséquent, les images ne sont pas seulement représentées par leur taille, mais aussi par leur transformation dans cet espace, tout comme les objets 3D ont des transformations. Une transformation d’identité représente une image centrée dans l’espace. La zone rectangulaire occupée par une image dans cet espace telle que définie par sa transformation et sa taille est appelée le domaine de l’image. La figure ci-dessous montre les domaines de deux exemples d’images.

../_images/compositing_realtime-compositor_compositing-space_image-domain_example.png — Les domaines de deux exemples d’images sont illustrés sur l’espace de composition. L’une des images est centrée dans l’espace et l’autre est réduite et traduite de telle sorte qu’elle se trouve dans le quadrant supérieur droit de l’espace. Notez que les deux images ont des tailles similaires dans les pixels, mais leurs tailles apparentes sont différentes.

Les images peuvent être transformées à l’aide de nœuds comme les nœuds Transform, Translate et Rotate.

Domaine d’opération

Compositor Nodes operate on a specific rectangular area of the compositing space called the Operation Domain. The nodes only consider the area of the input images that overlap the operation domain and ignores the rest of the images. If an input image doesn’t completely overlap the operation domain, the rest of the operation domain for that input will be assumed to be a zero value, a zero vector, or a transparent zero color depending on the type. This behavior can be changed to an extent, see the section about Wrapping below.

Par exemple, la figure ci-dessous illustre un cas où le domaine de fonctionnement d’un nœud est la grande zone bleue et le domaine d’une image d’entrée est la petite zone rouge. Dans ce cas, l’image d’entrée ne chevauche pas complètement le domaine de fonctionnement, de sorte que le reste de la zone bleue pour cette image d’entrée est supposé nul.

../_images/compositing_realtime-compositor_compositing-space_operation-domain_example.png — Un exemple de cas où le domaine de fonctionnement d’un nœud est illustré en bleu et le domaine d’une image d’entrée est illustré en rouge. Étant donné que l’image d’entrée ne couvre pas complètement le domaine de fonctionnement du nœud, le reste de la zone bleue pour cette image d’entrée est supposé nul.

L’illustration précédente est une représentation d’un exemple du monde réel où l’on utilise le nœud Alpha Over pour superposer un petit logo sur une image, comme le montre la figure ci-dessous. Dans ce cas, le domaine d’opération couvre l’intégralité de la vue de la fenêtre – comme cela sera plus tard démontré, mais le logo ne couvre qu’une petite zone, de sorte que le reste de la zone est supposé être une couleur transparente nulle, ce qui est pratique pour le cas d’utilisation.

../_images/compositing_realtime-compositor_compositing-space_operation-domain_real-example.png — Un exemple du monde réel où le nœud Alpha Over est utilisé pour sur un petit logo sur une image. Le logo ne couvre qu’une petite zone du domaine d’opération, qui est toute la fenêtre dans ce cas, de sorte que le reste de la zone est supposé être une couleur transparente nulle.

Interpolation

If an input image to a node is not perfectly aligned with the operation domain of the node or have a different size in pixels, the node would typically need to do a process called Interpolation, where the input image is read at the exact positions of the pixels of the operation domain. This can be done using different interpolation methods, including Nearest-Neighbor, Bilinear, and Bicubic interpolations. Those interpolation methods are demonstrated in the following Wikipedia gallery. Transformation nodes like the Transform and Rotate nodes include an interpolation option to set how they prefer their output image to be read and interpolated.

Note that the transform nodes don’t do any interpolations themselves, they merely record the preferred interpolation method for the output image and latter nodes that read that image will be the node that does the actual interpolation. It follows that latter transform nodes will overwrite the interpolation methods set by former transform nodes if no interpolation took place in-between.

Wrapping

While it was previously stated that areas of the input images that do not overlap the operation domain are assumed to be zero, this is only the default behavior. The alternative behavior is to instruct the compositor to repeat the input image to fill the missing areas along the horizontal direction, vertical direction, or both. This can be set in the Wrap option of the Translate node. Much like the aforementioned interpolation method, the Translate node doesn’t do any wrapping itself, it merely sets the preferred method of filling empty spaces and latter nodes that read the image will be the node that does the actual wrapping.

For instance, the previous Alpha Over example but with Both Axis Wrapping enabled is shown in the figure below.

../_images/compositing_realtime-compositor_compositing-space_operation-domain_wrapping.png — The previous example with *Alpha Over* example but with *Both Axis Wrapping* enabled.

Déterminer le domaine de fonctionnement

La question demeure sur la façon dont les nœuds déterminent leur domaine de fonctionnement. Différents types de nœuds peuvent avoir différents mécanismes pour déterminer leur domaine de fonctionnement. Mais généralement, trois classes de nœuds existent en ce qui concerne le mécanisme de détermination du domaine de fonctionnement, dont chacun est présenté dans l’une des sections suivantes.

Les nœuds Input

Le domaine de fonctionnement des nœuds d’entrée comme le nœud Image est un domaine avec une transformation d’identité et de la même taille que leurs sorties, donc pour le nœud Image, le domaine d’opération sera le domaine dont la taille est celle de l’image et dont la transformation est une identité.

Les nœuds Output

Le domaine de fonctionnement des nœuds de sortie comme le nœud Viewer est un domaine avec une transformation d’identité et de la même taille que la sortie du compositeur final. Pour la composition de la vue, cette taille serait la taille de la fenêtre et pour la composition du rendu final, cette taille serait la taille du rendu de la scène.

Autres Nœuds

Sauf indication contraire dans leurs pages de documentation respectives, tous les autres nœuds utilisent le mécanisme suivant. L’une des entrées des nœuds est désignée comme entrée de domaine du nœud et le domaine de fonctionnement du nœud est identique au domaine de cette entrée désignée. Pour de nombreux nœuds, l’entrée de domaine peut être identifiée intuitivement comme l’entrée principale du nœud, par exemple, l’entrée de domaine pour le nœud Filter est l’entrée Image. Mais il y a quelques mises en garde à noter, ce qui nécessite une compréhension plus profonde du mécanisme.

Chaque entrée dans le nœud a la propriété dite Domain Priority, le domaine de fonctionnement du nœud est le domaine de l’entrée de valeur non simple avec la priorité de domaine la plus élevée. Ainsi, par exemple, le nœud Filter a deux entrées, la priorité de domaine de l’entrée Image est supérieure à celle de l’entrée Factor et il y a quatre configurations possibles :

Les entrées Image et Factor sont connectées aux images. Dans ce cas, l’entrée Image est l’entrée de domaine car elle a la priorité la plus élevée et est connectée à une image.
L’entrée Image est connectée à une image, mais l’entrée Factor ne l’est pas. Dans ce cas, l’entrée Image est l’entrée de domaine car elle est la seule entrée connectée à une image quelle que soit sa priorité.
L’entrée Image n’est pas connectée à une image mais l’entrée du Factor l’est. Dans ce cas, l’entrée Factor est l’entrée de domaine car elle est la seule entrée connectée à une image quelle que soit sa priorité.
Ni l’entrée Image, ni l’entrée Factor ne sont connectées aux images, dans ce cas, il n’y a pas d’entrée de domaine car le nœud est évalué sur des valeurs uniques.

Considérations

Le mécanisme susmentionné pour déterminer le domaine d’opération a un certain nombre de conséquences qui doivent être prises en compte car elles pourraient être indésirables, chacune est présentée dans l’une des sections suivantes.

Clipping

La sortie des nœuds sera intuitivement clippée dans le domaine de fonctionnement, ou plutôt le domaine de l’entrée de domaine. Par exemple, si l’entrée Foreground est plus grande que l’entrée Background dans le nœud Alpha Over, la sortie sera clippée à l’entrée Background car il s’agit de l’entrée de domaine, comme illustré dans la figure suivante.

The Alpha Over node currently doe not support changing the domain priority for its inputs, so as a workaround, one can use a Mix node to achieved the desired behavior, noting that the first Image input in the Mix node has the highest domain priority, as shown in the following figure.

../_images/compositing_realtime-compositor_compositing-space_operation-domain_considerations_clipping-solution.png — Travail autour du comportement de clipping du nœud *Alpha Over* en utilisant un nœud *Mix*, en notant que la première entrée *Image* dans le nœud *Mix* a la priorité de domaine la plus élevée

Pixelation

If the domain input of the node is very large, other inputs will look pixelated. That’s because the resolution of the domain input is the same, while its apparent size is greatly increased, so the number of pixels covered by other inputs is much fewer.

Pixel Space Operations

Nodes operate on their input images in local pixel space irrespective of their transformation in the compositing space. For instance, if an image that is rotated by 90 degrees is blurred along the horizontal direction using the Blur node, the blurring will apparently take place along the vertical direction instead, because the node is applied in the local pixel space of the input.

Output

The realtime compositor only supports a single active output target, that is, only one of the Composite nodes, Viewer nodes, or Split Viewer nodes in the node tree will be considered active and the rest will be ignored. In particular, the compositor searches the Active Node Tree Context and falls back to the Root Node Tree Context if no active output was found in the active node tree context. The active node tree context is the node tree of an expanded node group, that is, when the users selects a node group node and edits its underlying tree, while the root node tree context is the top level node tree without any expanded node groups. The compositor searches for the active Composite node, if non was found, it searches for the active Viewer node, be it a Viewer or a Split Viewer node, if non was found, the compositor doesn’t run altogether. Consequently, note that adding a Viewer node will have no effect if there is a Composite node, since the priority is given to Composite nodes.