Generating tilesets dynamically about 3d-tiles HOT 24 CLOSED

Currently the criteria is based on the file extension only, but this will most likely change. If you just want to get something working in the meantime in Cesium, this would be the place to edit https://github.com/AnalyticalGraphicsInc/cesium/blob/3d-tiles/Source/Scene/Cesium3DTileset.js#L105.

from 3d-tiles.

CC #89

It would then build tileset.json on the fly from that data. This would allow for tileset.json subsets to be generated from larger datasets and possibly other types of dynamic data generation (like merging to tilesets on the fly?)

from 3d-tiles.

I would like to see one of two things, both of which are premised on lazy generation (the real win for generating tilesets dynamically should be not having to store the whole structure in memory at once...):

• Allow the spec of a child node to be given by a URL instead of inline data. This would essentially allow a filesystem-like approach to be taken, but would require cooperation from the server.
• The ability to specify a generator function to be invoked as a callback when the next child is needed. This could trivially subsume the functionality of the previous suggestion, but would require more careful planning around API design.

[edit]
I think my first suggestion is more-or-less external tilesets, but the intended use case appears to vary somewhat from the description there, which threw me off a bit.

from 3d-tiles.

Thanks for the input, @elfprince13!

[edit]
I think my first suggestion is more-or-less external tilesets...

Agreed.

The ability to specify a generator function to be invoked as a callback when the next child is needed. This could trivially subsume the functionality of the previous suggestion, but would require more careful planning around API design.

Can you provide a concrete use case? Is this purely a client-side implementation? Or does this impact the spec?

from 3d-tiles.

I think it would best be done as part of the spec. Rather than specifying:

"root": {
    /* Various other properties here */
    "children": [..]
}

You would specify something akin to this:

"root": {
    /* Various other properties here */
    "lazy-children": {
        "callback" : "name-of-function-to-call",
        "context" : /* Any value may appear here. It's purpose is only to be passed opaquely  to the callback */,
         "numchildren" : 8 /* Maybe this is an oct tree */
    }
}

To access a specific child, the callback could then be invoked by the implementation using something akin to this, and passed both the context value and the index of the desired child (and the resulting object could be memoized for efficiency). The meta-goal is simulating lazy evaluation with closures (the pattern here is essentially a generalization of this tutorial to acyclic datastructures with more than one child per node). A trivial concrete use case would be generating an oct-tree as needed without having to load the entire structure into memory.

from 3d-tiles.

Thanks for the extra info.

A trivial concrete use case would be generating an oct-tree as needed without having to load the entire structure into memory.

Have you seen:

• Tilesets of tilests: https://github.com/AnalyticalGraphicsInc/3d-tiles#external-tilesets
• Explicit tiling schemes, #92 (just an idea, no spec or implementation yet)

Also, are you sure there are not security concerns with something like this:

"callback" : "name-of-function-to-call",

from 3d-tiles.

Have you seen:

• Tilesets of tilesets: https://github.com/AnalyticalGraphicsInc/3d-tiles#external-tilesets

You could absolutely leverage external tilesets to achieve the same results, with a few caveats:

1. The overhead of loading resources over the network is almost certainly going to be higher than calling a function which already exists in client memory.
2. The spec should really formalize some requirements about lazy loading w.r.t. external tilesets.
3. This will require the developer to be able to execute server-side programs and not just be able to load static content.

• Explicit tiling schemes, #92 (just an idea, no spec or implementation yet

This would absolutely mesh well with explicit tiling schemes (and even provide a potential implementation).

Also, are you sure there are not security concerns with something like this:

"callback" : "name-of-function-to-call",

I would say that there are security concerns, but they aren't intractable. As a baseline, you certainly should not implement this via eval or downloading scripts from untrusted 3rd parties. I would recommend allowing the developer to provide a function which handles the name resolution. That way, if they're only loading trusted tilesets, they could use the relatively straightforward implementation I linked to on SO, but if they're loading something from an untrusted source, they could instead utilize a sandboxed environment that provides only a limited selection of functions (this would also mesh well with the discussion of #92, in that you could provide a selection of stock functions with known tiling schemes).

from 3d-tiles.

Thanks for the details, I may follow up with more questions when we start to evaluate this. Please feel free to chime in on any of the other spec issues in this repo. Your feedback is appreciated.

from 3d-tiles.

@KermMartian and I are approaching a point in our project where we need to make some determinations about this. One thing we've contemplated as an interim solution, while the spec is still being discussed, is the possibility of a server-side script that generates each tileset json as needed. However we're concerned about this language in the documentation for external tilesets:

The file extension of content.url defines the tile format. The url can be another tileset.json file to create a tileset of tilesets. See External tilesets

What are the exact criteria applied to determine the tile format? If we have a url of the form file.php?child=0/0/0&ext=.json, would that be recognized as a tileset.json?

Either way, the server-side approach is sub-optimal in the long run, but generating a tileset.json on disk for every directory in our tree would be even more sub-optimal.

from 3d-tiles.

I'm curious if anyone has insight into the answer to @elfprince13's question in the previous comment, so that we can test a server-side script hack in the interim. Thanks in advance.

from 3d-tiles.

Thanks for the answer! I think you actually answered a slightly different question, but that was a helpful place to start. https://github.com/AnalyticalGraphicsInc/cesium/blob/3d-tiles/Source/Scene/Cesium3DTile.js#L199`appears to be where the behavior of content.url is resolved, but it appears that you use the same function there to check the file extension.

from 3d-tiles.

Also see:

• Remove tile extension restriction, #213
• Implementation, CesiumGS/cesium#5206

from 3d-tiles.

This is awesome for generating tile-sets dynamically on the server, but it would be awesome to take it a step further and support client-side generation, using, e.g. something like my suggestion above.

from 3d-tiles.

Hello,
I am keenly interested in reading the cesium source code that handles the children attributes for a a tileset. Could anyone guide me there?

Thanks

from 3d-tiles.

(Note that @aymohamed is working with @KermMartian and myself on a prototype implementation for dynamically generating tile sets)

from 3d-tiles.

@aymohamed by children attributes, I think you mean the batch table with per-feature attributes, check out: https://github.com/AnalyticalGraphicsInc/cesium/blob/master/Source/Scene/BatchTable.js

Keep us posted on your progress!

@elfprince13 btw, will you be at SIGGRAPH?

from 3d-tiles.

Thanks @pjcozzi . I will take a look!

from 3d-tiles.

@pjcozzi , I am not sure if this is what I was looking for. A quick scanning through the code lines did not lead me to see the portion that deals with tilesets, children attributes and how they are loaded. I am quite new to this terrain, and I would appreciate seeing the lines of codes which do that. Also, doing ctrl+f of "tileset" doesn't return any results.

from 3d-tiles.

I'm still not sure what you mean by "children attributes." If you are looking for how HLOD tree traversal works, start with Cesium3DTileset.js and Cesium3DTilesetTraversal.js. You can also look in the history of the first file for a more simple traversal algorithm.

For more discussion on the Cesium code, please use the Cesium forum so we can keep this GitHub repo a clean archive of 3D Tiles spec discussion.

from 3d-tiles.

Perhaps @elfprince13 may have better wording.

from 3d-tiles.

@pjcozzi ,

I mean for a given 3d tile, with an array of children, where is the code that determines if a child is from an "external tileset"and handles the request for that URL.

from 3d-tiles.

Gotcha, please check the two files I linked above. Cesium's traversal is pretty complex so you might want to step through with the debugger. Again, please post future Cesium code questions on the forum I linked to above; I am not going to crowd this issue any further. Thanks!

from 3d-tiles.

Thanks @pjcozzi ! The 2nd link seems to have my answer. Thank you.

from 3d-tiles.

There aren't any immediate plans to support client side tile generation, though as mentioned above this could be handled server-side with external tilesets.

from 3d-tiles.