ofEnableDepthTest not working!

[ZeroLu]

I tried to put a model into the scene, and it's really messy as if the depthtest was turned off. Then, I tried to put the model out of the oculus' drawScene function and it works totally fine! Then I fill the sphere in the example using the ofFill. And I found that the default scene also have the same problem, wichch means that the further ball will be rendered before the nearer ball. Although I can see glEnable(GL_DEPTH_TEST) before the drawScene(). So the conclusion is that depthtest won't work in the drawScene().

[sphaero]

I'm seeing similar behaviour. I can't get depth test to work. Tried setting glEnable(GL_DEPTH_TEST); at places but my objects remain transparent. Without the oculus addon they render normal.

I also encountered when using ofDisableArbTex() nothing gets rendered

[mattebb]

Hi, that's a pretty old version of the addon with some errors in it. Until we get things all nicely merged back together you can try the version that's in my branch, that particular problem should be fixed there.

On 27 Feb 2015, at 2:42, Arnaud Loonstra [email protected] wrote:

I'm seeing similar behaviour. I can't get depth test to work. Tried setting glEnable(GL_DEPTH_TEST); at places but my objects remain transparent. Without the oculus addon they render normal.

I also encountered when using ofDisableArbTex() nothing gets rendered

— Reply to this email directly or view it on GitHub.

[sphaero]

I just tried it, but it's even worse :) I don't see anything anymore. Just black. I'm running the example app. If I press 'o' (overlay) a red plane is drawn but completely in the wrong place (upper right corner outside of the frustum of the oculus)

[sphaero]

Same happens for the programmable renderer example although it gave an error in main.cpp. I just commented the line:

error: could not convert ‘ofGLProgrammableRenderer::TYPE’ from ‘const string {aka const std::basic_string<char>}’ to ‘std::shared_ptr<ofBaseRenderer>’

[sphaero]

The fact I had black screen was due to #define SDK_RENDER 1 being commented, example is running although in my own code I just get a flickering screen so can't confirm if this issues is resolved. (I'm using SDK 0.4.4 btw)

[sphaero]

Just to add, I'm only getting a 30fps framerate. Could this be because there's still debug code in the addon? https://github.com/obviousjim/ofxOculusDK2/blob/mattebb-master/src/ofxOculusDK2.cpp#L716

I'm also seeing a segfault on exit:

Program received signal SIGSEGV, Segmentation fault.
0x00000000004adb5b in OVR::SDKWindow::getVisualFromDrawable (drawable=0, 
    vinfoOut=0x7fffffffdba0)
    at /home/people/arnaud/Documents/z25/z25-lib/unstable/openFrameworks/addons/ofxOculusDK2/libs/LibOVR/Src/Displays/OVR_Linux_SDKWindow.cpp:257
257         XVisualInfo* chosen = glXGetVisualFromFBConfig(display, *config);

Seems triggered by the destructor.

[sphaero]

The ofGLProgrammableRenderer error is due to changes in OF. It should now be done as:

int main(){
    ofGLWindowSettings settings;
    settings.width = 1280;
    settings.height = 800;
    settings.setGLVersion(4, 4);
    ofCreateWindow(settings);

    ofRunApp( new testApp());
}

This way the programmable example works. I can also use it in my own program however only 30fps. Jay, depth is sorted. So with all other issues aside let's close this one?

[sphaero]

Btw I still had the #define SDK_RENDER 1 in there. The programmable renderer runs very, very smooth.

[kylemcdonald]

just testing this on a mbpr with 750M, and the best performance i've gotten is from programmable renderer in mattebb-master with SDK_RENDER disabled / commented out.

but i'm not convinced that it's the programmable renderer making it fast. i get the same solid 60fps from the non-programmable renderer if i just add ofFill() before ofSphere() ... so it looks like it's just the fact that the programmable renderer isn't drawing a wireframe (which would be a more expensive operation)...

[obviousjim]

One thing to check is the refresh rate. forcing both displays to 60hz can often help with juttery scenes.

On Sat, Mar 7, 2015 at 12:36 PM, Kyle McDonald [email protected] wrote:

just testing this on a mbpr with 750M, and the best performance i've gotten is from programmable renderer in mattebb-master with SDK_RENDER disabled / commented out.

but i'm not convinced that it's the programmable renderer making it fast. i get the same solid 60fps from the non-programmable renderer if i just add ofFill() before ofSphere() ... so it looks like it's just the fact that the programmable renderer isn't drawing a wireframe (which would be a more expensive operation)...

