Render & View#

Preview images, 3D viewport, cameras and render passes.

11 nodes.

Back to the reference index

Contents#

• Camera (PCG) — Builds a single camera that Render Sequence, Texture Render, Motion Vectors and UV Backproject can all share.
• Camera from Points (PCG) — Turns points, taken in point-number order, into a sequence of cameras.
• Camera Path (PCG) — Generates a sequence of cameras along an orbit or an interpolated fly-through.
• Camera Pick (PCG) — Picks one camera out of a camera sequence.
• Camera To Points (PCG) — Converts cameras into points (one per camera) plus optional path and frustum wireframes.
• Motion Vectors (PCG) — Computes exact screen-space motion vectors between two frames from geometry and cameras.
• Render Sequence (PCG) — Renders a geometry through every camera of a camera sequence into a sequence of images.
• Sequence Motion (PCG) — Computes a sequence of exact motion vector images from a geometry sequence and cameras.
• Texture Render (PCG) — Renders a UV texture onto the geometry through a camera.
• UV Backproject (PCG) — Projects a screen-space image back into UV space, weighted by visibility and facing, into an accumulator.
• UV Resolve (PCG) — Turns a back-projection accumulator into a finished texture: divide by weight, dilate, fill holes.

Nodes#

Camera (PCG)#

PCG_Camera · category PCG/render · Houdini: Camera (SOP)

Builds a single camera that Render Sequence, Texture Render, Motion Vectors and UV Backproject can all share.

The camera is a standalone node so that the view used to render an image and the view used to project it back into UV space are literally the same wire. Entering the same parameters twice in two nodes invites a mismatch, and the result is a smoothly misaligned texture that looks like the diffusion model drew it crooked and is very hard to trace back to the camera.

Three placement modes: frame places the camera on an orbit around the bounding sphere of the connected geometry and picks the distance (perspective) or the orthographic size automatically; orbit uses the same elevation / azimuth / distance parametrisation around an explicit target; look_at uses an explicit eye position, target and up vector. For multiple views use several Camera nodes, or one Camera with different azim values, each feeding its own render branch.

Inputs

Outputs

Parameters

View

Transform

Tips

• Use one Camera node per view and wire the same node to both the render and the back-projection of that view.

Camera from Points (PCG)#

PCG_CameraFromPoints · category PCG/render · Houdini: Camera from Points (SOP)

Turns points, taken in point-number order, into a sequence of cameras.

The curve-driven counterpart of Camera Path. Each point (or, with frames > 0, each sample along the polyline through the points) becomes one camera.

Orientation modes: auto tries the orient attribute, then N, then a target attribute, then the path tangent, in that order; orient uses the orient quaternion; normal looks along N with the Up vector; target looks at the target point attribute or the Target parameter; path follows the path tangent. With Look Ahead above 0 the path mode looks at the point that far ahead along the path, which steadies the shot.

With Frames = 0 there is one camera per point. With Frames > 0 the path is sampled at equal arc-length steps: orient is interpolated with slerp, other quantities linearly. Loop joins the end back to the start without repeating the first frame at the end. With Use Point Attributes on, the point attributes fov, ortho_size, near, far, radius, resx, resy, projection and distance override the matching parameters, so Camera To Points followed by Camera from Points round-trips exactly.

Inputs

Outputs

Parameters

Compared with Houdini

Matches Houdini's Camera from Points in intent; the camera sequence is a ComfyUI-side list rather than camera objects.

Camera Path (PCG)#

PCG_CameraPath · category PCG/render

Generates a sequence of cameras along an orbit or an interpolated fly-through.

The entry point of the video side of the plugin. Orbit mode sweeps elevation, azimuth and distance from their start to their end values around a target. Interpolate mode moves the eye linearly from Eye to End Eye while looking at a fixed Target. The output is a camera list to be wired to Render Sequence; wire it to Camera Pick to use a single frame.

