TransformPointCloud

Point clouds in this pack are [N,7] tensors - three coordinates and four attribute channels (RGB plus room to grow) per point. TransformPointCloud takes one of those and a 4x4 matrix, applies the matrix as a rigid transform to every point's XYZ, and leaves the color/attribute columns completely alone. Output is another [N,7] cloud. That's the whole job, and it's the node that makes "walk around to the other side of the scene" possible.

Mechanically it's textbook: coordinates get padded with a 1 into homogeneous coordinates, multiplied by the matrix, and stripped back down to XYZ. Because the attributes ride along untouched, your colors stay glued to the right points - no relabeling, no re-mapping. If your matrix is a proper rigid transform (rotation + translation, which is what TransformToMatrix and TransformToMatrixManual produce), you get a clean rotated-and-shifted cloud; throw in non-uniform scaling or shear and points will stretch in ways that can look wrong in a pinhole render but are technically legal.

Inputs are exactly two: pointcloud (TENSOR, [N,7]) and transform_matrix (MAT_4X4). One output: transformed pointcloud.

Where it slots into a real workflow:

• Point-cloud walkers. The pointcloud_walker demo moves the cloud under the camera and re-renders each frame with ProjectPointCloud, producing a fly-through that never reveals the depth-map seams behind it - well, until you move too far and hit the disocclusion wall, at which point the pack's inpainting nodes take over.
• Grounding a floating scene. Estimate depth, lift to a cloud, then use TransformPointCloud to nail it to the world origin before you hand it to ProjectPointCloud for a novel view.
• Any time a matrix lands in your graph. TransformToMatrix and TransformToMatrixManual output MAT_4X4, and this is their natural consumer alongside RotateSplats for gaussian splats.

Two things worth knowing. First, the matrix convention here is "apply to the cloud," not "move the camera" - translating the cloud forward with shiftZ is the same visual result as pulling the camera back, so pick whichever reads better in your head and stay consistent. Second, TransformPointCloud does not normalize or re-sort anything; points that were valid stay valid, and points the transform pushes behind the camera only become a problem at render time (that's ProjectPointCloud's job to handle).

No heavy dependencies - no CUDA, no models, just tensor math. Install the pack via ComfyUI Manager (search camera-comfyUI, Install, restart), or:

git clone https://github.com/Alexankharin/camera-comfyUI.git custom_nodes/camera-comfyUI
cd custom_nodes/camera-comfyUI && python install.py

It's a boring node, and that's its charm. When the camera-move workflow you're assembling needs the world to shift under it, this is the unglamorous hinge everything else hangs on.