Hard-coded EntityView time delta constant can run into precision errors.
- Dominant language
- JavaScript
- Stars
- 15.7k
- Forks
- 3.9k
- Avg merge
- 4d 6h
- Merged PRs (30d)
- 34
Description
`EntityView` includes a [hard-coded constant](https://github.com/CesiumGS/cesium/blob/master/Source/DataSources/EntityView.js#L48), 0.001s, for approximating the velocity of the tracked entity. In some use cases, this small time delta runs into precision issues which can manifest in two ways:
1. If the underlying position calculation isn't capable of determining a different position at a resolution of 0.001s, then a zero velocity will be calculated and the ENU reference frame will be used. This is very jarring when it rapidly flips between ENU and VVLH.
1. If the underlying position calculation is at the limit of its precision, then the approximated velocity can be subject to precision errors and the VVLH reference frame will be jumpy/flickery.
To be clear, this isn't necessarily a failing of Cesium, but of the position model of the underlying entity. That said, it'd be better if it could work smoothly with less precise position data.
Contributor guide
Research direction
Start in Source/DataSources/EntityView.js at the hard-coded 0.001s delta and trace how it is used to approximate velocity and choose between ENU and VVLH. Reproduce the zero-velocity and jumpy-reference-frame cases described in the issue; done should mean less precise position data no longer causes rapid flipping or flickering.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- computer-graphics
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100