With Loop on, the last frame does not repeat the first: sweeping azimuth 0 to 360 over 24 frames ends at 345 degrees, not 360, so a looping playback has no duplicated frame (a one-frame stutter that is easy to see and hard to diagnose). Turn Loop off for a one-shot move where the last frame should land exactly on the end value.

Inputs

Outputs

Parameters

Orbit

Interpolate

Clipping

Tips

• For a seamless turntable keep Loop on and azimuth 0 to 360.

Camera Pick (PCG)#

PCG_CameraPick · category PCG/render

Picks one camera out of a camera sequence.

The index wraps around the number of cameras instead of raising an error, so dragging the index while previewing never breaks the chain.

Inputs

Outputs

Parameters

Camera To Points (PCG)#

PCG_CameraToPoints · category PCG/render · Houdini: Camera To Points (SOP)

Converts cameras into points (one per camera) plus optional path and frustum wireframes.

Each camera in the sequence, and/or the single camera input, becomes one point whose point number equals the frame number. Point attributes: P, orient (+Z is the view direction and +Y is up, the same convention as N, Orient Along Curve and Copy to Points), N, up, target, distance, fov, ortho_size, near, far, radius, resx, resy, projection and frame.

The frustums output is a line wireframe of each view frustum; its far rectangle matches the image corners exactly. Moving or rotating the points and feeding them to Camera from Points is a way to place cameras directly in the viewport.

Inputs

Outputs

Parameters

Motion Vectors (PCG)#

PCG_MotionVectors · category PCG/render

Computes exact screen-space motion vectors between two frames from geometry and cameras.

Optical flow has to estimate where a pixel was in the previous frame, and neural flow fails on weak texture, large motion, reflections and transparency without warning. Here the position is known: the same triangle and the same barycentric weights are projected once with the frame-t vertices and once with the frame-(t+1) vertices, and the two screen positions are subtracted. There is no search and no smoothing.

Forward and backward vectors live on different meshes and are rasterized separately. motion is defined on the frame-t image ("where do I go next"); motion_bwd on the frame-(t+1) image ("where did I come from"). Warping needs the backward one, and negating the forward map is only correct when nothing moves.

Output layers: motion, motion_bwd, mask (coverage at t), mask_next (coverage at t+1) and disocclusion, the area of frame t+1 that was not visible in frame t and must be repainted. Disocclusion is decided by triangle id, with a depth test (Depth Bias) and a silhouette guard as safety layers.

If only the camera moves, connect only cam_next; if only the object moves, connect only geo_next. The two frames must have identical topology so that barycentric weights correspond, and both cameras must have the same resolution.

Inputs

Outputs

Parameters

Render Sequence (PCG)#

PCG_RenderSequence · category PCG/render

Renders a geometry through every camera of a camera sequence into a sequence of images.

The B dimension of an IMAGE is the video; this node fills it. Each camera produces one image with the selected passes (layers mask, depth, N, P, uv, id, facing, and C for shade). Frames are rendered serially, since geometry is a Python object and cannot be batched as a tensor. If no pass is ticked, only Mask is rendered.

With Motion on, every frame also gets motion, motion_bwd and disocclusion layers describing the step from this frame to the next one. This only captures camera motion, because the geometry is a single static object; use Sequence Motion for moving geometry. The last frame has no successor: with Loop on it is connected back to frame 0, otherwise it gets zero motion and a fully set disocclusion, so that undefined motion is visible downstream instead of being faked by repeating the previous frame.

Inputs

Outputs

Parameters

More Passes

Motion Vectors

Attributes

Sequence Motion (PCG)#

PCG_SequenceMotion · category PCG/render

Computes a sequence of exact motion vector images from a geometry sequence and cameras.

