Initial orientation of S2 globe is too sensitive to changes in the boundingVolume value?
- Dominant language
- JavaScript
- Stars
- 15.7k
- Forks
- 3.9k
- Avg merge
- 4d 6h
- Merged PRs (30d)
- 34
Description
Recently we had a problem that two versions of our internal S2 globe was displayed with different initial orientation by Cesium. After investigating we realized that the boundingVolume of the two version had a small decimal difference (7th decimal of PI).
Cesium seems to be sensitive to the exact value of the boundingVolume when opening our internal globe and selecting what S2 face to display as initial orientation.
Cesium is zooming to different S2 faces when opening our internal globe depending on the root boundingVolume value defined in the tileset.json file .
If the root boundingVolume is as follows then Africa (face 0) shown:
"root": {
"boundingVolume": {
"region": [
-3.141592653589793,
-1.5707963267948966,
3.141592653589793,
1.5707963267948966,
-10881.995181892067,
8805.044281111099
]
},
here -3.141592653589793 is identical to the definition of PI.
If the root boundingVolume is as follows then Antarctica (face 5) is shown:
"boundingVolume": {
"region": [
-3.141592618820418,
-1.5707962986969973,
3.14159264862274,
1.5707962837028416,
-10881.995181892067,
8805.044281111099
]
},
The difference of the bounding volume is:
>>> -3.14159265358979 - -3.141592618820418
-3.47693718261155e-08
Is this as expected? Is it required that the boundingVolume must be identical to PI to orient the globe to display Africa (face 0) as its initial orientation?
We were suprised that our small difference in boundingVolume resulted in the dispaly of different initial S2 faces (Africa/Antarctica).
Contributor guide
Research direction
Reproduce the behavior using the two root boundingVolume regions shown in tileset.json and compare which initial S2 face Cesium displays. Then trace the globe initialization and camera-orientation path to determine whether the sensitivity is intentional; completion would require a documented expected behavior and a focused regression test or implementation change.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- computer-graphics
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100