Blender 5.3 Imports Gaussian Splats Cleanly, But No Native Export Preserves Them

Blender 5.3 can bring Gaussian splats in through four different file formats, but none of its native exporters produces a complete, web-readable splat on the way out. That is the headline finding of a hands-on test published on dev.to on 12 November 2026 by Alicia, a 3D technical artist and independent developer, run against the 5.3.0 release build (compiled 10 November 2026) on a Windows 11 workstation with a Ryzen 9 9950X and an RTX 5070 Ti.

Four imports, one splat source

The fixture was a synthetic plant fit — not a photographic scan — of 12,000 splats, originally trained in a Houdini study from 24 Karma renders. It reached Blender as a roughly 3.1 MB standard 3DGS PLY, a 236 KB lossy SPZ v3 derivative, a USD particle field and a locally repacked glTF using the KHR_gaussian_splatting schema.

All four paths produced the same result: a POINTCLOUD object typed GAUSSIAN_SPLAT with 12,000 points, per-splat scale, quaternion rotation, a four-component base radiance attribute and 15 spherical-harmonics vectors. Single operator timings ranged from 2.79 ms for PLY to 43.55 ms for the glTF repack, with SPZ at 4.13 ms and USD at 33.44 ms — though the author stresses these are diagnostics, not a format speed ranking. Orientation handling differed per format: the PLY arrived as identity and needed a manual X+90° rotation for Z-up inspection, while the SPZ, USD and glTF importers each handled the axis conversion themselves.

Cropping is lossless if you inspect evaluated geometry

A Geometry Nodes crop that deleted points with X > 0 cut the plant to 5,906 splats. Checked against a source_id attribute, every survivor matched its original record exactly: positions, scale, rotation, base radiance and all 15 SH vectors showed a maximum absolute difference of zero. The test's key scripting warning is that reading object.data directly still reports 12,000 points, as if the modifier had done nothing — real counts and attributes only appear through the depsgraph-evaluated geometry.

Applying transforms fragments the render

On a duplicate carrying X+90° and Z+90° rotations plus a uniform scale of 2, applying the transforms moved point centers correctly, agreeing within 5.95 × 10⁻⁸. But the scale, quaternion and SH attribute arrays did not change at all, and paired renders from an identical camera visibly fragment after application. This reproduces a limitation Blender documents itself. The practical guidance is to keep object transforms unapplied, because a correct transformed-splat exporter would need to rotate covariance and SH coefficients too.

Renders and a bounded relighting probe

Sequential single renders clocked Workbench at 0.83 s, EEVEE at 3.42 s with 128 samples, and Cycles with OptiX at 0.87 s with 64 samples and no denoising; the cropped plant rendered in 0.29 s in Cycles. A relighting probe that swapped the splat material for a gray Diffuse BSDF plus a point light produced a lit grayscale plant in about half a second — it did not recover the plant's learned albedo, and baked-illumination removal was not tested.

Every export fell short

Each native export was reopened in a fresh, empty Blender scene, and success messages proved meaningless. File creation, point preservation and splat preservation turned out to be three different outcomes:

• PLY with the modifier enabled: 156 bytes written, header declares zero vertices, native reimport fails.
• GLB with defaults: 144,664 bytes of 12,000 ordinary mesh vertices — the crop was skipped and splat attributes vanished.
• GLB with export_apply=true: no output; Blender raises an error that the object does not have geometry data.
• GLB after baking the modifier first: 5,906 ordinary mesh vertices, still no splat attributes.
• USD: 2,666,502 bytes, a 5,906-point cloud keeping scale, rotation and SH but dropping base radiance.
• Alembic: 5,906 points keeping scale and renamed SH but dropping rotation and base radiance.
• No SPZ export path was available to test.

The result matches Blender's own 5.3 release notes, which state plainly that there is currently no export support for splats, alongside documented limitations around color and applying transforms.

Why it matters

Native import means splats no longer need add-ons to enter Blender, and Geometry Nodes gives artists a genuinely lossless way to trim them. But the pipeline is one-way: any workflow that needs cleaned-up splats in a web viewer — the test's browser lab used Three.js 0.186.1 and Spark 2.3.1 — must rely on external tooling or custom writers. Two pitfalls in particular will bite scripters: evaluated-versus-base geometry when counting points, and the data loss from applying transforms. Until export support lands, treat Blender 5.3 as a capable splat viewer and editor rather than a round-trip tool.