Looking into getting buildings (and possibly other features), I started toying with the OSM2World project again. Now that OBJ2GLTF exists, it's easy to get OSM into Cesium.

For example: https://github.com/stirringhalo/osm2cesium

This takes OSM extracts and dumps them to obj, which is then converted to gltf, and georeferenced in Cesium based on the original obj

I've heard mention of a gltf to b3dm converter, does such a tool exist now or on the horizon? I'm looking to expand osm2cesium to handle larger areas with streaming.

Change all the examples in this repo and Cesium once the spec stabilizes.

CC #50.

Currently, Cesium is storing all of the tile formats gzipped compressed. Should this be part of the core spec, e.g., a .b3dm file is always gzipped compressed?

One concern is if problem-domain specific compression (mesh compression, point cloud compression, etc.) cancels out any benefit of gzip.

Perhaps we want the flexibility that some tile playloads will be gzipped and others will not so we just leave this out of the spec?

is there any location from which we can download the OSM model of New York dataset , or its batched file and tileset file togther ? i wanted to work with 3d tile , and use the OSM model of New York as my data source,however i could not find so far the b3dm file of NY and its tileset file online .

Like MBTiles as discussed with @mramato offline.

CC #9.

Either a default style or set of styles (#2).

Or is this better served by the app and higher-level formats that combine the tileset and style?

From the spec:

Trees of trees. A content.type of "3dtile" is planned and will allow conversion tools to chunk up a tileset into any number of tiles.json files that reference each other.

• Remove type, #5
• Remove batchSize, #4

https://github.com/AnalyticalGraphicsInc/3d-tiles/raw/master/figures/tile.png

See the originial notes for Vector Data.

Considering only polygons and no styling:

Header
------
magic            // uchar[4], "vctr"
version          // uint32,   1
byteLength       // uint32,   length, in bytes, of the entire tile.  See #23
batchTableLength // uint32,   length, in bytes, of the batch table.  Can be zero.

Batch Table
-----------
// Same as Batched 3D Model.  Optional.

Polygons
--------
polygonsLength    // uint32, number of polygons in the tile

There are polygonsLength of these (each is variable length):
* batchId         // uint32, index into batchTable, zero when Header.batchTableLength === 0
* minimumHeight   // float,  for shadow volume extrusion optimization
* maximumHeight   // float,  for shadow volume extrusion optimization
* positionsLength // uint32, number of vertex positions in this polygon
* x, y, z ...     // doubles in WGS84 coordinates
* indicesLength   // uint32, number of triangle indices
* i0, i1, i2, ... // uint16, every three indices form a triangle

This design assumes server-side triangulation and client-side subdivision and shadow volume extrusion. It includes metadata to optimize shadow volume rendering (which makes a huge difference).

Polygons with holes can be represented as multiple polygons (with or without the same batchId) or as one polygon with disconnected triangles.

The geometry is well behaved: there are no degenerate triangles nor are the duplicate vertex positions.

Cesium should render these tiles with RTC instead of GPU RTE.

Easy Questions

• batchId is the first field here, but the last field in i3dm (#23). Which do we prefer?
• Should indices be uint16 or uint32? When using uint16, a big polygon could be represented as several polygons with the same batchId.
• minimumHeight and maximumHeight are for rendering optimization. Most likely, they should be a semantic in the Batch Table instead.
• minimumHeight and maximumHeight just need to be conservative. Is uint16 more appropriate?

Less Easy Questions

• Tight representation for vertex positions, e.g., RTC, EXT_quantized_attributes, delta encoding, Open3DGC SOA vs. AOS, cartographic, etc.
• As we add more geometries, including geometries with optional fields, will a hybrid JSON/binary approach, like Binary glTF, be better?
• As we add more geometries, do we need to introduce multiple Batch Tables - one per geometry type. Or do we break this into many tile formats and use a Composite (#23) tile?
• How bad are cracks and what are we going to do about them?
• Can additive refinement just add new vertices to polygons? Perhaps this is a completely different progressive tile format.

Short-Term

Spec

@ggetz

• Better name than "3D Tiles Style"
• Hackathon to experiment with current version

@pjcozzi

• TODOs in spec
• Finish spec and schema

Cesium Implementation

@ggetz

• Latest schema for color map and color ramp
  • Remove BooleanExpression, NumberExpression, and friends
  • Unit tests: Cesium3DTileStyle (and implicitly for Cesium3DTileStyleEngine)
• Load style from uri, not just JSON string.
• Pass styleEngine last to constructors (and make it optional?)
• Example evaluating a style/expression on pick
• Remove chroma - 18d80354be225a116d0a711bb79b190871a82534 and e7aebcddacdcdcc00bb5120215d7f248a5acb29a (and ColorRampExpression.computeEvenlySpacedIntervals)

@pjcozzi

• Reference doc
• Update CHANGES.md
• Run coverage and see if we are missing any tests for 3D Tiles styles

Later

Spec

• Add JulianDate datatype to support styling with date/time metadata
• Introduce translucency property to assign to without having to set RGB?
  • And/or built-in variables to get the feature's current color and show?
• Operator overloads for regular expressions (we already overload for Color so why not here?), see #2 (comment)
• Allow variable names inside member expressions, eg. ${foo[${memberName}]}
• Non-visual properties, e.g., for infobox display, e.g.

{
    "show" : true,
    "color" : [255, 255, 255],
    "meta" : {
        "description" : "Hello, ${FeatureName}"
    }
}
var str = style.meta.description.evaluate(feature);

• Escape variables in strings.
• In general, is the ability to assign to feature properties in the style (as part of the JSON or maybe expression) useful?
  • Improved "standard library"
• Cesium built-in math functions, e.g., distance
• Check out GLSL
  • Built-ins like GLSL, e.g., czm_time, czm_inShadow, etc.
  • Include GLSL in a style?
  • Cascading multiple styles on one tileset?
  • Add explicit interval to optimize conditional when used for intervals
  • Referencing other features in a style

color : ramp(palette, distance(${thisFeature.location}, ${anotherFeature.location}))

show : (${thisFeature.height} > ${anotherBuilding.height})

• Multiple expressions in conditions, #2 (comment)
• Generate reference doc from JSON schema
• Core styling schema + extensions for buildings, vector data, point clouds, etc.?
• Influence from CZML, i.e., time-dynamic styles
  • Integration with Cesium Property system, e.g., evaluate expressions as Property or vice-versa.
• Other style languages, e.g., more like CSS selectors
• Support vector and matrix properties since this is supported in the batch table binary.
• Bounding volume hierarchy information (CesiumGS/cesium#4654)
  • Tile bounding volumes
  • Level in tree
• Support vector types like vec2, vec3, and vec4
• Allow component-wise math operations similar to GLSL

Cesium Implementation

• Interfaces for Cesium3DTileStyle and friends for users writing their own styles.
• Fix jsep to allow for single backslash characters to be parsed correctly. Workaround is to replace before jsep for now.
• Column numbers for syntax errors
• Use regex and replace function for replaceVariables in Expression.js?
• GPU implementation for tile formats that would really benefit, e.g., point clouds
• Line width (can we make this as simple as a uniform/batch-value and not recreate geometry?)
• Expose AST?
• Expose Conditional properties?
• Apply to GeoJSON?
• Optimizations if needed: constant folding and dead code elimination
• Schema validation - how much do we do at runtime? Tool for offline validation?
• Style features in parallel

Built-in functions

• radians(x) - convert value to radians
• degrees(x) - convert value to degrees
• cos(x)
• sin(x)
• tan(x)
• asin(x)
• acos(x)
• atan(x)
• atan2(y,x) - atan(y,x) in GLSL
• pow(x,y)
• sqrt(x)
• abs(x)
• sign(x)
• floor(x)
• ceil(x)
• round(x)
• min(x,y)
• max(x,y)
• clamp(x,y,z)
• mix(x,y,a)
• length(x)
• distance(x,y)
• dot(x,y)
• cross(x,y)
• normalize(x)
• random - 0.0 to 1.0 (some complexity on the GLSL side)
• exp(x)
• log(x)
• exp2(x)
• log2(x)
• fract
• time
• Consider data-driven implementation to avoid lots of duplication where the only difference is the function name and number of arguments.

Notes on vector data

• Polygons, #24
  • How bad are cracks and what are we going to do about them?
  • Can additive refinement just add new vertices to polygons? Perhaps this is a completely different progressive tile format.
  • Per-feature minimumHeight and maximumHeight?
• Polylines
• Polygons with holes
• Declarative styling
• Point features - billboards, labels, and points
  • Declutter?
• Non clamped-to-ground features
• Concise representation for ground-clamped positions, #124 (comment)

Selection of Cesium geometries:

• Polygon: extrusion and at height
• Polyline: extrusion (wall) and at height
• Rectangle: on terrain, extrusion, and at height
• Ellipse: on terrain, extrusion, and at height
• Others as requested

When bounding volumes for 3D tiles has been finalized, update the tiles.json specification, examples and descriptions.

These are in at least the following places:
3D Tiles: Tiles.json
3D Tiles: External Tilesets
Example tiles.json
Tiles.json schema

The work on bounding volumes is detailed in Issue #10 Different bounding volumes.

What is the best approach for tileset.json when generating tilesets dynamically like in #22 (comment)?

And update the JSON in the spec.

Like glTF.

Lessons learned from CesiumGS/cesium#3237

A tile with content.url pointing to an external tileset (another tile.json):

• Cannot have any children.
• Is semantically the same as the external tileset's root tile so root.geometricError === tile.geometricError and root.box === tile.content.box (or equals tile.box if tile.content.box is undefined).
• Cannot be used to create cycles, for example, by pointing to the same tiles.json containing the tile or by pointing to another tiles.json that then points back to the tiles.json containing the tile.

@e-andersson any other corner cases we should add to the spec?

We use photoscan to put images together and one of the nices things here is that it nativly support export to potree as a zip file.

The potree project has been under its way for some time and has tools for generating trees.

I am thinking that it would make sense to talk with the author about points and look into if it makes sense to reuse as much as possible, due to the tooling support already. Otherwise leaving all of us to solve one more tooling pipeline :)

Looks good btw. Happy to see the path AGI/Cesium is taking.

I'm not having any luck getting Cesium to display my own generated 3d-tiles data set, so I pulled down all the Chappes demo data and tried to get that to display like http://cesiumjs.org/Chappes/ does -- but no joy there either. I'm clearly doing something wrong, but don't have a working example I can try to compare against.

It would be very helpful it you could put into the examples directory a very simple test dataset (the json and the actual tiles, plus the couple lines need to include in the HelloWorld sample app). Doesn't have to be the Chappes data, just a few tiles with few hundred points each.

Thanks much.

For example, update here and elsewhere to be glTF 2.0, not glTF 1.0.

glTF 2.0 updates: KhronosGroup/glTF#605

Also consider if there are any other glTF extensions, like unsigned int indices, that we want to include.

See When using replacement refinement, can multiple children be combined into one request?.

We may design 3D Tiles to support downloading all children in a single request by allowing tiles.json to point to a subset of a file for a tile's content similiar to glTF buffer and bufferView.

• Batched model - several models batched into one with per-model ids for interaction/metadata
  • Use case: buildings
• Instanced model - several instances of one or more models with per-instance interaction/metadata.
  • Contains: pointers to one or more internal or external (to share across tiles) glTF models, and per-instance properties, e.g., position, scale, translation, and problem-domain-specific properties.
  • Use case: trees, fire hydrants, sewer caps, lamps, traffic lights, etc.
• Composite - container with multiple heterogeneous tiles, e.g., batched model for buildings, and instanced model for trees
• Point cloud
• Vector data - including labels, POIs
• OSM - use higher-level OSM constructs to save space and then batch just-in-time client-side
• Terrain - TIN payload like quantized-mesh potentially combined with texture
• Massive models, e.g., classic Boeing 747, Power plant, etc.

First, see the original notes for Instanced 3D Model and Composite tile formats. To help design the Instanced 3D Model tile format, see the Batched 3D Model tile format.

We now have significant work towards instancing in Cesium. See CesiumGS/cesium#3049.

Here's some initial thoughts:

Instanced 3D Model

Header
------
magic            // uchar[4], "i3dm"
version          // uint32,   1
batchTableLength // uint32,   can be zero, length of the batch table in bytes
glTFLength       // uint32,   length of glTF section (after the Batch Table) in bytes
glTFFormat       // uint32,   0 = url, 1 = embedded binary glTF
instancesLength  // uint32,   number of instances, NOT number of bytes, can be zero I guess

Batch Table
-----------
// Same as Batched 3D Model.  Optional.

glTF
----
// UTF-8 string or binary blob depending on Header.glTFFormat
// Length in bytes is Header.glTFLength

Instances
---------
There are Header.instancesLength of these:
* x, y, z    // doubles in WGS84 coordinates
* x, y, z, w // doubles in WGS84 coordinates (quaternion)
* batchId    // uint32, index into batchTable, zero when Header.batchTableLength === 0

• We can significantly optimize the size of each instance field, e.g., positions can be quantized relative to the bounding volume (see EXT_quantized_attributes). Rotation could also be optional (part of the batchTable) and default to Y up (glTF default) in a local frame for the instance's position. Rotation could use fewer fields. RTC. Delta encoding... SOA vs. AOS... Look into point cloud compression... #33
• Should instance.batchId be omitted when header.batchTableLength === 0. This will complicate the client, but save memory; however, the case it saves memory for is probably rare in practice. #33
• Throughout 3D Tiles, should batchTable be renamed? Something like propertyTable, metadataTable, etc. We can also decide this later as we define more tile formats. Consistent terminology is important. Moved to #32
• Throughout 3D Tiles, should the batchTable work more like glTF buffer/bufferView/accessor to avoid arrays of numbers? Moved to #32

Composite

In order to have different models instanced in the same tile (or more generally, combine any number of tiles, even tiles of different formats), we can use a Composite tile format.

Perhaps:

Header
------
magic            // uchar[4], "cmpt"
version          // uint32,   1
tilesLength      // Number of tiles

Tiles
----
// header.tilesLength (potentially heterogeneous) tiles

• To make this easier to parse on the client, each tile's header could include its total length in bytes or the Composite can contain an array of lengths. I think we want to store it in each tile so other binary streams containing tiles can be easily parsed.

• Generate it using wetzel like we did for glTF.
• Needs CesiumGS/wetzel#5

This will be one of the last things we do so we know the schema is stable.

From #23:

• Throughout 3D Tiles, should batchTable be renamed? Something like propertyTable, metadataTable, etc.
• Throughout 3D Tiles, should the batchTable work more like glTF buffer/bufferView/accessor to avoid arrays of numbers?

Cesium now throws an exception when "asset": { "version": 0.0} is missing from tileset.json, so if that's the desired behavior it should be reflected in the schema. Judging from the example tileset.json https://github.com/AnalyticalGraphicsInc/3d-tiles#tilesetjson there may be other updates needed.

We are working on ideas for supporting hierarchies in B3DM.
The background is that we are working with 3D GIS and BIM data (as CityGML or IFC), which are usually more complicated than 3D viz datasets. We want to preserve as much information as possible.
Currently there is a way to group nodes in GLTF. However, we also want to optimzie rendering as much as possible and make use of batches including attribute tables in B3DM.
In our scenarios, we have complex input data with groups, hierarchies and attributes on different levels. For instance,
a building has a unique id and a set of attributes and properties. The parts the building is made of also has a set of attributes, which are usually different. Sometimes we have 3 hierarchy levels and more.
the application we are working on must support selecting and highlighting entities at all available levels and display the attached attributes (as key value pairs).
We want to click on buildings and display building specific attributes and we also want to click on building parts and display component specific (wall, roof, window, door...) attributes without switching
to another data set with different configuration. The behavior of what kind of element is selected is controlled by a toggle button or by other means.

The current design of the batch table is quite simple, it is basically a 2D grid.
Now the question is how we group together batches and attach attributes to these groups.

We found out that the number of columns is flexible and that its not restricted to the number of batches. We can extend the batch table to include additional columns representing abstract features for which we can include attitional attributes.
This is nowhere specified, but it currently happily consumed by Cesium.

@jbo023 has set up a demo application
http://hosting.virtualcitysystems.de/demos/hierarchy/
Use the CityGML Explorer to access attributes and toggle between building selection and part selection using the buttons on the right.

Example B3DM file:
http://hosting.virtualcitysystems.de/demos/hierarchy/examples/data/buildings_semantic/15/35210/6826.b3dm

There is no formal specification of our approach because we see it as workaround taking into account the current limitations of B3DM.
Please let us know in case somebody is working on a similar topic. We are happy to discuss possible solutions.

As to the example file above, you will see batch table with ids, attributes (ignore the strange format for now..) and a row called parentPosition.
The latter is providing the information on how things are grouped together. E.g the first two entries in this row are 1243, which means that these batches are grouped together.
The id of this group can be found in the id array at position 1243. However, there is no batch with this number, its just an abtract group feature.

What do you think of this approach?
Has anybody alternative ideas or suggestions to accomplish this? Our intention is to include this feature in the 3D Tiles specification so that we can base our framework on the master branch. We can try to formally describe our concept in the git repo and create a pull request.

best regards,
Arne

As we add more tile formats, 3D Tiles needs to stay consistent.

Terminology

• Tiles are composed of sections such as header and body. Sections are composed of fields such as magic and version.
• "Feature" - indicates one model in a batch of models (b3dm), one instance in a collection of instances (i3dm), one point in a point cloud (pnts), one polygon in a vector tile (vctr), etc.

Fields

• field names are in camelCase.
• Length - a Length suffix on a field name indicates the number of elements in an array.
• ByteLength - a ByteLength suffix indicates the number of bytes, not to be confused with just Length.

Header

• Each tile format starts with a header that starts with the following fields:

magic            // uchar[4], indicates the tile format
version          // uint32,   1
byteLength       // uint32,   length, in bytes, of the entire tile.

Binary

• All binary data, e.g., tile formats, are in little endian.

This is a work-in-progress. There are more guidelines to come.

CC BY 4.0 is probably fine. See Considerations for licensors and licensees.

However, it could be useful to have the same CLA as Cesium for when the community contributes spec fixes, new tile formats, etc.

• We can significantly optimize the size of each instance field, e.g., positions can be quantized relative to the bounding volume (see EXT_quantized_attributes). Rotation could also be optional (part of the batchTable) and default to Y up (glTF default) in a local frame for the instance's position. Rotation could use fewer fields. RTC. Delta encoding... SOA vs. AOS... Look into point cloud compression...
• Should instance.batchId be omitted when header.batchTableLength === 0. This will complicate the client, but save memory; however, the case it saves memory for is probably rare in practice.
• Semantics for batch table properties such as scale.

We need to determine how 3D Tiles are going to support z-indexing. Obviously vector payloads are the biggest use case, but I'm pretty sure it would need to be handled at a higher level in the stack (instead of the payload level).

The 2 primary use cases I have in mind are:

1. Layer entire 3D Tilesets in a particular order, like traditional imagery layers.
2. Ground features within a given tile get z-indexed in relation to one another, i.e. indicate that a polyline representing a bridge gets drawn on top of a polygon representing a body of water.
3. The same as 2, but drawn at a constant altitude above terrain.

The following changes to the points README would help reduce potential for misunderstanding:

• the magic bytes should be set to pnts
• the version should be set to 1
• are the positions data to be in lat/lon, radians, or..?
• are the positions data to be expressed as XYZXYZXYZ or XXXYYYZZZ?
• are the colors data to be expressed as RGBRGBRGB or RRRGGGBBB?
• as a sanity check, note that the file size should be equal to 16 + numpoints * 15

Hi,

What is the best way of generating a .pnts file? Are there any programs or utilities available?

Thank you.

https://groups.google.com/forum/#!topic/cesium-dev/tCCooBxpZFU

From @kring:

I noticed that the spec says, "the bounding volume for child tiles are completely inside the parent's bounding volume." Why? Isn't it sufficient for the child content to be inside the parent's bounding volume?

The general spatial data structure in tileset.json does not allow for random access, e.g., "give me tile x,y at level z" because the tiling scheme is not fixed; instead the data structure needs to be searched top-down.

If random access is needed, we could allow a tileset to advertise itself as using a particular typing scheme, e.g.,

"tilingScheme" : "quadtree"

Point clouds use contents.boundingSphere for the RTC center point. This is not documented yet in README.md. We could put it in the tile itself, but it belongs here instead if 3D Tiles allow bounding spheres as a potential bounding volume, which I suspect we will.

I am currently experimenting with external tilesets and came across a question with relative URLs.
Assume a tileset a.json with a content.url pointing to another tileset b.json. b.json contains a content.url to a tile.b3dm content file. Further assume that a.json and b.json are not in the same path.

Now, my assumption was that a relative content.url to tile.b3dm must be given relative to b.json because it is referenced from this tileset. However, I was surprised to learn that it has to be relative to a.json. Is this the supposed behavior?

Cheers,
Claus

Cesium's Node.js development server is using application/octet-stream for now.

Related glTF discussion: KhronosGroup/glTF#412

Is there an advantage to knowing this in tiles.json when it is also defined as the length of the batch table in b3dm? Or can we remove contents.batchSize in tiles.json?

This is probably the right thing to do since it is more precise.

Such as on/off distance, average/worse-case geometric error, and meters per pixel. In addition to updates to tiles.json, there may also be tile-format-specific metadata.

See Is Screen-Space Error the only metric used to drive refinement?

Extensions in both tiles.json and the tiles themselves. We'll most likely take the same approach as glTF (for tiles.json) and quantized-mesh (for tiles).

Does tiles.json support both extensions and extras like glTF? Perhaps extra is useful for application-specific per-tile metadata that the app could process with a load event. We need concrete use cases.

Since most 3D Tiles tilesets are generated once and then served as static files, it's good practice to provide an aggressive caching policy in order to avoid unnecessary server hits. This is similar to how we serve Cesium's world terrain, for which we set a cache policy of one year. The problem with this approach is that if I want to update an existing tileset, browsers that already have older versions of the tiles won't request new ones (for a year at least).

This is a common problem in the industry and is solved via query parameters. We can add a property to the root tiles.json file whose value gets appended as a query string to every tile request. tiles.json would then be served with a less aggressive caching policy (1 hour) and the browsers would automatically detect when it changes causing new copies of the previously cached tiles to be fetched as needed.

As an example, in STK Terrain Server's layer.json, there is a version property that indicates the version of the tileset (not the version of the spec). Requests are then made by Cesium with the ?version=<value> query parameter as I described above. We could use a version property in tileset.json as well, since it has semantics that allow developers to tell what version of a dataset a client is using, or we could simply add an id property that require it to be a GUID string so that it's always unique uniquely identify the tileset.

I'm not partial to either approach, as long as the spec enforces one of them. (or optionally determine a complete different way to solve the caching problem).

I want to create one 3-d tiles b3dm edit Tool.
who can give me the b3dm ascII file which content can't be ??? and I can't understand.
My requirements are below:
1 one complete fileb3dm ascII file in which all content can be read. please notice this webstie sample are not suitable;
2 I am ready for developing it in Java. I want to know how to generate one b3dm file from one gltf in detail?

https://github.com/AnalyticalGraphicsInc/3d-tiles/blob/spec/pnts/README.md

Like glTF's copyright property, This could be as simple as:

{
    "asset" : {
        "credit": "a string"
    }
}

However, it would force converters to generate multiple tileset.json files (which could still reference each other to form a tree) to support per-tile credits. So we can move "copyright" to each tile, e.g.,

{
    "root": {
        "credit": "a string"
        // ...
        "children": [{
            "credit": "another string or omit to inherit"
            // ...
        }]
    }
}

The "credit" could inherit from the parent, and its display would be based on the refinement type because refinement impacts which tiles are rendered. This works well for common uses cases:

• Replacement refinement of terrain with global low-resolution data combined with local high-resolution data. When zoomed out, the low-res credit is displayed. When zoomed in close, only the high-res credit is displayed. In between, both are displayed
• Additive refinement of 3D buildings where "low-res" buildings are from one source and high-res buildings are from another. When zoomed out, just the low-res credit is displayed, when zoomed in, both credits are displayed.

Point cloud data is typically more than 3 fields for (x,y,z): LAS classification, salinity and temperature, etc., any of which one might want to represent by mapping it into (r,g,b).

Is there a plan to expand the binary blob in the point tile to include fields beyond (x,y,z) and allow for a colorization function to be plugged in, or is the intent that such colorization be done dynamically on the server side and passed back by the (r,g,b) fields?

Currently refine is optional and defaults to "add" (as opposed to "replace").

Instead, if it is omitted, should it inherit its parent's value recursively up the tree?

Is it redundant with url if each format defines its extension?

"content": {
    "url": "2/0/0.b3dm",
    "type": "b3dm",

To be more complete and rigorous than just the example in README.md.

This will be an update to tiles.json. It could also impact tile formats since each "sub-title" will need some kind of set of (offset, length) pointers into the tile content.

See How can additive refinement be optimized?.