Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Composite tiles #3158

Merged
merged 8 commits into from
Nov 8, 2015
Merged

Composite tiles #3158

merged 8 commits into from
Nov 8, 2015

Conversation

lilleyse
Copy link
Contributor

@lilleyse lilleyse commented Nov 2, 2015

For CesiumGS/3d-tiles#23

Client-side implementation of composite tiles. We should wait on merging this until the server-side code is ready, as this introduces breaking changes to the tile formats.

  • Added byteLength to all tile formats, added batchSize to b3dm tiles.
  • Point clouds now define their bounding sphere from the tile's oriented bounding box.
  • No longer using contentHeader.
  • Moved a lot of the ContentProvider loading code from request to init. Now request only loads the url and passes the data along to init. Composite tiles will call init when creating inner tiles.

@pjcozzi
Copy link
Contributor

pjcozzi commented Nov 3, 2015

@pjcozzi
Copy link
Contributor

pjcozzi commented Nov 3, 2015

added batchSize to b3dm tiles.

Did we remove this from tiles.json? Can we also remove type from tiles.json in this PR?

@@ -33,11 +33,12 @@
var scene = viewer.scene;
var city = scene.primitives.add(new Cesium.Cesium3DTileset({
//url : 'http://localhost:8002/tilesets/Cambridge',
url : 'http://localhost:8002/tilesets/London_Canary_Wharf',
//url : 'http://localhost:8002/tilesets/London_Canary_Wharf',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Avoid submitting these temporary changes to Cities.html in the future.

Points3DTileContentProvider.prototype.init = function(arrayBuffer, byteOffset) {
byteOffset = defaultValue(byteOffset, 0);

var magic = getMagic(arrayBuffer, byteOffset);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you check if all the other tile formats, including the new composite, and verifying the magic number like this?

@pjcozzi
Copy link
Contributor

pjcozzi commented Nov 3, 2015

Moved a lot of the ContentProvider loading code from request to init. Now request only loads the url and passes the data along to init. Composite tiles will call init when creating inner tiles.

This is an OK approach. If we stay with it, rename init to initialize to avoid the abbreviation.

However, can we do better? Can we decouple the request and the promise management (which is the same-ish) from parsing the tile's arraybuffer (which is different per tile type). For example, each tile's constructor would take an arraybuffer and offset, and would only be constructed once the request resolved.

this._url = url;
this._tileset = tileset;
this._tile = tile;
this._contentProviders = [];
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How do users of the Cesium API access this? Can you update Cities.html to support mouse-over color change and so on (and also update it for i3dm, which I think will lead us to think more deeply about how to expose this in a uniform way).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm still not sure about this. I could just add a getter, but then it's tile.content.contents. Not that great. Maybe tile.content could sometimes return an array? It's still odd.

The color changing works automatically though without any modifications.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The color changing works automatically though without any modifications.

Hmm. Maybe we don't need to expose this for now since users are interacting with the inner tiles in the same way they interact with standalone tiles? We could add a TODO and revisit later if needed.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just curious - did you test composites nested in composites? That is test data we should have.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just tested this and it works.

@lilleyse
Copy link
Contributor Author

lilleyse commented Nov 4, 2015

Did we remove this from tiles.json? Can we also remove type from tiles.json in this PR?

Both are removed from tiles.json.

Can we decouple the request and the promise management (which is the same-ish) from parsing the tile's arraybuffer

The one obstacle I see for that is ContentProvider usually needs to load models, and can only send the ready promise when the model is loaded.

@pjcozzi
Copy link
Contributor

pjcozzi commented Nov 4, 2015

Can we decouple the request and the promise management (which is the same-ish) from parsing the tile's arraybuffer

The one obstacle I see for that is ContentProvider usually needs to load models, and can only send the ready promise when the model is loaded.

Ah, and the model resources, e.g., textures, may be separate files so the promise may resolve later.

I'm OK with sticking with your current approach. As we add more tile formats, we'll see if it makes sense to change.

@pjcozzi
Copy link
Contributor

pjcozzi commented Nov 4, 2015

Let me know when this is ready.

Do you plan to support a tile.content.url that points to another tiles.json file in this PR or a new one?

@lilleyse
Copy link
Contributor Author

lilleyse commented Nov 4, 2015

I'll do it in the same PR. I'll have that ready later.

The rest of the changes are ready for review. I also standardized the getMagic code and made some changes to getStringFromTypedArray.

// API async, and would double the number of numbers in some cases.
batchTableResources.batchTable = JSON.parse(batchTableString);
}
// TODO : rename to batchLength?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's rename to batchTableLength.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if the tile has no batch table? The terminology could be confusing.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then it would be zero. This is consistent with 3D Tiles naming: CesiumGS/3d-tiles#26

What do you suggest?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But we still need the batch size even if it doesn't have a batch table. My comment was to rename batchSize to batchLength.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, you are right. Let's go with batchLength and batchTableLength.

@lilleyse lilleyse force-pushed the composite-tiles branch 2 times, most recently from 04febe8 to ae6f11b Compare November 6, 2015 16:26
@pjcozzi
Copy link
Contributor

pjcozzi commented Nov 7, 2015

@lilleyse do you need to make any other updates to this PR before I do a final review?

@lilleyse
Copy link
Contributor Author

lilleyse commented Nov 8, 2015

I made the last couple of renaming changes. This is ready for another look.

t.cesium3DTile.children.push(childTile);

stack.push({
header : childHeader,
cesium3DTile : childTile
});

// Check if the tile's content url is a tiles.json file.
if (defined(childHeader.content)) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting approach. I planned to do this by implementing a 3DTileContentProvider with a Cesium3DTileset primitive, which would be a bit cleaner than this. However, this approach will help with cache management, rendering budget, etc. since it isn't spread across multiple Cesium3DTileset primitives. Let's see how it goes.

@pjcozzi
Copy link
Contributor

pjcozzi commented Nov 8, 2015

Thanks again @lilleyse!

pjcozzi added a commit that referenced this pull request Nov 8, 2015
@pjcozzi pjcozzi merged commit b1b58ee into CesiumGS:3d-tiles Nov 8, 2015
@pjcozzi pjcozzi deleted the composite-tiles branch November 8, 2015 20:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants