mirror of
https://github.com/bherbruck/solidcraft.git
synced 2026-11-08 13:01:52 +00:00
e6dc105134
* Point clouds: insert PLY, XYZ and PTS scans as a modelling reference (#5151) A point cloud is kept in the design as a reference, drawn as depth-tested dots and never a body. - io: a PLY reader (ASCII, binary little/big endian; x, y, z of any numeric type, optional colours, other elements skipped; counts checked against the file) and XYZ/PTS text, thinned evenly past max_points. PLY meshes with faces can also come in through file.insert_mesh. - doc: Document.point_clouds (shared f32 points relative to an f64 origin, colours, units, rigid placement, size and colour), stored as a binary container part; format change in pending/point-clouds.rs. - engine: pointcloud.insert / edit / delete / list; doc.open opens a cloud as a new design; selection.delete takes point_clouds; view bounds include them. - gpu: an instanced point-sprite pipeline (16 bytes a point). - ui: Browser Point Clouds folder with eyes, menu and an Edit Point Cloud card; drop, Open, Insert and file dialogs take .ply/.xyz/.pts; a CPU viewport fallback; messages in en, en-GB, ja, zh, de and ko. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Point clouds: colour by the file, one colour or height, from the UI (#5151) The Edit Point Cloud card gets Color By (File Colors, Single Color, Height). Height is a blue-to-red ramp over design Z, between the cloud's own two heights or, by default, a range worked out from the points (all but the lowest and highest 2 %, from an even sample). pointcloud.insert and pointcloud.edit take color_by and height_range; pointcloud.list reports them. The colour of each point is worked out in one place (PointCloud::shade) for the GPU and CPU viewports. Also: the card's dropdowns compare the picked index (a dropdown's response doesn't report the pick, so File Units did not change either). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Point clouds: integrate format registration and viewport caches (#5151) * Point clouds: satisfy current UI audits and document comparisons (#5151) Route model RGB data through the theme conversion boundary, provide a compact ribbon label, and include point clouds in the new document comparison. Gate the Unix-only CLI-link helper and test so Windows all-target checks remain buildable after the rebase. * Point clouds: isolate translations for current main (#5151) Move the existing 74 messages unchanged into one pending locale file and attribute it through a pending row, following the current repository workflow. Repository checks, 50 tooling tests, final workspace Clippy, wasm and generated-catalog equality checks passed after the rebase. * Point clouds: fit the rebased code to main's GpuTarget and Frame Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Compare point clouds when reusing placement-independent results Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * Point clouds: complete command help and required translations (#5151) * Point clouds: size the save cap from the raised limit after the rebase Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: bherbruck <brennen.herbruck@gmail.com>
59 lines
3.3 KiB
Markdown
59 lines
3.3 KiB
Markdown
# Point clouds
|
||
|
||
A point cloud is scanned points kept in the design as a reference to model from (#5151): a
|
||
lidar or SLAM map, a photogrammetry result, a part from a handheld scanner. It is drawn as dots
|
||
in the viewport, depth-tested with the bodies, and never becomes a body; nothing in the timeline
|
||
depends on it.
|
||
|
||
## Files
|
||
|
||
| Extension | What is read |
|
||
|-----------|--------------|
|
||
| `.ply` | ASCII, binary little-endian and binary big-endian PLY: the `vertex` element's `x`, `y`, `z` (any numeric type) and its `red`, `green`, `blue` when present (bytes, 16-bit or 0…1 floats). Other properties (normals, intensity) and elements are passed over. |
|
||
| `.xyz`, `.pts` | Text, a point per line: `x y z`, optionally followed by `r g b` (six numbers) or by an intensity and `r g b` (seven or more, as PTS files write it). Spaces, tabs, commas or semicolons separate the numbers; `#` and `//` start comments; a PTS file's first line (its count) is skipped. |
|
||
|
||
A PLY file that also has faces can be inserted as a mesh body instead with **Insert Mesh**
|
||
(`file.insert_mesh`); **Insert Point Cloud** then mentions it in its warnings.
|
||
|
||
Point cloud files say nothing about their length unit. `units` (`mm`, `cm`, `m`, `in`, `ft`)
|
||
says what it is; the default is millimetres, as for every other import. Lidar and SLAM maps are
|
||
usually in metres. The unit can be changed afterwards (Browser › Point Clouds › Edit Point Cloud,
|
||
or `pointcloud.edit` with `units`): the points are scaled from the unit they came in as.
|
||
|
||
## Colours
|
||
|
||
**Color By** in the Edit Point Cloud card (or `color_by`) says how the points are coloured:
|
||
|
||
- `file` (the default): the file's colour of each point, grey when it has none.
|
||
- `single`: one colour (`color`) for every point.
|
||
- `height`: a ramp by design Z, blue low through cyan, green and yellow to red high. It runs
|
||
between two heights (`height_range`, mm). By default they are worked out from the points: all
|
||
but the lowest and highest 2 %, so a few stray points don't flatten the ramp. Turn
|
||
**Automatic Range** off in the card to set them.
|
||
|
||
## Size
|
||
|
||
A cloud keeps at most `max_points` points (5,000,000 unless asked, at most 20,000,000); a larger
|
||
file is thinned evenly, one point in *n*, and the result says how many were kept. Files up to
|
||
1 GiB are read. The points are stored single precision relative to the cloud's first point (kept
|
||
double precision), so a scan far from the origin keeps its detail; they travel inside the design
|
||
file as a binary part (12 bytes a point, 3 more with colours).
|
||
|
||
## Commands
|
||
|
||
- `pointcloud.insert` — `path`; `name?`, `units?`, `max_points?`, `center?` (move the middle of
|
||
its base to the origin), `point_size?` (pixels), `color_by?` (`file`, `single`, `height`),
|
||
`color?` (`[r, g, b]` 0…1; alone it means `single`, `null` means `file`), `height_range?`
|
||
(`[low, high]` mm, or `null` for the automatic range).
|
||
- `pointcloud.edit` — `cloud` (id or name); `name?`, `visible?`, `point_size?`, `color_by?`,
|
||
`color?`, `height_range?`, `units?`, `matrix?` (a rigid placement, as `occurrence.move` takes it).
|
||
- `pointcloud.delete`, `pointcloud.list`.
|
||
- `doc.open` opens a point cloud file as a new design holding it; dropping one on the window
|
||
adds it to the open design.
|
||
|
||
## Example
|
||
|
||
```json
|
||
{"command": "pointcloud.insert", "params": {"path": "glim-points.ply", "units": "m", "color_by": "height"}}
|
||
```
|