gwaldron / osgearth

3D Maps for OpenSceneGraph / C++14
https://www.pelicanmapping.com/home-1/opensource
Other
1.51k stars 779 forks source link

znear > zfar from OverlayDecorator #431

Closed rolandhill closed 8 years ago

rolandhill commented 10 years ago

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.

Tested using osgEarth 2.5, projected map.

Thanks,

Roland

gwaldron commented 8 years ago

Old thread removed