You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
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:
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
The text was updated successfully, but these errors were encountered: