OverlayDecorator::cullTerrainAndCalculateRTTParams() can send zfar < znear to clampProjectionMatrixImplementation() due to the maxFar calculation in the following code
// Clamp the projection matrix to the newly calculated clip planes. This prevents
// any "leakage" from outside the subraph.
double zNear = cv->getCalculatedNearPlane();
double zFar = cv->getCalculatedFarPlane();
cv->clampProjectionMatrix( projMatrix, zNear, zFar );
OE_TEST << LC << "Subgraph clamp: zNear = " << zNear << ", zFar = " << zFar << std::endl;
// restore the clip planes in the cull visitor, now that we have our subgraph
// projection matrix.
cv->setCalculatedNearPlane( osg::minimum(zSavedNear, zNear) );
cv->setCalculatedFarPlane( osg::maximum(zSavedFar, zFar) );
// clamp the far plane (for RTT purposes) to the horizon distance.
double maxFar = std::min( horizonDistance, _maxHorizonDistance ); <-------- maxFar < zNear < zFar
cv->clampProjectionMatrix( projMatrix, zNear, maxFar );
This has only been noticed when viewing from underground (using TrackballManipulator) when the Map is zoomed out (in this case the map takes up about 10% of the screen). Note that being zoomed out is probably more of a trigger because the znear is increasing.
Debugging the above code shows that zfar is being calculated correctly to be > znear, but maxFar can be less than znear.
There are 2 issues here:
1) maxFar can end up being < znear - Bug.
2) This code gets executed even if there are no image or feature overlays - not a bug, but might be inefficient.
OverlayDecorator::cullTerrainAndCalculateRTTParams() can send zfar < znear to clampProjectionMatrixImplementation() due to the maxFar calculation in the following code
This has only been noticed when viewing from underground (using TrackballManipulator) when the Map is zoomed out (in this case the map takes up about 10% of the screen). Note that being zoomed out is probably more of a trigger because the znear is increasing. Debugging the above code shows that zfar is being calculated correctly to be > znear, but maxFar can be less than znear.
There are 2 issues here: 1) maxFar can end up being < znear - Bug. 2) This code gets executed even if there are no image or feature overlays - not a bug, but might be inefficient.
Tested using osgEarth 2.5, projected map.
Thanks,
Roland