bjornblissing / osgoculusviewer

An OsgViewer with support for the Oculus Rift
Other
106 stars 67 forks source link

Culling disabled #63

Closed rooi closed 9 years ago

rooi commented 9 years ago

Hi,

When I use the vierwer in combination with osgEarth, the memory usages get very high. This is especially true when using osgEarth image layers in the earth files.

Do you have any idea what could cause this?

I've tested this with osg 3.2.1 and the latest osgEarth master version. I could send you the code I used to run the osgEarth with your osgoculusviewer if you'd like.

Any hint would be very much appriciated!

Thanks!

Roy

rooi commented 9 years ago

It seems that the following line causes this:

osg::Camera* OculusDevice::createRTTCamera(OculusDevice::Eye eye, osg::Transform::ReferenceFrame referenceFrame, const osg::Vec4& clearColor, osg::GraphicsContext* gc) const { ..... camera->setCullingMode(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR); ..... }

Why do you set DO_NOT_COMPUTE_NEAR_FAR?

Thanks!

Roy

ChrisDenham commented 9 years ago

Interesting. I had to comment out that line too because I was finding that the cull pass didn't seem to work properly with it in. It seemed as though it was taking twice as long as normal to perform the cull and then not actually cull anything, which made the draw take longer too. So i guess what may be happening in your case is that nothing is getting paged out so you end up with the whole of your world in memory. I didn't investigate whether it was an osg bug, or whether it is triggered by something related to this oculus integration, but commenting the line out seemed to have no detrimental effects on my application.

bjornblissing commented 9 years ago

Hi @rooi & @ChrisDenham,

It is usally better to handle the near and far plane calculation yourself. Normally you as the author would know the limits of your dataset and can adjust the near and far planes accordingly.

Also, If you let OSG handle the near far plane calculation it would overwrite the projection matrices returned from the Oculus SDK: https://github.com/bjornblissing/osgoculusviewer/blob/3ef18eb2dea92cfd89f0d0aa57205a2edd2323b5/src/oculusdevice.cpp#L495 https://github.com/bjornblissing/osgoculusviewer/blob/3ef18eb2dea92cfd89f0d0aa57205a2edd2323b5/src/oculusdevice.cpp#L502

You can set your own values for near and far here: https://github.com/bjornblissing/osgoculusviewer/blob/3ef18eb2dea92cfd89f0d0aa57205a2edd2323b5/src/viewerexample.cpp#L45-L46

ChrisDenham commented 9 years ago

Hi @bjornblissing, Thanks for the info. Though, I was already setting appropriate near and far clipping planes for my data as per your suggestion, I found that the culling still didn't work properly. For example when the slave cameras were facing away from all my scene data, the cull pass was not culling things which were clearly fully outside the viewing frustum of any camera. I could see in the osg stats HUD that much higher counts of Drawables listed than if I allowed the automatic compute_near_far to happen. In fact, for some of my scenes, I couldn't get it to run at 75FPS unless I enabled the auto compute_near_far. Anyway, not really sure what what root cause of the problem is, so this just documents my experience. I can't say I noticed a problem with the projection matrices being reset, but I'll check that.

bjornblissing commented 9 years ago

@ChrisDenham Is it only osgEarth based applications that behave like this. Or does viewing standard models benefit from enabling automatic near/far plane calculations?

The reason for my question is to try to find out if there is something special that osgEarth is doing that are complicating things.

ChrisDenham commented 9 years ago

@bjornblissing I've not used osgEarth. My application is a fairly simple room design viewer that does not currently do any model paging. The scenes I'm viewing typically only contain a few hundred items (though some have quite high poly counts). However, generally I can get over 300FPS when using a 'standard' OSG viewer, but with the osgoculusviewer with automatic near/far plane calculation disabled, it couldn't get to 75FPS until I enabled the near/far calculation. Which is odd, because the manual near/far values I chose should have caused it to actually cull more or less the same things. Here's a typical kind of scene I'm dealing with: image

bjornblissing commented 9 years ago

Ok.. Found it. Not an obvious bug.

It should NOT be: camera->setCullingMode(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR);

Instead it should be: camera->setComputeNearFarMode(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR);

The enum osg::ComputeNearFarMode::DO_NOT_COMPUTE_NEAR_FAR is not a culling mode setting at all. It is an enum that handles how near and far planes are calculated. Its enum value corresponds to the value 0, which when feed into the setCullingMode() function will be translated into osg::CullingModeValues::NO_CULLING. This disables culling completely, which results in the framerate drop you are seeing.

This would never have happened with the strongly typed enums available in C++11.

ChrisDenham commented 9 years ago

Yay! Good catch. The odd behavior now makes perfect sense to me. :-)

rooi commented 9 years ago

Ah thanks for the fix!