The moving-geometry counterpart of the motion option in Render Sequence, which can only express camera motion. It takes the geometry sequence produced by For-Each Frame End, so deformation, growth and fracture all get exact vectors. For every frame, motion between that frame and the next is computed as in Motion Vectors (layers motion, motion_bwd, mask, mask_next, disocclusion).

There must be as many cameras as geometries, or exactly one camera for a fixed viewpoint. A mismatch by one frame shifts the vectors by a whole frame and produces ghosting when warping, so it raises an error. The last frame has no successor: with Loop on it is connected to frame 0, otherwise it gets zero motion and a fully set disocclusion. Consecutive frames must share one topology.

Inputs

Outputs

Parameters

Texture Render (PCG)#

PCG_TextureRender · category PCG/render · Houdini: UV Quick Shade (SOP)

Renders a UV texture onto the geometry through a camera.

The forward half of the texture projection loop. It lets you check a back-projected texture without leaving ComfyUI, and it is the honest test of back-projection: a known texture rendered and back-projected should come back unchanged. The two directions use different code paths (screen rasterization plus UV sampling here, UV rasterization plus screen sampling there), so a round trip checks real behaviour rather than one bug cancelling itself.

The output has the color in layer C and a coverage mask.

Inputs

Outputs

Parameters

Compared with Houdini

Corresponds to UV Quick Shade.

UV Backproject (PCG)#

PCG_UVBackproject · category PCG/render

Projects a screen-space image back into UV space, weighted by visibility and facing, into an accumulator.

Until this step the chain is one-way: geometry, render pass, control image, diffusion model. The generated image is laid out in screen pixels, but an asset needs a texture laid out in UV. This node does that conversion.

Accumulator. The output is an accumulator (layers Csum, Wsum and views), not a texture. Connect it to the accum input of the next view's Backproject so each view adds its contribution on top of the previous ones, and finish with UV Resolve to get a texture. A single node that outputs textures directly could not know how much weight earlier views had at each texel and would have to overwrite in overlaps, producing a visible seam.

Visibility. UV rasterization knows which triangle each texel belongs to, and the screen rasterization knows which triangle is visible at each pixel; when they match the texel is visible without any depth comparison. Pure depth bias is a bad trade: too small gives self-occlusion speckles (the same disease as shadow acne), too large leaks through occluders. The default triangle+depth accepts a texel if its triangle matches or its depth is within the bias; triangle only is too strict.

Silhouette guard. Pixels on the silhouette are partially covered and blend in the background, and generated images are least reliable at object edges, so pixels within a number of pixels of the silhouette are discarded.

Linear blending. Averaging encoded values gives different results than averaging linear values, and the error shows up only in overlaps as a seam. So the image is decoded to linear before accumulation by default.

Texel weight is the facing term (N dot view direction) raised to Facing Power, zero at or below Facing Min, times a fade over the outer Border Fade fraction of the image, times 1 or 0 for visibility.

Inputs

Outputs

Parameters

Weighting

Visibility

Advanced

UV Resolve (PCG)#

PCG_UVResolve · category PCG/render

Turns a back-projection accumulator into a finished texture: divide by weight, dilate, fill holes.

Divides the summed color by the summed weight, writes a gutter around UV islands, and fills regions that no view saw.

Dilation and hole filling are different things. Dilation writes a few extra texels outside the UV islands; without it, bilinear sampling at island edges picks up background, especially in low mips. Hole filling covers texels that were never seen by any view (back sides, fully occluded areas, large gaps between islands) with push-pull: the weighted image is downsampled into a pyramid and upsampled again, keeping original values where weight exists and filling elsewhere from coarser levels. It costs O(n), fills arbitrarily large holes in one pass and is smooth, unlike iterative dilation, which needs as many rounds as the hole radius and leaves concentric rings.

Output layers: the texture in the chosen layer, mask (texels actually seen by a view; dilated and filled texels are not counted, so it shows where another view is needed) and views (number of views per texel, to find areas held up by a single view).

Inputs

Outputs

Parameters