On Mon, Sep 7, 2015 at 9:37 PM, Björn Blissing <[email protected]> wrote: > > Jan Ciger wrote: >> That blog post I remember, but the conclusion there seems to be that >> positional timewarp introduces occlusion artifacts and a lot of extra >> complexity. I didn't sound like something they are intending to implement at >> the time. >> > > > Hi Jan, > > One reddit user made two short videos to display the effect of positional > timewarp. Both a normal case and one extreme case (pushed to fail). > > In the first video the frame rate is artificially dropped. Then he toggles > between positional timewarp on/off, to show how this trick can alleviate a > frame rate drop and still do some minor movement without stutter: > http://zippy.gfycat.com/JealousMeagerKestrel.webm > > The second video shows what happens if you move to much. Here rendering is > frozen and the HMD user continues to move until the effect fails miserably: > http://giant.gfycat.com/AgileThatGraysquirrel.webm > > The author wrote the following description: > "Timewarp is a way of distorting the image the HMD receives in the event that > the simulation can't keep up with the target frame rate or refresh rate of > the device in order to compensate. So, motion-to-photon latency and > headtracking will appear to remain consistent, even if your framerate is > fluctuating. This helps to alleviate jitter. This, however, was only > previously possible for rotational tracking in a prior Oculus SDK. Now the > distortion is possible for positional tracking as well. Both have their > limits of course -- you can only move so much before the scene becomes > terribly warped. It's meant to cover for momentary or tiny dips in frame rate > -- not for massive ones that last a while. "
Oh careful there. What he is actually showing is the effect of the asynchronous timewarp - if you can't hit the framerate, you reproject/warp the previous frame. That's a fairly new thing which required the driver support - you need to preempt the current rendering command stream if you aren't going to hit the target and re-project the old frame. The original idea of timewarping was to reduce the apparent tracking latency by warping the rendered image to match the tracking data late in the frame. That is what I was referring to - I doubt the latency reduction in the case of positional tracking is worth the effort, because the tracker is running at a comparable/same speed as your application. I have recently spent some crazy amount of time debugging framerate problems when the application (both OSG/OpenGL & Unity/D3D) are locked to VSYNC but you get horrible framerate jitter every once in a while for no apparent reason. This produces horrid artifacts when doing frame-sequential stereo, because suddenly the stereo flips (I am trying to do stereo on a GeForce with my own synchronisation hw). My hypothesis is that the Nvidia's driver is silently dropping frames from the pre-rendered frame queue if you are rendering too quickly (the scene was really simple, rendering in thousands of fps without vsync) instead of blocking or something. And it happens only on GeForce hardware, not on our old Quadro, so it seems to be driver "optimization". If the same thing happens with the Rift connected too, then these timewarping kludges are going to have a hard time keeping up. Or maybe they switch to a different code path in the driver when the Rift is detected ... I can't say I am a big fan of this - it is a kludge depending on the GPU vendor's good will and your good relationship with them (the SDK is NDA-ed, for ex.). Basically we are getting to the point where it is going to be impossible to deliver a properly working 3D application without working with the GPU vendor (good luck if you are a small indie guy). J. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
