Entwine: indexing point clouds into tiles a browser can read

What Entwine does with a point cloud

Entwine is a data organization library for massive point clouds, designed to conquer datasets of hundreds of billions of points as well as desktop-scale point clouds. The repository description calls it point cloud organization for massive datasets.

The word organization is the one to hold on to. Entwine is not a renderer, not an analysis package and not a point cloud format of its own invention that replaces the data. It takes a point cloud you already have and reorganises it into a tiled structure, the Entwine Point Tile format, so that a client can fetch the pieces it needs rather than downloading everything.

That distinction is the entire point. A point cloud of a hundred billion points is not a file anyone can download, and even a desktop-scale one becomes unwieldy. Splitting it into a spatial hierarchy, each tile carrying its own metadata and a bounding box, turns one enormous object into many small ones that a web client can request on demand as the user moves around.

The input side is broad by design. Entwine can index anything that is PDAL-readable, and PDAL is the point data access library, so the set of supported inputs is PDAL's set rather than a list Entwine maintains. On the output side it can read and write to a variety of sources like S3 or Dropbox, which means the resulting index can live in object storage rather than on the machine that produced it.

The claim on losslessness is strong and worth quoting carefully. The README says builds are completely lossless, so no points will be discarded even for terabyte-scale datasets. For a data processing tool, that is a meaningful guarantee, because a pipeline that quietly drops a fraction of a percent of a survey is a pipeline you cannot trust without checking, and checking means comparing full datasets.

The primary language is C++, the homepage is entwine.io, and the licence is recorded as one GitHub cannot classify, with a `COPYING` and a `LICENSE` file in the tree.

The EPT format and the alternative that also produces COPC

The output format has its own name and its own documentation, and understanding it is necessary to use the result.

Entwine produces the Entwine Point Tile, or EPT, format, and the file format documentation is on the project site. A tiled hierarchy of this kind is what a Potree or Cesium style client expects, and the README links to demo clients: the Cesium viewer with a sample data set, and Potree.

The format is not the only way to get a tiled point cloud, and the README is helpful about the alternative. For an alternative method of generating EPT which can also generate COPC data, it points to the Untwine project. COPC is the Cloud Optimized Point Cloud format, and the distinction matters in practice.

Untwine is described as an alternative method of generating the same EPT output that can also produce COPC, which means it covers both formats while Entwine covers one. If your downstream consumer expects COPC rather than EPT, that is a decision point, and the README sends you to a different project for it. For a reader choosing between the two, the difference in approach is that Entwine is the older path to EPT with the PDAL-based input support and the S3 and Dropbox output, while Untwine is the path that also lands you in COPC.

The configuration documentation is where the details live, at entwine.io/configuration.html, and the README says it covers reprojecting your data, using configuration files and templates, enabling S3 capabilities, and all sorts of other settings. Reprojection is the one to note: a tile hierarchy is only useful if the tiles share a coordinate reference system, and the ability to reproject during the build is what makes a source dataset with a different CRS usable by a web client at all.

Building an index, and then serving it

The usage section is a four step tutorial, and it runs end to end on public data.

First, create a conda environment with the `entwine` package and activate it:

conda create --yes --name entwine --channel conda-forge entwine
conda activate entwine

Then build an index over a public dataset:

entwine build \
    -i https://data.entwine.io/red-rocks.laz \
    -o ~/entwine/red-rocks

The output lands at `~/entwine/red-rocks`. The README notes you could have also passed a directory like `-i ~/county-data/` to index multiple files, which is the case that matters when you have a county survey split into tiles rather than one file.

Serving the result is a matter of putting the directory behind a static HTTP server:

docker run -it -v ~/entwine:/var/www -p 8080:8080 connormanning/http-server

And then pointing a client at it, with the Cesium viewer and the Potree client both given as links that take the `ept.json` metadata URL. The `ept.json` file is the entry point of the index, the thing a client fetches first to learn what tiles exist and where they are.

The shape of that workflow is worth pausing on. Because the output is a static directory of files, the serving layer is deliberately dumb. There is no server process to run, no API to authenticate against, no state to keep. Any static file host works, which is what makes the S3 and Dropbox output options coherent rather than a special feature.

The build system and the platforms that are tested

The repository layout is that of a C++ project built with CMake and distributed through conda, and the CI badges at the top of the README name the platforms.

There are separate workflow badges for OSX, Linux and Windows, plus one for Docs, one for Conda and one for Docker. That is an unusual spread for a point cloud library, and it tells you something about the intended usage: the library is expected to run on the machine producing the index, which is often a workstation, and the Docker badge says the same thing about containerised builds.

