Before we start here is a first screenshot to open your appetite and demonstrate what can be done with 3D Tiles and 2D S-57 marine navigation data.
Specification status
The 3D Tiles format has been around for a few years as part of CesiumJS and it is now moving to become a standardized format supported by many 3D display engines.
Today the specification is open to the community for review: OGC Seeks Public Comment on 3D Tiles Candidate Community Standard
What can we do with 3D Tiles ?
format overview
The format is actually just a packaging method rather than a real binary definition.
There are 4 different 3D Tiles:
- B3DM : Batched 3D Models
Likely the one most developers and users will deal with. The structure has few limitations and only decorates a Khronos GLTF file + raw binary assets + feature attributes mapping (called feature table).
This only tile format can do it all and replace all the other ones but you will have to deal yourself with OpenGL, GLSL, assets, geocentric/geographic maths and all the troubles and limitations of WebGL and browser compatibility issues.
Anything (within the limits of GLTF) can be rendered: billboards, meshes, videos, animations… as long as you have enough skill to code it.
- I3DM : Instanced 3D Models
This one is convenient to render a same 3D model many, many times. It is actually a higher level version of OpenGL “Instanced Rendering” but for complete meshes, not just draw calls.
Each model can be modified a little, it’s size or orientation for example. So you should use this format if you have a lot of similar features: trees, road signs, electric pylons…
- PNTS : Point Clouds
Another specialized version of 3D Tiles, this time for points. Nothing much to say here. If you have a lot of points to display with only little styling needs, basically only changing the color plus some fancy effects in JavaScript and that’s it. Unlike the previous tile format, you won’t need to do any GLTF or OpenGL.
- CMPT : Composite
The composite format exists for more pragmatic reasons, to reduce network queries and speed up loading. This tile is only a stack of tiles packed together.
And to organize all of it, we find a TileSet file in JSON describing how tile are related to their parent.
few clarifications
Unlike what we find in WMTS or TMS, 3D Tiles are not place on a regular grid and child tiles don’t always replace their parent. The tiles tree can take any shape, tile region can overlap, be one above the other, anything, being in 3D allows a lot of freedom.
For example if you have a building, when you are far away you have a first tile with a rough cube. Then, when getting closer a more accurate tile replaces the parent, and zooming again a high definition model appears with proper textures. That the casual use case.
Let’s take a different scenario, we have wind arrows rendered as billboards. At high scale the tile contains only one arrow every hundred points. Then, when zooming in, a child tile is added (not removing the parent) which contains one arrow every 10 points and so on… It’s a progressive refinement. But it’s not possible with all data types.
The technical side of 3D Tiles
- Even if data are rendered on a globe or a map, it feels like 3D Tiles isn’t really related to the geomatics fields. You have two coordinate systems: geocentric and latitude/longitude sometimes in degrees, sometimes in radians. The format is too low level to be used by geomaticians alone. You will need developer skills to build the files and good knowledge of OpenGL and GLSL programming to achieve fancy results.
- To produce data you will have to do all reprojection and resampling yourself, and you better be right with your maths or you won’t see anything and no error will be displayed. And if you have some errors they will likely be the unclear exceptions raised by OpenGL.
- Another technical area concerns the GLTF, GLTF 2.0 binary form which is still really new. 3D tools don’t have yet export tools for it and when they will, the problem of compatibility with the various 3D Tiles engines will come too. It is likely that some tiles produced by tools will only work with a limited set of 3D engines. There are so many 3D model formats, even more than images out there. When we see the mess it is with just netCDF, grib, geotiff and jpeg2000, compatibility problems with 3D Tiles are guaranteed to happen.
Let’s hope the OGC will set up a test suite for this format and the 3D engines, like it is the case for WMS.
Where is 3D Tiles compared to OGC and ISO specifications ?
Like OGC-KML (ex Google KML), 3D Tiles, as a community standard doesn’t have any obligation to use the existing specifications, no metadata, no symbology encoding, no services, no geometries, no filter, no CQL.
- Feature: We could have expected the feature-table model of 3D Tiles which is in JSON to look like GeoJson since it serves vaguely the same objectives (without the geometry) but again it isn’t, it is quite different. For performance reasons, properties are packed in long arrays indexed by an integer identifier.
- Symbology: It would have been nice to share some style and ruling elements or a little of OGC Filter encoding, or perhaps having some relation with 3D Symbology encoding drafts, but no luck either.
- Geometry: 3D Tiles is in 3D obviously, and ISO 19107 aside, there is no real specification to define 3D geometries. ISO 19107 is so complex and unsuitable for GPU processing that we can’t blame 3D Tiles for not using it.
Like at the time when Google proposed KML to the OGC, the format was already done and made for GoogleEarth / GoogleMaps, the same thing is repeating here but for CesiumJS.
3D Tiles is in a different world, it talks JSON, JavaScript-ish regex/filters and GLSL.
Geomatys and the 3D Tiles format
Geomatys teams played with 3D Tiles for some time, and with the various 3D formats of cesium, including CZML, height maps and quantized meshes over the last years. It results a mixed feeling.
The GIS world was missing a first 3D format to start with and 3D Tiles fill the gap nicely without imposing to much constraint. It’s actually a breeze of freedom thanks to GLTF.
However, it’s difficult to see 3D Tiles as a GIS format, it doesn’t reuse what we are used to in GIS.
All the referencing, reprojection, transformation doesn’t appear in the format. It is all baked ahead of time by a 3D tiles generator. 3D Tiles is the end of the line product only for rendering. It would have been cool to create a 3D tile, declare somewhere that the tile is in EPSG: 3031 (stereographic polar) or some engineering coordinate system used by moving features and let the 3D engine do the work.
Finally, 3D Tiles is a nice format after all, a first normalized step in the 3D world for GIS. That’s why, Geomatys implements it on its Examind Server platform.
Nautical charts display in 3D Tiles
Let’s see what we can do with 3D Tiles and IHO S-57 / S-52 data.
IHO S-57 format and S-52 symbology are standards used for marine navigation. If you are interested you can find more information on my previous post here: Between GIS and ECDIS, S-57 and S-52 for marine and military fields
Keep in mind that S-57 data are not made for 3D visualization, but they manage to end up in pretty 3D Tiles.
A 2D S-57 navigation map:
And in 3D, we obtain the following:
At low resolution, we display the S-57 cells by a bounding box and identifier label.
When getting closer, the bounding box is replaced by the terrain elevation computed from S-57 bathymetry, cost-line, height points and other data.
Getting closer again, we can see the various S-52 symbols and a light cone animated coming out of the lighthouse.
With S-57 data over a city harbour, we can see the docks and buildings.
The overall quality depends on the S-57 file. They aren’t made for 3D and inland data aren’t their main purpose so some glitches appears.
For more information about Examind and 3D Tiles, please contact Geomatys teams.
One thought on “3D Tiles in action for ENC”
An impressive share! I have just forwarded this onto a co-worker who has been doing a little
homework on this. And he in fact bought me lunch simply because I stumbled upon it for
him… lol. So let me reword this…. Thanks for the meal!!
But yeah, thanx for spending time to discuss this subject here on your blog.