Is the PotreeLoader usable?

[mfitzer]

I have a point cloud that's in the potree format and I'd like to visualize it with deck.gl's Tile3DLayer. I see on the 3D Tiles Loaders page a PotreeLoader is listed, but when I click on the link for documentation, I get a 404 not found page.

However, I found that I can still install the npm package @loaders.gl/potree. So, I did some digging to see if I could figure out how to use it:

• I found two GitHub issues on the subject, however, both look inactive
  • 3D Tiles/Potree tooling overview
  • Tracker: @loaders.gl/potree
• I then dug into the loader source code and found:
  • This initial documentation: @loaders.gl/potree README
    • I tried following this example supplemented with current examples for using the Tiles3DLoader
      • This example didn't actually show what the POTREE_URL should point to
  • I also tried looking at this test of the potree-hierarchy-chunk-loader to see if it could point me in the right direction
    • In this file, I noticed that the POTREE_HIERARCHY_CHUNK_URL is pointing to a file that I don't have in my potree data
  • Based on those different examples, it is not clear what the data url should be pointing to for the potree data
    • Part of the confusion is the fact that my potree data consists of 3 files generated by version 2.1 of the PotreeConverter whereas the PotreeLoader seems to be written for the old format that produced a large number of files
• Here is simplified example of my code:

import { PotreeLoader } from '@loaders.gl/potree';
import { Tileset3D } from '@loaders.gl/tiles';
import { load } from '@loaders.gl/core';

/*
  Potree Data Structure:
  ...some-location/potreeData
    - hierarchy.bin
    - metadata.json
    - octree.bin
*/

const potreeDataUrl = '...some-location/potreeData';

const potreeData = await load(potreeDataUrl, PotreeLoader);
console.log('loaded potree data', potreeData);

const potreeTilesetData = new Tileset3D(potreeData, {
  onTileLoad: tile => console.log(tile)
});
console.log('Tileset3D', potreeTilesetData);

To wrap up, here are the main questions I have:

• Is the PotreeLoader usable in its current state? If not, is there a timeline for when it will be usable?
  • I looked at the parse-potree-bin.ts file and saw that it just returns null, I'm assuming this means it is still in development
• Does the loader support output from PotreeConverter 2.1? If not, are there plans to support this in the future?
• Is there an up-to-date example of how to use the PotreeLoader?
• What should the data url point to?
  • I've tried point it to the parent directory and to each individual file in the directory
    • Pointing it to the metadata.json file actually loaded the json data but then the Tileset3D failed at line 270 of tileset-3d.ts with Unhandled Rejection (TypeError): Cannot read properties of undefined (reading 'refine')

[ibgreen]

@mfitzer You are correct. The potree effort was started but not completed. We were planning to get back to it but so far it hasn't happened.

FWIW completing potree support should be a small effort since it is such a simple format and we already support the much more complex I3S and 3D tiles formats. I'd certainly be happy to guide anyone who wants to try their hand at completing the work and I suspect the I3S maintainers would also be willing to help review.

For 2.1, we did get input from potree creator Markus Schütz on how to update to 2.1, also a small effort, but we obviously didn't get around to that either.

One of the problems with original potree datasets is that they tend to lack geospatial reference. The point clouds look awesome in isolation but are hard to position correctly on maps next to other geospatial data which is one of the main goals of the loaders.gl / deck.gl stack.

[mfitzer]

Hi @ibgreen, thank you for the quick reply!

If no one comes along to make the necessary updates to complete the potree support, do you have an idea when your team would get to it?

On your last point, would it be possible to take in a loader option to specify a coordinateOrigin similar to how the deck.gl PointCloudLayer is georeferenced?

Thanks for the help!

[ibgreen]

do you have an idea when your team would get to it?

Not really. Currently there is a lot of activity on tiled data formats in loaders.gl, building out full support for I3S (building scene layers etc) and also 3D tiles .Next, but potree seems to never quite make it to the top of the list.

On your last point, would it be possible to take in a loader option to specify a coordinateOrigin similar to how the deck.gl PointCloudLayer is georeferenced?

Yes that is of course a great idea. That would "anchor" it correctly if the app knows the location. But even so, the scale and orientation of the point cloud can be quite arbitrary (i.e. it positions might not be specified in meters and east-north-up coordinates).

[mfitzer]

Hmm, could a scale factor and 3D orientation also be provided as loader options to allow the app to transform the data as needed?

[ibgreen]

Absolutely. The issue is more that your app really needs to know a number of parameters about the tilesets, and providing those parameters is not super trivial for the user / developer. If you have them handy then no problem of course.

