Module points

Point clouds from points::array, points::base64, and pcd::base64 (ifcx_alpha).

Decoding follows the upstream reference viewer (src/viewer/render.ts and three.js PCDLoader r171 at buildingSMART/IFC5-development 1a63082):

Attribute	Value	Binary layout
points::array	{positions: [[x, y, z], …], colors?: [[r, g, b], …]}	—
points::base64	{positions: "<base64>", colors?: "<base64>"}	little-endian f32 triples back to back: 12-byte stride, no header
pcd::base64	"<base64 of a .pcd file>"	PCD v0.7 ascii, binary, or binary_compressed, fields x y z and optional rgb

When a node carries several of them, PointCloud::from_attributes uses the first of pcd::base64, points::array, points::base64, the order of the upstream viewer.

Numbers

Positions are f64 like every coordinate in this crate (see crate::math). points::array keeps the JSON numbers exactly, where the upstream viewer narrows them to f32; the f32 values of the binary encodings widen losslessly, and ASCII PCD coordinates are rounded to f32 as the loader does unless the header declares SIZE 8. Colours are f32 linear RGB in 0..=1: array and base64 colours are used as written, and 8-bit PCD rgb is converted from sRGB to linear as three.js does.

Copies

points::base64 decodes in fixed 12 KiB chunks straight into the output vector, which is allocated once at its final size, so the decoded bytes never exist as a second full-size buffer. pcd::base64 decodes the file bytes once, since its header and layout are only known after decoding; binary_compressed additionally needs the LZF output. Points are then read from that buffer without further copies. Base64 text with embedded ASCII whitespace, which browsers’ atob accepts, is first copied without it.

Structs

PointCloud

Decoded points of one node, in the node’s local coordinates.

Constants

PCD_BASE64

Attribute id of a point cloud given as a base64 PCD file.

POINTS_ARRAY

Attribute id of a point cloud given as JSON arrays.

POINTS_BASE64

Attribute id of a point cloud given as base64 f32 buffers.