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

Extend tileset creation function to assign multiple positions #130

Open
javagl opened this issue May 15, 2024 · 0 comments
Open

Extend tileset creation function to assign multiple positions #130

javagl opened this issue May 15, 2024 · 0 comments

Comments

@javagl
Copy link
Contributor

javagl commented May 15, 2024

(This is a spin-off from #111 )

The createTilesetJson command has recently been extended to allow placing the resulting tileset at a certain position, by passing in the cartographicPositionDegrees that the tileset should have.

One common use-case could be to have a set of input files (GLB, B3DM...), and the goal could be to assign different positions to each of them.

This could be "emulated", to some extent, by calling createTilesetJson with the proper cartographicPositionDegrees for each of them, and then use merge/combine to create a single tileset from the results. But this is not very convenient and does not scale well.

The question of how this functionality could be offered is still open. But on the level of brainstorming, I could imagine that there is some overlap of this functionality and #84 . For example, there could be some very simple input file format like

[
    { content: "contentA.glb", cartographicPositionDegrees: [ 111, 21, 31 ] }
    { content: "contentB.glb", cartographicPositionDegrees: [ 112, 21,  32] }
    { content: "contentA.glb", cartographicPositionDegrees: [ 113, 23,  33] }
    ...
]

from which a tileset could be created where each content has the given position. And one could use a similar file format for defining multiple instances. For example, when the content is the same, as in

[
    { content: "contentA.glb", cartographicPositionDegrees: [ 111, 21, 31 ] }
    { content: "contentA.glb", cartographicPositionDegrees: [ 112, 22,  32] }
    { content: "contentA.glb", cartographicPositionDegrees: [ 113, 23,  33] }
    ...
]

then it could automatically create instanced models. Alternatively, there could be something like

[
    { content: "contentA.glb", cartographicPositionDegrees: [ 111, 21, 31 ],
      instances: {
            translations: [
                [1,2,3],
                [2,3,4],
            },
            rotations: [
                [0,0,0,1],
                [0,1,0,0],
            },
            scales: [
                [1,1,1],
                [2,2,2],
            }
        }
    }
    ...
]

where the instancing information is passed in more explicitly.

Again, this is brainstorming - there are many details to be sorted out. But my gut feeling is that it could be relatively easy to offer some really useful functions here.

Right now, it is not even clear whether this should be based on an input file, or a functionality that is offered at the API level. The pseudocode from the linked issue that said

magic.addContent("exampleA.glb", 35, 140, 10);
magic.addContent("exampleB.glb", 37, 135, 30);
magic.addContent("exampleC.glb", 36, 142, 01);
...
tileset = magic.buildThat();

could be more flexible, and probably acceptable for users who want and need more options and configurability here.

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

No branches or pull requests

1 participant