Working on a time range feature for dynamic visualizers

CesiumJS
1

Hey guys, I am currently researching what it would take to create range sliders on the cesium timeline widget to visualize historical and future positions for dynamic objects. Google earth has this capability. See below.

I want to duplicate the object at all of its positions within the time range slider and set the visibility based on its time unit distance away from the main slider (the duplicates of the object will be more transparent the farther in time they are away from the main time slider’s position). From looking in the code, this does not seem like it will be very difficult at all. I think I can basically pass in past and future time range intervals along with the main slider time to the dynamic object’s updateObject. Then, from here, I can duplicate the object at each position along the range per timeline time unit and set the transparency accordingly.

I plan on getting it to work with points, and then it seems like the changes to the other dynamic objects should be similar.

I was just wondering if I am missing something, and if there is a better way to do it, or if someone is already working on a similar feature.

On a side note, I noticed that there is a class called CompositeDynamicObjectCollection which seems to make it possible to have multiple dynamicobjectcollections to support viewing multiple czml documents at a time. I do not see any examples of using it though. I would like to modify the Cesium Viewer to use this instead, so that we can import multiple czml files.

2

Jonah,

Viewing historical (and future) information is something that’s been on our to-do list since the beginning. We actually had a prototype at one point, but that code was incomplete and has not been ported to the new Viewer yet. It was also a hack, so we’re better off starting from scratch.

If I’m understanding you correctly, there are three seperate features you would like to see implemented.

  • Path Visualization - For dynamicObject.position, create a historical (and future) path showing where the object has been and where it is going.
  • Waypoint Visualization - For other visualizer types, such as billboard, show the past (and future) billboards which represent where we had actual (non-interpolated) data for.
  • Timeline Interval - Extend the Timeline widget to manipulate an interval which will constrain all visualization to that time so that past and future data does not extend past that interval.

I think all three of these are great ideas and definitely on the roadmap. To keep things clean, they should each be implemented independently and merged into master one at a time. I’ll go into more detail below about how I see each feature being implemented. I’ll put all of this up on the wiki as well.

Path Visualization

Create a new visualizer, PathVisualizer, rather than modify the existing visualizer. This visualization will use the dynamicObject.position property to draw the path the position makes over time. We will need a new CZML property, “path” for defining the graphical properties of the Polyline it creates, which will most likely mirror our current polyline options, plus have three new properties to determine how much of the path is visualized.

  1. leadTime (number) - How many seconds ahead of the current time to show the path for.
  2. trailTime (number) - How many seconds behind the current time to show the path for.
  3. intervals (ISO8601 interval array) - One or more intervals where the the path is shown for the duration of that interval as long as the current time is in or on the interval.

Waypoint Visualization

Like PathVisualizer, we are probably better off creating a new visualizer for each type which shows historical information, rather than modiy existing types. For example billboards could have WaypointBillboardVisualizer or something similar. I could be convinced otherwise, but I think the first step would be to implement it separately and only merge them together if it can be done cleanly and without affecting performance. It’s important to keep in mind that when visualizing waypoints, we want to visualize how that looked at that time, and not how they look now. I think adding transparency to hem is a good idea as well. We’ll most likely want a way to define how this works in CZML as well (similar to the above Paths), but I need to think about it some more.

Timeline interval

This is probably the easiest to implement and just involves allowing the tick on the Timeline to be split into two so that the desired start/end times can be manipulated. Rather than modify the actual start/end times on the clock itself, this will just create a new constraint managed by the timeline. It should also be easy to go back to the full data interval. Additionally, we would want to add a constrainedInterval property to all of the Visualizers (and VisualizerCollection) which lets the visualizer know the constrained time for which it should provide visualization. This will allow the historical visualizers to know not draw data outside of the desired times.

Obviously, these are just ideas at this point. I’ve been really busy on Core cleanup, so thanks for the catalyst to get me to write this stuff down. If anything I’ve said sounds different than what you actually intended, just let me know and we can figure out a design that fits everyone’s requirements.

Thanks,

Matt

3

Thanks for the detailed response, Matt. I agree that it makes sense to create new historical visualizers rather than modifying the existing ones. We are on the same page with the other details as well. I am on a short time constraint to get this working on some basic level by the next two weeks, so the work that I do may just have to be a prototype for you guys to either build on or reference to later. I will keep in mind all the things that you mentioned and try to keep the implementation inline with this plan. Thanks again for your guidance on this.

Jonah

4

Here is a demo of what I have done so far. Now there are range sliders on each side of the main timeline scrub that you can manipulate. I have the simple.czml satellite example already pre-loaded. For extra fun, drop in the LotsOfSensors.czml file from the viewer gallery.

http://cesiumhistoricalviewer.appspot.com/cesium/Apps/CesiumViewer/index.html

