Vector Tiles: Support 3DTILES_content_gltf_vector and EXT_mesh_polygon#13478
Vector Tiles: Support 3DTILES_content_gltf_vector and EXT_mesh_polygon#13478donmccurdy wants to merge 21 commits into
Conversation
|
Thank you for the pull request, @donmccurdy! ✅ We can confirm we have a CLA on file for you. |
| export class Polygon { | ||
| /** @type {number} */ | ||
| count = 0; | ||
|
|
||
| /** @type {TypedArray} */ | ||
| indicesOffsets = undefined; | ||
|
|
||
| /** @type {TypedArray} */ | ||
| triangleIndices = undefined; | ||
|
|
||
| /** @type {TypedArray} */ | ||
| triangleIndicesOffsets = undefined; | ||
| } |
There was a problem hiding this comment.
This has been a tricky spot in the draft spec — what is the 'base' mode of the primitive indices, and what mode of indices are supplied as extension metadata?
It's fairly clear that tessellation is too costly for anything serving on-the-fly, like a Postgres extension, so I've moved the triangle-related properties to the extension and made them nullable here.
Less clear is whether the base mode should be LINE_LOOP (the obvious semantic mapping for a polygon's exterior/interior loops) or LINE_STRIP (which requires overriding the core spec to redefine as a closed loop, but has better support in modern graphics APIs). I'm inclined to go with LINE_LOOP despite the lack of graphics support, because it's fairly trivial to rewrite the indices, and re-defining core concepts in glTF makes me more nervous.
I still need to update KhronosGroup/glTF#2570 to this effect.
| triangles[j] = resultIndices[triangles[j]]; | ||
| } | ||
| } else { | ||
| throw new Error("Runtime triangulation not yet supported."); |
There was a problem hiding this comment.
It sounds like we probably will want to support runtime tessellation, but I think that will need to be left for a future PR. It's not as simple as using PolylinePipeline#triangulate because we need to reproject the coordinates from 3D into 2D, or use another tessellation library.
| const result = new TypedArray(count * stride); | ||
|
|
||
| for (let i = 0; i < indices.length; i++) { | ||
| // Write each result value, skipping primitive restart indices. | ||
| const index = indices[i]; | ||
| if (index !== restartIndex) { | ||
| for (let j = 0; j < stride; j++) { | ||
| result[i * stride + j] = array[index * stride + j]; |
There was a problem hiding this comment.
Possible out of bounds?
i is the raw loop index over all indices (including restart positions), but result is only allocated with count * stride elements (where count excludes restart indices). When restart indices are present.
For example, with indices = [0, 1, 2, 3, 0xFFFFFFFF, 4, 5, 6, 7]:
count=8, result has 24 floats
i=5 writes to result[15..17], skipping [12..14] (left as zeros)
i=8 writes to result[24..26] → out of bounds, silently dropped
3 participants
Description
Updating CesiumJS support for vector tiles to match the current draft specifications.
3D Tiles extensions
3DTILES_content_gltf_vector3d-tiles#838glTF extensions
Overview
For now I've kept backward compatibility with earlier (internal) drafts, e.g. CESIUM_mesh_vector, but I expect we'll drop that support after the 1.142 release.
Issue number and link
Testing plan
Updated unit tests, sample data, and sandcastle demo. Any existing datasets and sandcastles should remove unaffected and backward-compatible, until support for CESIUM_mesh_vector (which is not part of the current/upcoming Vector Tiles direction) is removed after v1.142.
Author checklist
CONTRIBUTORS.mdCHANGES.mdwith a short summary of my changeAI acknowledgment
If yes, I used the following Tools(s) and/or Service(s):
If yes, I used the following Model(s):