typeof DynamicObject? - and other DynamicScene design questions

CesiumJS
1

Hi,

I'm looking at the DynamicScene implementation, both of the official
Cesium source code and Andre Nune's KML branch, and I'm trying to
understand the design rationale behind some of the implementation
choices I see. I have two specific questions I'd like to dig into in
more detail.

Seeing from the implementation, it seems that the main point behind
DynamicScene is that 'somehow' a range of DynamicObjects are put into a
collection by various DataSources, and then a number of Visualizers
picks these objects up and visualize them. I understand the main point
of the design would be that specific DataSource implementations only
provide the data, while Visualizers only visualize them, no matter where
they came from.

One of my questions regarding visualization is the binding of data to
visualizers. In the current implementation what I see is that
visualizers look a specifically named properties of DynamicObjects, and
if properties with their expected names exist, they assume they can
visualize that object - that this, they assume the type of object from
it having a property of a particular name.

first: do I see this design correct?

second: is this really the best way to do it? say, inferring a type of
object from the fact that it has a property named 'path' seems too lax
for me at first sight, as one doesn't know the type of the 'path'
property based on this information. wouldn't a more strict object-type /
visualizer binding approach be safer? or at least, a documentation of
'reserved' properties that basically act as markers. just to make sure
that you don't inadvertently put a property named 'path' into your
object, as other visualizers will pick it up and choke on them.

regarding the efficiency of the current mechanism, I wonder if it's a
good idea to have all visualizers look at all dynamic objects on every
update() call to determine if they are interested in them? by having a
more explicit binding mechanism, this would not have to be done.

The other question I have is related to the 'level' of objects to be
created. Now I see that these are quite basic, say points, lines, etc.
but sometimes an object of higher level makes sense, which is made up of
a number of primitives: say an extruded KML LineString is made up of a
wall, a polygon, and the points in it might be spheres. moreover, it
makes sense to treat this collection of primitives as a single unit, for
the sake of selecting them with a mouse, hiding or showing them as a
single unit, etc. I wonder how such a functionality is imagined with the
current approach of 'let's collect all the primitives into a single place'

Moreover, in the current design, at what place would rendering / styling
information be stored? say, color of a particular object, transparency,
other visual information. in the dynamic object itself? at some other
place? in some style-collection, and then one can refer to a particular
style?

I'm sorry if the above are obvious, I'm just looking at this component
now and I trying to thoroughly understand it.

Akos

2

Hi Ákos,I think you have a good understanding of how things currently work; though plenty of changes are planned and I’m open to all kinds of ideas to help get us to our overall goal (more on that below). Keep in mind that most of this code was written over a year ago when we were tuning everything to work with time-dynamic data and weren’t fully aware of what the performance characteristics of JavaScript would allow us to do. Now that we are trying to support a variety of data formats (CZML, KML, GeoJSON, TopoJSON, etc…) it’s clear that the current visualization system needs to be refactored; and that’s something we’re actively working on.

Regarding the visualizers updating every entity every frame; you are correct, it is not the best way to do it (assuming the data does not change every frame). I started work in the dynamicScene-es5-properties branch to allow us to better characterize the state of input data. I plan on additionally adding caching information as well as refactoring all of the visualizers to do the minimal amount of work necessary whenever the time changes. We actually already do this for data which is completely static, like GeoJSON and many KML files. The DataSourceDisplay calls getIsTimeVarying on each DataSource when it is added; if it returns false the visualizer is only executed a single time, or whenever the DataSource notifies the display that it’s static data has changed (such as how KML network polling works). So I agree with you and expect to see a lot of work done in this area in the coming weeks.

All of your other comments seem to deal with the way we aggregate data into a DynamicObjects. The goal of DynamicObject is to be the composited result of multiple different types of visualization and information regarding a particular object (the high level object as you put it). This is not all that different than a PlaceMark in KML; except that it is a bit more flexible because multiple geometries (of differing types) can be associated with a single DynamicObject. So in your example, a Placemark with an extruded LinearRing from KML gets turned into a DynamicObject which contains not only the style information needed to represent the ring, but also the description for the pop-up balloon and any other relevant information we would want to carry over from KML. The geometry and appearances functionality that Cozzi, Dan, and Hannah have spent so much time on has not been incorporated into DynamicScene yet, but I full expect it to happen in the near term. At that time you’ll be able to easily represent a KML LinearRing as an extruded and outlined polygon. The highlight/show/pick/treat as a single object functionality you bring up will all work at the DynamicObject level. Scott is currently doing some of this work in the dataSourceBrowser branch. (the main goal of that branch is a new widget which behaves similar to the Google Earth KML tree).

I don’t see how naming conflicts are a problem with DynamicObject. Any properties it has are documented in our reference documentation: http://cesium.agi.com/Cesium/Build/Documentation/DynamicObject.html and the general idea is that it provides a common interface regardless of where the data comes from. If you would like to use a separated interface to store the “original” source object, you can easily add a property to DynamicObject to do this. Can you help me better understand the use case you have and alternative method that you would use for managing the aggregated data? The current system isn’t perfect, and I’m open to other ideas; for example, one drawback of the current system is that you can not associated multiple primitives of the same type (for example polygones) with a single DynamicObject.

I’m sure I left out some details, but hopefully this answers your questions. Please let me know if it didn’t, or if you have additional questions. Any use cases you provide will definitely help influence our overall direction. As soon as things have stabilized a bit, I plan on writing up full architecture overview, documentation, tutorials, and examples to make it easy for people to get up and running as well as provide critical feedback.

3

taking a specific example of a LineString, one needs to have a
polyline geometry, and if the LineString is extruded, a wall
geometry as well + the related styling info. let’s assume that we
also have a DynamicWall object (nonexistent now), specified by the
wall property in a DynamicObject
is your suggestion that for creating a DynamicObject for a
LineString, one would create a DynamicObject with the following
properties:
polyline: DynamicPolyline
wall: DynamicWall
and thus both the polyline visualizer and the wall visualizer would
‘pick it up’, and visualize these two constructs respectively?
taking another specific example of visualizing an airspace (for
aviation), which is a ‘body’, that is made up of two polygons of the
same geometry but different heights, and a vertical wall that
connects these two geometries vertically - thus creating a closed
shape. how would the above approach work? I’d create a
DynamicObject:
polygon: a DynamicPolygon for the upper bounding polygon
wall: a DynamicWall
polygon: a DynamicPolygon for the lower bounding polygon
but wait, I can’t have the second (lower) polygon, as the ‘polygon’
property is already taken by the upper polygon!
in other words, the above modelling construct only allows for each
DynamicObject to have a single instance of any kind of dynamic
construct - a single polygon, a single polyline, etc. how would
having multiple instances of the same kind of property be modelled
with the DynamicObject setup?
another approach I was thinking about is to abuse this framework,
and to create objects which are very specific. say a specific
DynamicKML, that would have a ‘kml’ property, that would contain all
the information read from a KML file (all Placemarks, LineStrings,
etc). and this would be processed by a KmlVisualizer, and would
create all the Geometries as needed. this would result in a
visualizer specific to KML, but it would still fit into the
DataSource / DynamicObject / Visualizer model.
Akos