Here is my fork of cesium:

http://github.com/jktaylor/cesium

I had to put this demo on Google’s app engine because github’s pages weren’t being created correctly for the cesium viewer because it breaks on dojo’s files that start with underscore. I ended up switching dojo to the community version hosted at Google “//ajax.googleapis.com/ajax/libs/dojo/1.7.2/dojo/dojo.js”.

On a side note, I ran into a problem where playback was pausing for half a second while the javascript engine ran garbage collection. I was easily able to fix it following a suggestion from this blog post.

http://www.scirra.com/blog/76/how-to-write-low-garbage-real-time-javascript

I was curious if you guys knew about some of these techniques or thought about doing things like this for cesium?

5

Very nice. I haven’t looked at the code yet but I’ll be sure to check it out as soon as I have some time (unfortunately an unrelated work project has be bogged down right now).

Here are the first few things that popped into my head.

  1. I particular like the implementation of the timeline slider. Seems like a natural way to configure the setting and the translucency is a nice touch.

  2. Are those waypoints the actual data points stored in the DynamicPositionProperty, or are they just temporally spaced points? I want to eventually expose the internally stored positions on DynamicPositionProperty and was curious if that’s what you were doing here.

  3. I noticed that the “current” position of the primitive doesn’t line up along the line. The trick we used in other projects we’ve done is to always sample the position of the object at the current time, this way the line always runs through the current position. It’s a simple cheat, but effective.

  4. We have a pull request coming in very soon that refactors Polylines that greatly improves their performance. I think you’ll see performance improve a lot once that happens.

  5. I’m quite aware of the garbage collection issues and I’ve been spearheading an effort to clean up the entire code-base to relieve memory pressure. If you look at the implementation of getValue() in the Dynamic properties for instance, you’ll see they all take an optional “result” parameter that allows for object re-use. We’ve also already refactored Cartesians and Matrices to do the same. It’s a work in progress but we’re bringing changes in as they are finished. By the end of August I expect any and all garbage collection issues to be eliminated completely.

Awesome work and a cool demo. Thanks for sharing.

Matt

6

Hey Matt,

Those are the actual waypoints stored in the dynamicpositionproperty and not temporally spaced. I created a function in
dynamicpositionproperty that returns all positions within a time range. The key to my garbage collection problem was to pass in a return value object and keep that object around as a class member as you guys have done with the getValue that you mention. It was not obvious to me when I first saw that, that it was done to relieve memory pressure issues.

I will fix the paths so they go through the objects.

Great news on the polylines! I was bummed when I changed the visualizer to make each polyline segment have it’s own transparency based on its position in time away from the main scrub, and I saw the performance was not as good. I think the transparency and waypoint scale changes are pretty visually effective. Thanks for taking a look at it.

7

Cool stuff Jonah. I like that Timeline slider as well, and the use of transparency for the tracks.

Matt, I’m curious about #3 you mentioned above.

“3. I noticed that the “current” position of the primitive doesn’t line up along the line. The trick we used in other projects we’ve done is to always sample the position of the object at the current time, this way the line always runs through the current position. It’s a simple cheat, but effective.”

I believe I’m doing something similar in order to get my polylines to track a satellite over its Cesium-interpolated positions. I override the vertex properties of the polyline at each time to match the source and target satellites’ positions. It’s definitely a hack the way I did it, I’m curious if there’s a more elegant way to do it besides modifying DynamicPolylineVisualizer directly and hunting to find the satellite associated with each polyline.

Eric

8

I know this thread is super old, but we really need a timeline slider like the Google Earth one in Cesium as well. Was any of this actually implemented and put into Cesium over the past 4 years? I haven't seen any samples that would suggest that it has. Also, Jonah's example isn't working on AppEngine any more, so I'm not really able to see what he did there and the code is missing from github as well. Please let me know if this went anywhere.

Thanks
Andrew

9

Hello,

Yes, Cesium does have a timeline widget that is included by default in the Viewer. You can see a demo here: http://cesiumjs.org/Cesium/Apps/Sandcastle/index.html?src=Hello%20World.html&label=Showcases

Best,

Hannah

10

I know Cesium has a timeline, but the current timeline only supports a single instance in time. Not a range of time like the one in Google Earth. Please see the original post of this thread for what was being asked about (a time range feature). Matthew Amato made it sound like Cesium was working on this feature at one point. So I’m hoping there is support for a range / time window slider in the timeline.

Andrew

11

Hi Andrew, Sorry for misreading your question.
No, the timeline does not have this feature for using two sliders to create a range. However, you can clamp the entire timeline to a range so the slider won’t go outside of that range. I believe you can use the ClockViewModel.clockRange property.

-Hannah