External Batch Table

[lilleyse]

Suggested on the forum: http://cesiumjs.org/forum.html#!msg/cesium-dev/tCCooBxpZFU/GDnHYsu_AwAJ

Bundling the batch table with the tile is often convenient, but isn't as suitable when batch table properties change while the geometry remains constant. Should 3D Tiles support external batch tables?

An alternate solution is to store an id property in the batch table that can query a web service to retrieve additional metadata, however its not possible to apply declarative styling on this data unless it can be incorporated into the batch table. Being able to update an external batch table would solve this problem.

Hi,
Is there a way to store the feature-wise properties for a b3dm file to another file and use that file when rendering the batch 3d models?

It can be named as 'External' batch table.

The rationale for it is as follows:

The 3d building model is relatively constant. (so does a few of the properties - for example, the height of the building) But some properties of the building is not so constant.

For example, let's say we must color the building according to the specific day's mobile RF quality. One day the building is colored red, while another day it can be colored redish-yellow.

We cannot bundle such data (RF quality) into the b3dm file as an 'internal' batch table with the 3d models since the cost of creating the files and the storage it takes are not justifiable, since there are many such KPIs like RF quality and we must handle many days of the KPI values. Simply we cannot duplicate the 3d model with every KPIs x days.

So, it would be nice to separate the information in the b3dm file into two category. One is constant (like the 3d models) and the other is variable. The variable parts can be created on-the-fly by quering the DBMS (and cached on the server for performance) and downloaded to the web client, and then merged with the constant part - and then be drawn.

[pjcozzi]

Being able to update an external batch table would solve this problem.

This may be the right approach; otherwise, we are basically building some of the app logic into the 3D Tiles format by having these external swappable batch tables that complicate the spec and implementation burden.

This approach would make this an implementation issue and others have also asked to be able to update the Batch Table, e.g., process it once downloaded to decode, etc.

[zeodtr]

How about this - add the following feature to the declarative styling module:

• When drawing a b3dm chunk - thus when referencing a b2dm chunk, a user can set a URL that refer to the external batch table for that b3dm chunk.
• The declarative styling module downloads both the b3dm chunk and the user-specified external batch table chunk, and manages independently in the cache.
• When building a drawing batch, the declarative styling module refers both the b3dm and the external batch table.
• Have a 'redraw' function to allow the user change the external batch tables for the b3dm chunks.

The point is, a user should be able to change the reference URL for the external batch table on runtime. (for example, by selecting an item in a radio button group) So, the reference for the external batch table should not be in the b3dm chunk. It should be specified by an API function of the declarative styling module.

An id property (or any user-defined property) stored in the b3dm chunk can by used by the user to build appropriate URL of the external batch table on runtime.

(By the way, I'm the one who posted the question on the Google Groups which is quoted in lilleyse's issue-opening comment.)

[lucasvw]

Although I see the importance of styling 3d tiles features according to attributes which are not contained in the batch table- for exactly the arguments given by zeodtr- but I totally agree with pjcozzi that complicated external batch table structures will make the spec overly complicated. This is clearly an implementation issue.

I made a small demo in which I basically attached a handler to tileVisible on the cesium3dTileset object. The handler checks if the tileSet is "new", and if not, makes a request to an external webservice which returns some id <-> attributes.

Based on these attributes I color the individual objects in the tileset simply with model.color ( so no declarative styling )

See: https://www.youtube.com/watch?v=H7La7WOR2Cc

As an improvement to this approach, I think it would be great if there would be an API method to overwrite / add / append the batchtable. Currently there is already the Cesium3DTileBatchTable.setProperty method. Using this method declerative styling would be possible outside I figure. However some higher-level (bulk) functionality might be good here.

[zeodtr]

@lucasvw 's demo implementation is great, I think.

But it would be nice if there exist the following 'convenience' features:

• Id <-> attributes data chunk can be cached using Cesium+3DTiles's internal cache logic.
• An efficient format for id <-> attributes data chunk which can be parsed by Cesium+3DTiles, so that the declarative styling functionality can use it.

I think it can be done with 'standalone(=external)' batch table file format, which contains only the batch table - without the 3D model data, point cloud data, etc.

[pjcozzi]

Sounds like everyone is in agreement that this can be handled with new Cesium API features.

@zeodtr it would be fine for an app to store just a Batch Table and transfer it.

We're going to address #66 soon; this would come some point afterward.

[pjcozzi]

Removing 1.0 label since this is for the Cesium implementation. It would come after the complete implementation for the 1.0 spec.

[pjcozzi]

@lilleyse any interaction of this with feature metadata, #430?

[pjcozzi]

interaction

I mean current or potential future that needs to be thought about now so we can do this cleanly later.

[lilleyse]

EXT_mesh_features can store metadata in external buffers.

Also see #519 (comment)