bjornblissing / osgoculusviewer

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

Support MSAA #55

Closed bjornblissing closed 8 years ago

bjornblissing commented 9 years ago

Currently there is no support for antialiasing. To be able to support antialiasing via MSAA the FBOs must be initialized with osg::Texture2DMultisample instead of osg::Texture2D.

Both the color buffer and the depth buffer must have the same dimensions and number of multi-samples.

bjornblissing commented 9 years ago

@ChrisDenham Please continue the discussion regarding antialiasing in this issue thread.

ChrisDenham commented 9 years ago

I have question about the OculusTextureBuffer construction and its use of ovrHmd_CreateSwapTextureSetGL. I noticed that this function will create two osg::Texture objects, but both will be assigned to m_texture, and thus, subsequent calls to OculusTextureBuffer::texture() only ever return the second texture that was assigned. Bearing in mind I don't really understand FBO stuff very well, this may be what was intended, but I thought I would check it with you?

bjornblissing commented 9 years ago

The OculusTextureBuffer::m_texture member is unique for each instance of OculusTextureBuffer object. And OculusDevice creates two instances of the OculusTextureBuffer. So if you check the pointers that is returned from OculusTextureBuffer::texture() function you will see that they point to different memory locations.

ChrisDenham commented 9 years ago

Yes, I understand that, but each instance of OculusTextureBuffer creates two instances of osg::Texture2D (i.e. one for each of the two textures returned by CreateSwapTextureSetGL) , but OculusTextureBuffer::texture() only returns the second.

bjornblissing commented 9 years ago

Ok. Now I see what you are getting at. Well, that is an unfortunate construct. I have changed it into something a bit clearer in: 87dd181a70a487d141f79399605580d0569420f9

But in principal we are creating two textures per eye. And then we let the Oculus runtime have access to one and osg to one. During swap we change the current render surface by binding to the texture with the index referenced in m_textureSet->CurrentIndex.

To create the glTextures we utilize osg::Texture2D objects which then can be deleted. Except for one that we need to attach the camera to the colorbuffer.

ChrisDenham commented 9 years ago

Does that mean this is probably not related to the problems I am having trying to get the MSAA working? I'm running out of straws to clutch at.

ChrisDenham commented 9 years ago

Another straw to clutch?

"Texture sets cannot be multisampled - this is an unfortunate restriction of the way the OS treats these textures. If you wish to use MSAA eyebuffers, you must create the MSAA eyebuffers yourself as before, then create matching non-MSAA texture sets, and have each frame resolve the MSAA eyebuffer target into the respective texture set. See the OculusRoomTiny (MSAA) sample app for more information."

from: https://developer.oculus.com/documentation/pcsdk/latest/concepts/release-migration/

bjornblissing commented 9 years ago

Well, that example is using DirectX11. So that would require some study to figure out the corresponding GL calls.

ChrisDenham commented 9 years ago

This example looks more useful for OpenGL and Oculus/MSAA: https://github.com/kondrak/oculusvr_samples

bjornblissing commented 9 years ago

Good find.

This seems to be the important file to study (especially the OnRenderMSAAFinish() function): https://github.com/kondrak/oculusvr_samples/blob/master/common_src/renderer/OculusVR.cpp

ChrisDenham commented 9 years ago

Just wondering if anyone is likely to be working on the MSAA enhancement in the near future? I only ask because I was about to try and getting it working myself and didn't want to duplicate efforts.

ChrisDenham commented 9 years ago

I've made some progress with this and it seems to be working well apart from some bad judder in the right eye (or left eye if I change the camera render order). Any ideas what I might be doing wrong? My guess was something to do with indexing of SwapTextexureSet when bliting the MSAA FBO back to the oculus texture, but so far it's got me stumped.

ChrisDenham commented 9 years ago

If anyone fancies casting their eye over changes I made here to support MSAA, they are here, b6d4ccb35e41e5ebdd36040ce9d65f16f82013df

The problem I'm having is that although MSAA seems to be working correctly, I'm getting a "lag" in the right eye as you move your head (as though it was rendering the previous frame) but I can't see what I have done wrong. Note my changes might look a bit deeper than I had hoped for, and they still need tidying up, but I'm just trying to make it work first. Though I think I have made changes so it works exactly as prior to my changes when #define USING_MSAA is comented out.

The key differences with USING_MSAA defined is that it attaches a texture to camera using: camera->attach(osg::Camera::COLOR_BUFFER, texture2D, 0, 0, false, 4, 4); and relies on OSG's implicit FBO attachment to setup the MSAA FBO. The content of which is copied to the oculus swap texture in OculusTextureBuffer::onPostRender

ChrisDenham commented 8 years ago

Ah ha... success today. MSAA now working well. I will submit another pull request with my changes once I've tidied up my code and made the antialiasing a runtime option. :-)

bjornblissing commented 8 years ago

@ChrisDenham Great work! I am looking forward to that PR.

ChrisDenham commented 8 years ago

Pull request here #67