SUBTREELoader, ImplicitTilingPlugin: Add support for subtree json files - #1731
Om-singhaI wants to merge 3 commits into
Conversation
|
Thanks for the contribution. How have you tested this? Do you have a demo data set to try? |
The core already routes a subtree json to parseTile, so it's mostly wiring. I used the tile's implicit tiling data to tell a subtree json from other json. The tests build one subtree both ways and check they expand to the same tiles.
c28fc74 to
e8d7207
Compare
|
The tests in the PR build the same subtree twice, once as a binary Those were all made up though, so on your second question I went and used I haven't tried the two ion assets you mentioned, since I don't have a key. Happy to add an example page if you'd rather see it render. |
# Conflicts: # CHANGELOG.md
# Conflicts: # CHANGELOG.md
Getting a key or test assets is the bare minimum effort I'd expect here, and understanding and testing the code you submit is a basic prerequisite for a PR - on this project or any other. Unit tests that only compare the code against itself aren't a substitute for loading a real dataset and confirming it renders. If the code isn't being validated or understood before it's submitted then nothing is really being offered. I can ask for unverified generated code myself. I have to ask again that some effort be made to understand why this is being added and to make sure it's actually serving the intent of the fix. Other projects have started banning users for low-effort AI PRs, and I'd really rather not go there, but as I've mentioned the burden of contributions like this isn't worth my time when I have to confirm whether even the most basic expectations have been met. If you're genuinely interested in contributing to the project consistently please make sure you understand what the code is doing and how it's used in context. To move this forward: please load a json-subtree dataset (the ion assets or the Cesium sample) in an example, confirm it renders, and post a screenshot. |
|
Loaded Cesium's ImplicitTilesetWithJsonSubtree sample in example/three/index.html with the tileset url in the hash. On master, nothing loads past the rootOn this branch: Screen.Recording.2026-09-19.at.7.39.02.PM.movThe root's implicitTiling.subtrees.uri is subtrees/{level}.{x}.{y}.json, so the first subtree comes back as parsed json rather than an ArrayBuffer. Master only hands content to SUBTREELoader when the extension is subtree, so that file is fetched and then nothing claims it, and no tiles are created. With the change the loader takes the parsed object, the subtree's tileAvailability of constant 1 over its two levels expands to the root plus four children, and each pulls content/{level}/{x}/{y}.b3dm. Refine is ADD, so all five draw together, which is the Visible: 5 in the header. I should have rendered real data before replying, my bad. |
This branch has not been deployed
2 participants
Adds support for subtree files in the json format. It's the subtree json item from the list in #608.
Most of it is wiring. A subtree json has no
rootproperty, so the core already falls past the external tileset branch and hands it toparseTile.SUBTREELoader.parsenow takes either an ArrayBuffer or an already parsed object, and the plugin sends json through to it.I used
tile.implicitTilingDatato tell a subtree json from other json reaching the plugin. It's the only thing on the tile at that point that says it belongs to an implicit tileset, and it's close to the condition the list asks for in place of the.subtreeextension check. Disposal keys off the same thing, so the children generated under a json subtree still get cleared. It won't catch a tileset serving its content as json as well, since then nothing separates the two. Happy to change it if you'd rather key off something else.There's no test for either file today, so this adds some. They build the same subtree twice, once as a binary buffer and once as a plain object, then check both expand to the same tiles, covering constant availability with no buffers and bitstreams in an external buffer or in the binary chunk, with the fetch stubbed.