DA3_SavePointCloud

Short and useful: this node writes a point cloud to disk as a .ply file so you can open it in something that isn't ComfyUI. Blender, MeshLab, CloudCompare, a Gaussian splat viewer - they all read .ply. Without this node your point cloud lives and dies inside the graph. With it, you've got a file you can actually work with.

This is the last stop in the single-image 3D chain: DepthAnything_V3 (in Raw mode) → DA3_ToPointCloud → DA3_SavePointCloud. The pack's author confirmed the export path directly when people asked "can I use this in Blender?" - yes, it exports a .ply, and that's this node doing it.

How it works

There's not much to it, which is the point. It takes a pointcloud input and a filename_prefix (default pointcloud), serializes the points - positions and colors - into the .ply format, and saves the file. It's an output node, so running the graph writes the file; the saved path comes back as the file_path string output if you want to feed it somewhere else (a downstream viewer, a logging node, whatever). That's the entire interface. Two inputs, one output, no knobs to get wrong.

The only input you'll ever change is filename_prefix, and only if you want your files named something more useful than pointcloud_00001.ply. Set it to the scene or shot name and your output folder stays readable.

Where the file lands and what to do with it

The .ply goes to your ComfyUI output directory. From there it's a standard, boring, wonderfully portable format:

• Blender - File > Import > Stanford PLY. The points come in with color. From there you can mesh them, particle them, or use them as a reference to model against.
• CloudCompare / MeshLab - the serious point cloud tools, for cleaning, aligning, or converting.
• Gaussian splat viewers - if your cloud came from the Gaussian path, a .ply is the native splat container.

.ply is a good default because it stores per-point color, which is exactly what you get out of DA3_ToPointCloud when you pass it a source_image. That's why "photo to colored 3D dots to Blender" works in three nodes.

Common issues

If the saved cloud looks sparse, the fix isn't here - it's upstream. DA3_ToPointCloud defaults downsample to 5 to keep the preview fast, so before your final save, lower that value for a denser export. This node just writes whatever it's handed.

If the file is huge and slow to open, that's a genuinely dense cloud - either accept it, downsample upstream, or thin it in CloudCompare after import. And if you connected this but no file appears, make sure the graph actually reached this node: it's an output node, so it only fires when its branch executes. A cloud that's still stuck behind a normalized-depth error two nodes back never gets here - check that DepthAnything_V3 is in Raw mode and DA3_ToPointCloud ran clean first.