Cecium DIS-style dead reckoning

[berg...@gmail.com]

1. A concise explanation of the problem you're experiencing.

I like to visualize several entities that move around. Rather than constantly updating the position of each entity (by sending the position data from a simulator through e.g. a websocket connection), I like to off-load the updating to Cesium using dead reckoning models. I looked at SampledPositionProperty, we may be able to support this, but I have really no clue how to get that working.

Does Cesium support DIS-style dead reckoning? I.e. first order derivative of position change / velocity.

If so, how can this be done? Is there a simple example you can point me to?

2. A minimal code example. If you've found a bug, this helps us reproduce and repair it.

Currently, the position updates are static and transmitted every so many seconds causing overhead.

Code snippet to create entity:

var billboard = {
image: sym.asCanvas(), //Get the canvas for the billboard
pixelOffset: new Cesium.Cartesian2(-sym.markerAnchor.x, -sym.markerAnchor.y), // Symbol offset
eyeOffset: new Cesium.Cartesian3(0.0, 0.0, 0.0), // default
horizontalOrigin: Cesium.HorizontalOrigin.LEFT, // default
verticalOrigin: Cesium.VerticalOrigin.TOP};

var entity = {
id: milsym.id,
billboard: billboard,
};

var position = new Cesium.Cartesian3(milsym.geocentricPosition.x, milsym.geocentricPosition.y, milsym.geocentricPosition.z);

entity.position = new Cesium.ConstantPositionProperty(position);

viewer.entities.add(entity);

3. Context. Why do you need to do this? We might know a better way to accomplish your goal.

N/A

4. The Cesium version you're using, your operating system and browser.

Version 1.53. FF en GC on Windows 10.

[Omar Shehata]

This is a very good question, and I believe the answer is yes. This is something I've been working on recently to try and provide an example for how to use it. This example shows you how to set up the different interpolation options:

https://cesiumjs.org/Cesium/Build/Apps/Sandcastle/?src=Interpolation.html

This PR adds a Sandcastle example that uses these sample properties to move the vehicle's position, in addition to the wheels and orientation:

https://github.com/AnalyticalGraphicsInc/cesium/pull/7361

The example is in this file:

https://github.com/AnalyticalGraphicsInc/cesium/blob/15c98a49a3e10e91b248687eb21906d5100a7244/Apps/Sandcastle/gallery/Time%20Dynamic%20Wheels.html

Here the samples are all added ahead of time, but you should be able to add samples at run time, and the Sampled properties can extrapolate forwards. I hope you find this helpful until we can set up a tutorial on this common use case. 

If you get it working it'd be very helpful to the community to post your example here/or as a Sandcastle link!

[berg...@gmail.com]

I have got an example going, but use Cesium.ConstantPositionProperty. The entity position is updated with either the received position on the websocket, or every so many seconds using a timer. In the latter case the position is dead-reckoned. Maybe not the best approach, but it does work.

A better way is - I assume - using Cesium.CallbackProperty. When the callback is triggered, the position for the requested time should be returned. This position should be dead reckoned from the last received websocket update. I have done this yet. When and how often is the callback called? Do I have control over the call rate?

Once I have this in place I also like to visualize the path that the entity traversed. Although this is another questions, I like to know how to do this as well.

I am happy to post code once I get callback option going, hopefully with track display included. Any help appreciated.

[Omar Shehata]

When and how often is the callback called?  Do I have control over the call rate?

The callback is called every time the property is required. It's best to think of it not as an update function that advances the simulation, but more as a function that evaluates the property for any given time.

So in a given frame, if the Cesium render code gets the Entity's position to figure out whether it's in view of the camera, and your own code uses the Entity's position to compute something, then that function will l be called twice per frame. This way, Cesium can support things like being able to play any simulation in reverse, as well as easily pause and step through. 

So you can see how the callback property in this example computes the position based on the passed in time:

https://cesiumjs.org/Cesium/Build/Apps/Sandcastle/?src=Callback%20Property.html

So in your case, I think if you keep track of all the positions you get from the websocket, and then in the callback, given a time, do your computation there and return the position. Does that work for you? 

[berg...@gmail.com]

The simulation (whose spatial data is sent over the websocket to the browser), only moves forward in time. The simulation can run non-real time (not necessarily scaled real time), but in my current setup I only use wall clock time (1x real time). Spatial data includes 2nd order derivatives, and is only sent when the difference with the local dead-reckoned model is more than 1 meter. So, if the difference with the local model remains small, no spatial data is sent to the browser at the other end for a long time. The browser is assumed to follow the same dead-reckoning model using the last received spatial data to work from. The dead-reckoning only works forward in time.

From the cesium spec it is unclear if the callback only moves time forward, i.e. if every callback is for a time greater than the previous invocation. If so I can do the dead-reckon calculation in the callback function.

Currently I use a ConstantPositionProperty for each entity, which I update at a rate of 10Hz to get relatively smooth movement on the display. When I use the Cesium callback the update rate is determined by Cesium, 2 x fps, right? How does this work out performance-wise for say 1000-1500 entities?

[Omar Shehata]

I think in that case the way you have it might be best. The CallbackProperties are not evaluated a specific number of times per frame, it's evaluated only when needed (like a getter function).  

From the cesium spec it is unclear if the callback only moves time forward, i.e. if every callback is for a time greater than the previous invocation.

 I wouldn't say the callback moves time in any direction. Its role is to return a value at a particular given time. This makes it great for properties that can be computed independently for any point in time (for example, I think this is how the sun's position is computed, given any particular time it can compute its position). However, for properties that require knowledge of past frames/states it might not be a great option (which is why, in the vehicle Sandcastle PR I linked above, to rotate the wheels I did not use a CallbackProperty, because in order to know the rotation of the wheel at any given time, I'd need to sample the velocity of the vehicle at all the moments in time from some start position leading up to this moment, which would be a performance hit doing it every frame for a long period of time).

Hope that makes it a little clearer. 

[berg...@gmail.com]

Thanks so far. I will explore the links and examples you provided for my application.