[mfitzer]

Right, that makes sense, good to know. Thank you for your help!

[Jingasan]

I hope potree is supported.

[nightvisi0n]

I'd certainly be happy to guide anyone who wants to try their hand at completing the work and I suspect the I3S maintainers would also be willing to help review.

@ibgreen Looking at the source code it seems nothing has changed in the implementation state since then. I've currently do not have much knowledge about the potree data format, but it seems that at least the parsePotreeBin function has to be implemented to get this working. Is there anything else that needs to be implemented to get the @loaders.gl/potree plugin ready?

I think the potree format is would be a great addition to loaders.gl (and deck.gl), since it's free and open source and has an excellent point cloud converter. Many other formats (3D Tiles, I3S) do not have easy to use and up to date open source converters which make these formats hard to use in projects that do not allow to use proprietary software.

[ibgreen]

@nightvisi0n

There is a small amount of work left to parse the different files.

The biggest part of the effort is to make the potree loader convert the parsed tiles and output a "normalized" tile structure, that can be understood by the tile traversal in the loaders.gl tiles module.

That normalized format just got a lot easier to work with as a pass was made to add typescript typings.

I'd be happy to pair up with and coach someone who is willing to do the work.

[ibgreen]

If you are interested in giving it a go and would like to discuss more in depth please sign up to the deck.gl community and ping me there.
https://deck.gl/docs/get-started/learning-resources#community

[jo-chemla]

Great to see that integration within loaders-gl of the the Potree v1.x and v2 formats is still on your mind and that ts typings will easen that effort!

Quick feedback regarding something you said earlier in this thread I just noticed: Potree datasets are indeed georeferenced, as long as the input pointcloud file has the point coordinates defined in a Coordinate Reference System that is well defined (via an EPSG code or proj4 string like UTM grid, lambert for france etc - which can by the way be stored within a las file VLR header). In potree, this CRS can be defined via a proj4js string within the cloudjs file, and point coordinates conversion from original CRS to another one could be computed via proj4 transform.

For example, all our 200 potree datasets on app.iconem.com are georef'ed and can be displayed on top of a google 3D-tiles or osm or cesium basemap as shown in this example.

[ibgreen]

Yes I believe georeferencing was added in a potree spec update that happened after those comments were made. Older potree files are probably not georeferenced. Still, good availability of newer georeferenced potree files does increase the value of completing this loader.

We do have proj4 support (e.g. via the complementary math.gl library).

However, I am not sure if our LAS/LAZ loader can extract that metadata. Would have to test on a file. Because that particular loader (LAS) is special in that it uses a compiled C++ -> JavaScript code chunk (instead of being written in TypeScript) and we are not able to add features (e.g. LAS 1.4 support etc)

[jo-chemla]

Thanks for the feedback. Our potree datasets have been georeferenced from 2015, because Potree does not do any assumption about the points coordinates, it just stores them as-is - with a slight compression - as well as a projection attribute which references a proj4 string of the CRS these coordinates are expressed in. I don't think Potree does read that CRS information from the las file headers during PotreeConversion, so what we do is input the CRS manually for every conversion by providing the converter CLI (or editing the cloud.js json structure afterwards) a proj4 string of that CRS.

Knowing that, the only thing required is knowing which CRS the coordinates are expressed in. If you have a non-empty projection attribute in the cloud.js, the original potree viewer will enable a minimap showing the footprint of the ptc and camera position on top of an openlayers basemap. Another official potree example mixes Potree pointclouds within its own threejs rendered with a synchronized cesium viewer (camera projection from the potree/threejs scene coordinates to cesium coordinates enable zero-shift perfect match), that's ~what we use on the showcase video above.

Regarding las reading, the loaders-gl reader will probably not rely on it other than parsing the raw points coordinates, color, and eventually extra attributes (intensity, classification, custom user attributes etc). What's most important is parsing the cloud.js file containing metadata, as well as all the hierarchy details of each tile of the tree - each bin/las pointcloud node has an accompanying hrc file which stores informatino about the hierarchy. Docs on file format for v1.7 on the official repo and with illustration from markus thesis on the propelleraero

Quick note, doing a search for las on the loaders-gl repo it seems like you use an old fork of lastools in the Model3DTiler dockerfile, schuetz/LAStools, while you could use the official LAStools which does support las 1.4.

[abhemanyus]

Are there any updates on this? From the looks of the @loaders.gl/potree implementation, I gather only Potree v1 is implemented.