Tighten up spec when content.url is another tileset about 3d-tiles HOT 9 CLOSED

None that I can think of at the moment. Perhaps it should be noted somewhere that the geometric error of a tile with tiles.json content should be the same as that of its tiles.json root? Or should it be flexible?

from 3d-tiles.

Semantically, I think we see the external tiles.json root tile as the same as the parent tile so I agree both tiles should have the same geometric error. I made a note above.

from 3d-tiles.

Actually, does this buy us anything in the implementation? We would also want to make the same claim about the box/content.box property. Instead, it might be better to have a <= relationship for the case when a tile has content that is a tiles.json, but also has children. In this case, it is as if the external tiles.json is a peer of the children.

from 3d-tiles.

A <= relationship might make sense for additive refinement, but maybe not for replacement refinement where all children of a tile must be ready in order to replace that tile. So in the case where a tiles.json tile's root is a peer to the tile's children, the tile, root and children would all have the same geometric error, wouldn't they?
Implementation-wise, it just buys us the convenience of not having to calculate/check SSE for both the tiles.json tile and its root tile separately. As you said, if the external tiles.json root tile and the parent tile were semantically the same, I think it would make sense, but the case of children peers (semantically confusing) complicates things.

Shall we treat all root tiles as <= with regards to geometricError and box / content.box or can we prescribe == for tiles using replacement refinement?

from 3d-tiles.

I'm growing a bit skeptical of allowing children to a tiles.json tile. It makes the implementation more complex/confusing, and doesn't enable any structure that wouldn't be possible without it (right?).

If we want to support it, there will be some unintuitive relations between the tiles involved that are probably not warrented by any use-cases (the use-cases I thought about earlier, would be just as well supported by a no-children specification, I've realized).

from 3d-tiles.

I'm growing a bit skeptical of allowing children to a tiles.json tile. It makes the implementation more complex/confusing, and doesn't enable any structure that wouldn't be possible without it (right?).

OK, let's not allow it. I updated the wording at the top of this issue.

We can always relax it in a later version of the spec if there is a real need, but I agree with your point that it doesn't enable any new structures.

from 3d-tiles.

Shall we treat all root tiles as <= with regards to geometricError and box / content.box or can we prescribe == for tiles using replacement refinement?

Given that we are not allowing a tile to point to a tiles.json and have children, let's say that the tile and tiles.json root are semantically the same so their geometricError is the same and root.box must equal tile.content.box (or tile.box if tile.content.box is undefined).

If you agree, I'll update the top comment of this issue. Then I'll close this and update the spec once the implementation in CesiumGS/cesium#3237 is complete in case we run into anything else.

from 3d-tiles.

Sounds good!

from 3d-tiles.

Great, updated above: #42 (comment)

from 3d-tiles.