FUSION · NODE REFERENCE
sTransform
Hierarchical transform for live Shape data
A Shape modifier with one required orange Input1: it takes vector Shape data, adds X/Y Offset, independent X/Y Size, Rotation and Pivot, and returns Shape Output without early rasterization. It is especially useful for hierarchy, keeping source self-animation separate from parent-like movement of the whole branch.
sTransform
Overview
What sTransform does
sTransform belongs to the Fusion Shape system and works on Shape data. Resolve 21 documents one required orange Input1 on the tile: it accepts the output of another Shape node. MediaIn, ordinary RGBA image data, or a blue mask are not substitutes for that input.
The sTransform output remains Shape data. It can continue through sGrid, sDuplicate, sBoolean, sMerge, sChangeStyle and other Shape tools; an ordinary image is not produced until sRender.
That is the essential difference from the regular Transform tool. Regular Transform works on a raster/image stream, whereas sTransform changes procedural Shape geometry before rasterization and preserves downstream Shape editability.
The main production role of sTransform is to add another transform layer on top of transform controls already present in many Shape generators. This separates local source animation from parent-like movement of an entire branch.
Blackmagic's reference uses sStar as the hierarchy example: the star's built-in Angle can create self-spin, then the sStar output feeds sTransform and sTransform Rotation can move the whole star around another axis. This is a clean hierarchy instead of one overloaded animation layer.
X Offset and Y Offset move the incoming Shape geometry in Fusion's normalized coordinate system. The Resolve 21 reference gives a useful landmark: X Offset 0.0 is centered, while 0.5 places the Shape center on the right edge of the frame.
Offset is not Pivot. Offset moves geometry; Pivot defines the axis used by Rotation and the scale relationship. Confusing those jobs makes intentional orbit motion look like an unexplained translation error.
X Size and Y Size independently scale the incoming Shape horizontally and vertically. A value of 1.0 preserves size on that axis; unequal values intentionally stretch or squash the incoming Shape geometry.
The captured sTransform Controls panel does not expose a shared Lock X/Y control. Preserving proportions is therefore an authoring decision: for uniform scale animation, X Size and Y Size must change together.
Rotation turns the incoming Shape geometry in the 2D plane around the current Pivot. Set the axis first, then create Rotation keys; changing Pivot later changes the path of an already-authored rotation.
X Pivot and Y Pivot position the axis of rotation for the incoming Shape. Resolve 21 notes that the pivot appears in the Viewer as a red X and can be dragged onscreen.
Pivot does not have to coincide with the visible geometry center. Deliberately separating geometry from Pivot enables orbiting icons, swinging badges, radial HUD animation and other hierarchical movement without a raster Transform.
Transform Axis is an important checkbox whose meaning is often misdescribed. The manual defines it as applying the transform to the Shape's axis. It is not Show Controls, gizmo visibility, or an X/Y lock switch.
Transform Axis becomes most useful in hierarchy tests: in addition to the geometry, the Shape axis information follows the operation, which can alter how downstream Shape transforms relate to the branch. Test it with multiple Shape-transform stages rather than judging only one still frame.
The captured Resolve Inspector shows exactly eight authored Controls: X Offset, Y Offset, X Size, Y Size, Rotation, X Pivot, Y Pivot and Transform Axis. In that saved state Offset/Rotation/Pivot are 0.0, X/Y Size are 1.0, and Transform Axis is enabled.
Those captured values are UI evidence for one saved state, not a universal factory-default contract for every Resolve build. They are useful A/B baselines but should not be treated as a version-independent API promise.
A simple motion-graphics branch is generator → sTransform → sRender. The generator owns primitive construction and local controls, sTransform owns object-level placement, and sRender owns rasterization.
If a Shape has already been repeated by sGrid, placing sTransform after sGrid transforms the whole compound grid as one group. Putting sTransform before sGrid changes the source first and then repeats that transformed source. These are different hierarchies.
The same ordering rule applies to sDuplicate: a transform before duplication belongs to the source copy, while a transform after duplication belongs to the assembled branch. Node placement is often more important than the numeric Offset/Size/Rotation values.
After sMerge, one sTransform can animate a compound Shape as a single unit. This is cleaner than synchronizing keys across several generators when the whole composition must move, scale or rotate together.
sTransform does not redefine Style by itself. Color, Alpha, Allow Combining and other appearance properties arrive from the upstream Shape tree; sTransform changes geometry rather than creating a new fill or shading layer.
sTransform also does not create raster alpha. Until sRender, the edge remains vector Shape information. Judge antialiasing, final pixel coverage and very fine outlines downstream at the target raster resolution.
Do not use sTransform to repair source-primitive construction when the task is really geometry design. For example, sRectangle Width/Height describe the rectangle itself, whereas sTransform X/Y Size is an external object-level transform applied on top.
For orbit animation, begin with a static diagnosis: inspect the source Shape, Offset, Pivot and one Rotation state. Add the second rotation key only after the axis relationship is understood.
With nonuniform X/Y Size, inspect stroke and corner behavior carefully. The stream is still vector, but the geometry genuinely stretches: a circle can become an ellipse, a square a rectangle, and a star an anisotropic burst.
If downstream processing needs Glow, Blur or another image effect, finish Shape operations first, then sRender, then apply the raster effect. Early sRender prevents later s-nodes from receiving native Shape data.
For reusable templates, separate responsibilities in node names such as SOURCE GEOMETRY, LOCAL SPIN, GROUP TRANSFORM and RENDER. This reduces the chance that a future edit breaks hierarchy by placing keys at the wrong level.
Use Viewer 100% after sRender for final edge QC and playback for Offset/Rotation hierarchy. A still frame is useful for axis and proportion checks but cannot reveal timing, arc motion or interactions between transform layers.
A reliable sTransform QC order is topology/type → Offset → Size → Pivot → Rotation → Transform Axis → downstream hierarchy → sRender edge. Testing one variable at a time keeps cause and effect obvious.
When to use it
Object-level Shape motion before sRender
Separate source self-spin from orbit/group rotation
Move a compound Shape after sGrid/sDuplicate/sMerge
Nonuniform X/Y scale inside the Shape domain
Create a custom pivot for orbit or swing animation
Hierarchical HUD, badge, icon and lower-third motion
Prepare source orientation before repetition
Keep the pipeline vector until final rasterization
sTransform in context
Screenshots referenced by this article. Open an image to inspect it at full size.
Example for sTransform.
Original image