— Reply to this email directly or view it on GitHub https://github.com/obviousjim/ofxOculusDK2/issues/8#issuecomment-77699972 .

• James

[sphaero]

The oculus should be 75hz. The only way I could get a smooth screen is by having a single display (only oculus) with 75hz refresh. Anything else guarantees jittery head movement. With 75hz I still had some jitters but a lot less than with 60hz.

[obviousjim]

Hmm, that isn't what I've experienced.

60hz works for me on windows and mac as long as both displays are forced to 60 and vertical sync is on (and it's running full speed that is!)

On Sun, Mar 8, 2015 at 12:38 PM, Arnaud Loonstra [email protected] wrote:

The oculus should be 75hz. The only way I could get a smooth screen is by having a single display (only oculus) with 75hz refresh. Anything else guarantees jittery head movement. With 75hz I still had some jitters but a lot less than with 60hz.

— Reply to this email directly or view it on GitHub https://github.com/obviousjim/ofxOculusDK2/issues/8#issuecomment-77759815 .

• James

[sphaero]

The more fps the better. I read (can't find a ref anymore) somewhere that the sensors are best at 75hz... The dev guide says: "Developers targeting this class of hardware will need to be very conscious of scene geometry because low-latency rendering at 75 FPS is critical for a usable VR experience. Irregular display updates are also particularly apparent in VR so your application must avoid skipping frames."

[mattebb]

Sorry for the late reply, at the end of a crazy 9 month project, really hoping to get back to this stuff in the next week or so...

sphaero is right, it's 75Hz. It's not the sensors though, it's the DK2's display refresh rate, which runs at 75Hz. You must be rendering at exactly 75Hz, and vsynced to the display otherwise you will get tearing, causing really nasty judder.

On Windows and Mac OS at least, this gets annoying since the refresh rate of any monitors attached get forced to the refresh rate of the primary monitor, presumably since the graphics card is only outputting pixels for all screens at once - it's not sending different buffers to different screens at different intervals.

What this means for the DK2 is that since many monitors are only 60Hz, you will need to set the DK2 as your primary display in order to get it running at 75Hz like it's intended. As mentioned above, sending pixels to the DK2 at less 75Hz will cause judder. Of course this is a major pain in the butt since making the DK2 your primary display means you have to navigate the desktop interface through the HMD when you're going to start your app etc.

This is one of the reasons for Oculus implementing 'direct mode' on Windows. Direct mode is a bit of a hack, working as a kind of dummy graphics driver, and enables the DK2 to bypass the normal windows graphics path and run at its native refresh rate, no matter what your desktop refresh rate is set to. Direct mode has other issues of its own though... James has an implementation of using direct mode in his branch, which I haven't ported over yet. I've recently installed windows on boot camp in order to test it, but haven't got to it yet.

As an aside, these problems were less apparent on the DK1's, since its refresh rate 60Hz. Upcoming HMDs however will be much higher - the Valve one is 90Hz, so it will be interesting to see how they solve the issues involved...

[mattebb]

@kylemcdonald :

I'd be surprised if the wireframe drawing was causing slowdowns. Are you comparing the 'ProgrammableRendering' OF example with the 'OculusRiftRendering' example? The OculusRiftRendering example is pretty old and has other issues there too. This needs to be all cleaned up...

You can try seeing if it is indeed the programmable renderer by opening the ProgrammableRendering example and commenting out ofSetCurrentRenderer(ofGLProgrammableRenderer::TYPE); in main.cpp , which will use the old fixed function pipeline.

[sphaero]

Btw, on Linux you are more flexible. You can give the Oculus its own X display. You keep your regular desktop but if you want to run an app on the Oculus you specify the display to run on, i.e. for an OF app:

DISPLAY=:1 make RunDebug

This is the Oculus's recommended setup I think.

[kylemcdonald]

@mattebb if you pull master and change the example to draw solid shapes instead of wireframes, it goes to 60fps. i haven't tested if the programmable renderer drops to a low framerate with the wireframe spheres, perhaps it's fine.

[ZeroLu]

Wow! I didn't notice that this topic is alive! The problem has been a struggle. However, we solve it by adding

settings.useDepth = true;

to the ofxOculusDK2.cpp in the ofxOculusDK2::setup(). In the end, it was like

bool ofxOculusDK2::setup(){
    ofFbo::Settings settings;
    settings.numSamples = 4;
    settings.internalformat = GL_RGBA;
    settings.useDepth = true;
    return setup(settings);
}

So simple! Hope it helps! @BenjaminPetry is my teacher and he solved it.