The top level contains `CMakeLists.txt`, a `cmake/` directory for the CMake modules, an `entwine/` directory for the library source, an `app/` directory for the command line application, a `config/` directory, a `scripts/` directory, a `test/` directory, and `doc/` for the documentation with a `.readthedocs.yaml` configuration. The presence of a dedicated `doc/` tree with its own readthedocs configuration is notable, since the documentation site at entwine.io is where the configuration and file format references live.

Building through conda rather than a plain CMake invocation is the documented path for users, and the `Conda` badge tracks that channel. The `Docker` badge tracks a container build, which pairs with the `connormanning/http-server` image used in the serving step, although that image is a separate project from this repository.

The three operating system badges matter for a specific reason. A tool that indexes a hundred billion points has to read them from somewhere, and the input formats it handles are the ones PDAL handles, which differ by platform in their codec support. A build badge per operating system is a statement that the input matrix is not uniform.

Where Entwine is the wrong tool

The first wrong-tool case is analysis. If the question is how many points fall inside a polygon, what the elevation distribution looks like, or how a cloud differs from last month's, then the answer is a tool that answers questions, not one that reorganises files. Entwine's output is an index for a client, and the client is where the analysis or the rendering happens.

The second is a dataset small enough to serve directly. The README says Entwine is designed to conquer datasets of hundreds of billions of points as well as desktop-scale point clouds, and that is a genuine range, but a single cloud of a few million points that fits in a browser over HTTP does not need a spatial index, and building one adds a build step and a second copy of the data to keep in step with the first.

The third is a pipeline that needs COPC specifically. The README is explicit that Untwine is the route for a method of generating EPT that can also generate COPC, and the two have different format targets, so choosing the wrong one means rebuilding the index later.

The fourth is a format PDAL cannot read. The input support is inherited rather than native, which is a strength in terms of breadth and a constraint in terms of control. If you need a format that PDAL does not handle, you need a conversion step before Entwine, and that conversion is where points can be lost, which sits awkwardly against the lossless claim about the build itself.

The alternative worth naming is Untwine, and the difference in approach is worth being precise about. Untwine is a separate project that also produces EPT and can additionally produce COPC, so for a COPC consumer it is the direct comparison. The other comparison is doing nothing: keeping the original file and having the client read it directly, which is fine at small scale and impossible at the scale Entwine targets. Entwine's case rests entirely on the tiled, served-over-HTTP, browsable experience.

Maintenance state and what the licence situation is

The last push to the default branch was on 2026-06-02, and the recent releases are 3.2.1 dated 2025-10-15, 3.2.0 dated 2025-08-27 and 3.1.1 dated 2024-04-05. The repository is not archived, and the release numbering shows the project moving through 3.1, 3.2 and 3.2.1 over a couple of years.

The June 2026 push is recent enough that the project is not dormant, but the release tags are not recent either, and there is no sign in the README of a rapid release cadence. The honest assessment is that the code is being worked on, with the last push on 2026-06-02, and that the published versions move at a measured pace rather than continuously. Anyone depending on it should pin a version rather than tracking the branch.

The licence is the one loose end. The project listing records it as a custom licence that GitHub cannot classify, and the instruction is to see the LICENSE file. The tree carries both a `COPYING` file and a `LICENSE` file, which is a common pairing for software that also bundles third-party licence texts, since a C++ project linking against libraries such as PDAL, zlib or GDAL typically has to reproduce their notices. The practical point is that the terms are in the repository and should be read directly rather than inferred from the fact that the project is public.

For an adopter, the concrete next step is small and testable. Build an index over one public dataset, serve it with the static HTTP server, and open it in a viewer. That exercises the input path, the tiling and the metadata in one go, and it tells you whether the lossless claim holds for your own source format before you point it at a survey worth more than the build.

Editorial conclusion

Adopt Entwine when you have a point cloud too large to ship as a single file and need it served over HTTP to Cesium or Potree, since the tiling, the chunking and the metadata index are the whole job and Entwine does that without discarding points. Do not adopt it as a viewer or an analysis tool, because the output is an index for a client to consume, and the actual rendering happens in Cesium or Potree. Before you build on it, confirm the source format is readable by PDAL, decide whether the EPT output is enough or whether you need COPC, since the README points to Untwine for the alternative that can also produce COPC, and check the `COPYING` and `LICENSE` files in the repository, because the licence is recorded as one GitHub cannot classify.

Frequently asked questions

Official sources

1. connormanning/entwine on GitHub
2. Issues
3. Project website
4. README
5. Releases