Skip to content
Draft
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
47 changes: 47 additions & 0 deletions proto/viam/common/v1/common.proto
Original file line number Diff line number Diff line change
Expand Up @@ -89,8 +89,55 @@ message Mesh {
bytes mesh = 2;
}

// PointCloudHeader contains all the metadata required to interpret the binary data blob.
message PointCloudHeader {
// Describes the dimensions and their order for each point, e.g. ["x", "y", "z", "rgb", "intensity", "normal_x"].
repeated string fields = 1;

// The size of each dimension in bytes. For example, for five float32 fields this would be [4, 4, 4, 4, 4].
repeated uint32 size = 2;

// The data type of each dimension, corresponding to the 'fields' list.
repeated PointCloudDataType type = 3;

// The number of elements in each dimension. This is typically 1 for most fields like 'x' or 'rgb', but can be
// larger for feature descriptors.
repeated uint32 count = 4;

// Width of the point cloud. For unorganized clouds this is the total number of points.
uint32 width = 5;

// Height of the point cloud. For unorganized clouds, this is 1. For organized clouds, this is the number of rows.
uint32 height = 6;

// The acquisition viewpoint of the data, specifying the sensor's pose. This is optional but highly recommended
// for sensor fusion and accurate visualization tasks.
optional common.v1.Pose viewpoint = 7;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not a frame of the sensor that captured it? that's what we currently do with pointclouds in the visualizer. pointclouds are returned from camera methods in local space and we child them to the camera frame. it allows us to show both local and world pose information

Copy link
Member

@micheal-parks micheal-parks Oct 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess though if this is just modifying the proto message then we can still determine the frame using the above strategy. would viewpoint here potentially mean some other kind of offset with respect to the sensor frame?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can do either, but I am thinking more from an ergonomics standpoint. I imagine it would be easier to work with just the pose than the entire frame object when using this API. I also feel like the Pose is less likely to change (at least in the near future) as opposed to the Frame.


// For partial updates, this specifies the starting element offset in the client's buffer where this new data
// should be written. If this field is absent, the message is treated as a full point cloud replacement.
optional uint32 start = 8;
}

// PointCloudDataType enumerates the fundamental data types for point cloud fields
enum PointCloudDataType {
POINT_CLOUD_DATA_TYPE_UNSPECIFIED = 0;
// For signed integer types (int8, int16, int32)
POINT_CLOUD_DATA_TYPE_INT = 1;
// For unsigned integer types (uint8, uint16, uint32)
POINT_CLOUD_DATA_TYPE_UINT = 2;
// For floating-point types (float32, float64)
POINT_CLOUD_DATA_TYPE_FLOAT = 3;
}

// A PointCloud separates the descriptive metadata from the raw binary data, allowing for efficient network
// transport and zero-copy parsing on the client-side for rendering.
message PointCloud {
// The point cloud data, stored as a single, packed binary blob.
bytes point_cloud = 1;

// The header defining the structure of the data blob.
PointCloudHeader header = 2;
}

// Geometry contains the dimensions of a given geometry and the pose of its center. The geometry is one of either a sphere or a box.
Expand Down
Loading