Tracker: @loaders.gl/tiles about loaders.gl

[ibgreen]

@mcasebeer FYI

[veikkoeeva]

That Implement vector tiles, does it refer to tilesets in some format such as Mapbox vector tiles, something else or yet undefined? I see https://github.com/uber/deck.gl has integration with Mapbox and in that list there is also Map instanced model tile data to deck.gl, hence the question. Besides the questions, I for one, besides probably many others :), would be interest to know if there are thoughts about map applications regarding this.

Also apologies if this isn't the appropriate place to these sort of questions. Looks very good. Much appreciated!

[ibgreen]

That Implement vector tiles, does it refer to tilesets in some format such as Mapbox vector tiles

@veikkoeeva This refers to the vector tile variant of the 3D tiles specification. I believe they are still experimental. Maybe @loshjawrence can confirm.

We do have an implementation of mapbox vector tile loading in our companion framework deck.gl. It might make sense to move that to loaders.gl.

https://github.com/uber/deck.gl/blob/master/docs/layers/tile-layer.md

Not sure if that addresses your needs/interests?

[veikkoeeva]

@ibgreen Partially, I think. I've been thinking how to combine something like glTF assets loaded by BabylonJS together with georeferenced "charting data" and maps; maybe have the assets themselves be of chart like visualization data that ought be placed on a map and be interactive. Surely all this looks like becoming an interesting space.

[donmccurdy]

Do you plan to support the declarative styling specification and expressions from the 3D Tiles specification? Or would that be out of scope for this project? If not, do you know whether an open source, renderer-agnostic implementation exists yet?

[ibgreen]

Do you plan to support the declarative styling specification and expressions from the 3D Tiles specification?

@donmccurdy Ideally we'd like to support the full 3D tiles standard with all options and extensions, but due to the significant amount of work involved in this effort we decided not to tackle the styling part in the first version.

How far we go after that will depend a bit on uptake and interest (and yes, naturally, your question counts as interest).

From my quick review of the Cesium styling code it looks like (at least the framework independent parts of) styling support should be a fairly small and self-contained addition, it might even be a good fit for an external PR

Once we have dynamic tileset traversal in place, we should be able to wrap up the initial version and then we should make a list of the gaps (including styles) and re-evaluate efforts and priority.

If not, do you know whether an open source, renderer-agnostic implementation exists yet?

I am not aware of any, but as mentioned, the Cesium code base is open source, clean and has great test coverage, I have found it to be a very solid base for porting work.

Copying some Cesium folks @joshlawrence @lilleyse

[donmccurdy]

From my quick review of the Cesium styling code it looks like (at least the framework independent parts of) styling support should be a fairly small and self-contained addition, it might even be a good fit for an external PR.

Perhaps even an external module. 🤔 I'm imagining something similar to d3-scale that takes a style object as input and can then return visual properties for any given feature on demand:

import { styleEval } from '@3dtiles/style-eval';

const style = styleEval({ ... });
const fillColor1 = style.getFillColor( feature1 );
const fillColor2 = style.getFillColor( feature2 );

[ibgreen]

@donmccurdy I get the sense that you are looking for a reusable styling module to use in an independent context (i.e. not as a 3D Tiles feature?)

We also have stylesheet support in our XVIZ/streetscape.gl autonomy solutions:

• Spec
• Parser

[donmccurdy]

I get the sense that you are looking for a reusable styling module to use in an independent context (i.e. not as a 3D Tiles feature?)

I'm just curious at this point. I have possible use cases for 3D tiles feature data alone, for the style rules alone, and for both, but it's too early to say whether I'll move forward with anything.

The style rules in 3D Tiles seem to be the closest equivalent thing to being "standard" (it's an OGC Community Standard, at least) which makes them of some independent interest to me. Mapbox's style specification and the XVIZ styling looks functionally solid, but not on a standards track.

[ibgreen]

The style rules in 3D Tiles seem to be the closest equivalent thing to being "standard"

That is a good point. A downside is perhaps that 90% of the currently defined style fields are marked as experimental and are not officially part of the standard, but that could probably be addressed with a revision.

I have possible use cases for 3D tiles feature data alone, for the style rules alone, and for both, but it's too early to say whether I'll move forward with anything.

Understood. I really like the idea of loaders.gl being able to provide those pieces as independent building block.

I just spent some time checking what it would take to do an initial framework independent port of the 3D tile styles class (#262). It does pull in a bit more code than I originally thought, but it still seems like a basic port could be completed within a day or so, allowing styles to be created and features to be evaluated against it.

[pjcozzi]

That is a good point. A downside is perhaps that 90% of the currently defined style fields are marked as experimental and are not officially part of the standard

@ibgreen could you point me to these fields? There is a well-defined styling spec that is part of the 3D Tiles OGC Community Standard. There may be some "experimental ideas" beyond that but the core should be well defined at https://github.com/AnalyticalGraphicsInc/3d-tiles/blob/master/specification/Styling/README.md

[ibgreen]

@pjcozzi - I was just looking at https://cesiumjs.org/Cesium/Build/Documentation/Cesium3DTileStyle.html, where 23 of the actual styles are marked as experimental. I haven't compared with the styling spec.

[pjcozzi]

Ah, thanks @ibgreen, yes those properties are mostly for billboard/label fields that are not yet part of the 3D Tiles OGC Community Standard. Those are documented in this branch of the spec for interested folks: https://github.com/AnalyticalGraphicsInc/3d-tiles/blob/3d-tiles-next/Styling/README.md