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

3D Model Entity API at a disadvantage #7831

Open
emackey opened this issue May 11, 2019 · 1 comment
Open

3D Model Entity API at a disadvantage #7831

emackey opened this issue May 11, 2019 · 1 comment

Comments

@emackey
Copy link
Contributor

emackey commented May 11, 2019

Users of 3D Models at the Entity API level are limited in what they can do, because of the one-way transfer of information between that level and the graphics primitive level. This is not a problem for things like points and labels, where any given label doesn't need to tell the API user anything new that the user didn't already tell it.

But in the case of 3D models, after telling the Entity Model graphics which model file to load, there's plenty of new information to be had about this particular model beyond just the timing of its readiness, including:

  • A list of available animations that could be controlled
  • A list of available nodes that are available for nodeTransformations
  • Coming soon, a list of AGI_articulations that could be articulated or pointed

Now take the case of CZML. We know that CZML is one-way down from the server. But it's not unreasonable to ask the server to do its own inspection of the server-side copy of the model, to understand the available animations, node transformations, and articulations, prior to constructing the CZML stream to send down.

The same is not true for users of the Entity Model API. These users shouldn't have to deeply inspect the glTF on the client, since Cesium is already responsible for doing so on the same client. This would double the memory and double the processing time, and increase the required amount of code, for a client to attempt this on the same system where it had already been performed.

So, I think the ModelGraphics API needs a way to expose certain pieces of information (listed above) to API users, even if these pieces will not be used by CZML.

/cc #7378 #4727

@malaretv
Copy link
Contributor

Semi-related:
I'm also running into an issue where the Entity ModelGraphics API to load models is severely limited in what it exposes compared to Model. It is also unclear from the API docs what their relation is.

In my case I load a CZML and after would like to be able to access and manage imageBasedLighting properties on the underlying Models afterwards

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants