Re: [osg-users] Oculus+OSG

[Bruno Fanini]

Hi all,

Has anyone in the community tested the Oculus CV1 with Bjorn integration? Any 
issues noticed/reported?
Regarding Oculus SDK 1.6 everything I tested so far is fine with a DK2.

Cheers,
Bruno

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=68285#68285





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Björn Blissing]

Hi,

So the first "stable" version of the Oculus SDK have been publicly released. I 
am happy to report that I got the OpenSceneGraph integration up and running. 
Although there is a bit more work to get it completely stable. 

Oculus have now launched what they call Oculus Home, which is their portal for 
pretty much everything. To play nice with this portal you have to handle your 
application with special care, or as Oculus calls it "VR Focus Management". 
This means that your application must handle situations such as the user 
unplugging the HMD, handling application shutdown and restart in a special way, 
etc.. 

This have not been implemented yet, the main part being the application 
shutdown problems. This is mainly due to differences between the way Oculus 
prefer you to handle shutdown and how shutdown is performed from OSG. So 
shutting down the application currently results in a crash on my machine. But 
hopefully this is something we should be able to fix.

As usual have the previous development been branched to:
https://github.com/bjornblissing/osgoculusviewer/tree/sdk-v0.8

Regards,
Björn

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=66688#66688





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Björn Blissing]

Chris Hanson wrote:
> Is the additional performance penalty for OGL apps (versus DX) from context 
> sharing still an issue?


Well, I still see some frame drops in the OpenGL example compared to the 
DirectX version, which is running without any drops at all. But it's much 
better compared to the previous SDK version. Now I am getting a frame drop 
maybe once every 2 minutes compared to getting drops every other second.

Best regards
Björn

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=65452#65452





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Christian Buchner]

NOTE: Oculus SDK and Runtime 0.8.0.0 beta have just been (quietly) released.

Find a change log here:
https://developer.oculus.com/downloads/pc/0.8.0.0-beta/Oculus_Runtime_for_Windows/

Christian


2015-09-29 21:24 GMT+02:00 Jan Ciger :

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hello,
>
> On 29/09/15 12:22, Antoine Galluet wrote:
> > Hi,
> >
> > Please tell me if you prefer me to post my issue in another thread
> > to keep this one clean.
> >
>
> Please, don't hijack threads with unrelated issues. Make a new
> thread/topic.
>
> > I'm starting with openscenegraph and the oculus. I compiled the
> > viewer and I can load the basic example (cow, plane). But I have an
> > error when I try to load one of my own .osgb. The viewer returns me
> > "InputStream::readObject<>: Unsupported wrapper class"
> >
> > Do you have any clue of what's going wrong?
>
>
> Your problem is likely because you are trying to load an .osgb file
> that was exported by an incompatible OSG version. That has nothing to
> do with Oculus Rift whatsoever.
>
> Try to use osgconv on the file and convert it to .osg for example. If
> you set OSG_NOTIFY_LEVEL env. variable to DEBUG, it might give you
> idea why it has failed.
>
>
> Regards,
>
> Jan
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iD8DBQFWCuWLn11XseNj94gRAqcnAJwJL/z9wZbD8nfGq6Ckc+AjBSzGZgCdGv0l
> ETZWZaJidAldsagsFMCikDI=
> =/Hf3
> -END PGP SIGNATURE-
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Björn Blissing]

cbuchner1 wrote:
> NOTE: Oculus SDK and Runtime 0.8.0.0 beta have just been (quietly) released.
> 
> Christian


Hi Christian,

I have already made the (minor) changes needed. And these commits have been 
pushed to the master branch at GitHub.

Best regards
Björn

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=65401#65401





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Chris Hanson]

Is the additional performance penalty for OGL apps (versus DX) from context
sharing still an issue?

On Thu, Oct 22, 2015 at 4:59 AM, Christian Buchner <
christian.buch...@gmail.com> wrote:

> NOTE: Oculus SDK and Runtime 0.8.0.0 beta have just been (quietly)
> released.
>
> Find a change log here:
>
> https://developer.oculus.com/downloads/pc/0.8.0.0-beta/Oculus_Runtime_for_Windows/
>
> Christian
>
>
> 2015-09-29 21:24 GMT+02:00 Jan Ciger :
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Hello,
>>
>> On 29/09/15 12:22, Antoine Galluet wrote:
>> > Hi,
>> >
>> > Please tell me if you prefer me to post my issue in another thread
>> > to keep this one clean.
>> >
>>
>> Please, don't hijack threads with unrelated issues. Make a new
>> thread/topic.
>>
>> > I'm starting with openscenegraph and the oculus. I compiled the
>> > viewer and I can load the basic example (cow, plane). But I have an
>> > error when I try to load one of my own .osgb. The viewer returns me
>> > "InputStream::readObject<>: Unsupported wrapper class"
>> >
>> > Do you have any clue of what's going wrong?
>>
>>
>> Your problem is likely because you are trying to load an .osgb file
>> that was exported by an incompatible OSG version. That has nothing to
>> do with Oculus Rift whatsoever.
>>
>> Try to use osgconv on the file and convert it to .osg for example. If
>> you set OSG_NOTIFY_LEVEL env. variable to DEBUG, it might give you
>> idea why it has failed.
>>
>>
>> Regards,
>>
>> Jan
>>
>>
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v2
>>
>> iD8DBQFWCuWLn11XseNj94gRAqcnAJwJL/z9wZbD8nfGq6Ckc+AjBSzGZgCdGv0l
>> ETZWZaJidAldsagsFMCikDI=
>> =/Hf3
>> -END PGP SIGNATURE-
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>


-- 
Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com
http://www.alphapixel.com/
Training • Consulting • Contracting
3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 •
GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
Legal/IP • Code Forensics • Digital Imaging • GIS • GPS •
osgEarth • Terrain • Telemetry • Cryptography • LIDAR • Embedded • Mobile •
iPhone/iPad/iOS • Android
@alphapixel  facebook.com/alphapixel (775)
623-PIXL [7495]
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Antoine Galluet]

Hi,

Please tell me if you prefer me to post my issue in another thread to keep this 
one clean.

I'm starting with openscenegraph and the oculus. I compiled the viewer and I 
can load the basic example (cow, plane). 
But I have an error when I try to load one of my own .osgb.
The viewer returns me "InputStream::readObject<>: Unsupported wrapper class"

Do you have any clue of what's going wrong?
... 

Thank you!

Cheers,
Antoine

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=65240#65240





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Jan Ciger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

On 29/09/15 12:22, Antoine Galluet wrote:
> Hi,
> 
> Please tell me if you prefer me to post my issue in another thread
> to keep this one clean.
> 

Please, don't hijack threads with unrelated issues. Make a new
thread/topic.

> I'm starting with openscenegraph and the oculus. I compiled the
> viewer and I can load the basic example (cow, plane). But I have an
> error when I try to load one of my own .osgb. The viewer returns me
> "InputStream::readObject<>: Unsupported wrapper class"
> 
> Do you have any clue of what's going wrong?


Your problem is likely because you are trying to load an .osgb file
that was exported by an incompatible OSG version. That has nothing to
do with Oculus Rift whatsoever.

Try to use osgconv on the file and convert it to .osg for example. If
you set OSG_NOTIFY_LEVEL env. variable to DEBUG, it might give you
idea why it has failed.


Regards,

Jan


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iD8DBQFWCuWLn11XseNj94gRAqcnAJwJL/z9wZbD8nfGq6Ckc+AjBSzGZgCdGv0l
ETZWZaJidAldsagsFMCikDI=
=/Hf3
-END PGP SIGNATURE-
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Björn Blissing]

Riccardo Corsi wrote:
> thanks Björn for the MSAA pointer - it was not the cause of the issue but the 
> explanation on the 75Hz helped me solve the problem:
> I had to remove the V-sync setting from the driver configuration. 
> 


Ok, I guess you had your V-sync setting to "Force on". Otherwise this should be 
handled with code inside the osgoculusviewer.


Riccardo Corsi wrote:
> So to keep a smooth experience the osg application must be able to render at 
> 75Hz for both eyes - is that correct?
> This is an important tip to keep in mind...


To cite "VR Design : Best Practices":

"PERFORMANCE, i.e. FRAME RATE, IS KEY
the difference between 75fps and 30fps is night and day…
you MUST deliver 75 fps at a minimum
don’t ship until you hit this bar
this isn’t an average, its a floor : so target 100fps average
this isn’t a luxury, its a requirement."

Source: http://dsky9.com/rift/vr-design-best-practices/

Best regards
Björn

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=65214#65214





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Riccardo Corsi]

Hi Björn,

first of all thank you for keeping up to date the Oculus integration!

I have just updated to SDK 0.7 + osgOculus head and the viewer works, but:

1. while the provided Oculus demos are really smooth with respect to
motion,
the osg viewer example results quite jerky, especially the rotation of the
head causes a sort of "hiccup"
during the motion

2. when using the osg viewer example, the right eye monitor has some
flickering every second or so,
a part of the screen becomes black/corrupted for some frames.

Have you ever noticed such behaviors?
Have you got any suggestion to fix them?

Thank you,
Ricky

On Wed, Sep 9, 2015 at 1:46 PM, Björn Blissing 
wrote:

> Hi,
>
> I just fixed a performance related bug.
>
> Due to misuse of an enum I had accidentally disabled all culling. (This
> bug would probably been avoided if strongly typed enum a'la C++11 were
> used).
>
> This bug only affects users using Oculus SDK 0.6 and 0.7. I urge all users
> of these versions of OsgOculusViewer to update to the head revision on
> GitHub.
>
> Best regards,
> Björn
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=65077#65077
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Björn Blissing]

Hi Ricky,

We have recently added support for MSAA in the OsgOculus integration (credits 
to Chris Denham). Rendering with MSAA enabled will require some extra GPU horse 
power and is probably the reason you see the stuttering in the rendering. If 
you look at the performance HUD (by pressing '2' on the keyboard), you will see 
what frame rate the compositor is working with. Anything under 75fps will cause 
stutter (on the DK2) and the performance HUD will report by incrementing the 
value: "Compositor Missed V-Sync Count".

To disable the MSAA change this line to a zero (or you could try to lower the 
amount to 2 and see if that helps):
https://github.com/bjornblissing/osgoculusviewer/blob/d0c425d3eda01b8134518ef524906e736a6aed9b/src/viewerexample.cpp#L50

This is probably also related to the flickering you are seeing. 

Best regards
Björn

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=65210#65210





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Christian Buchner]

hmm..
make sure a) SLI is disabled (if you have two or more cards linked)
b) you're running the latest nVidia developer drivers from here
https://developer.nvidia.com/gameworks-vr-driver-support

I have no such artifacts. Running the OSG 3.2 branch here.



2015-09-25 10:52 GMT+02:00 Riccardo Corsi :

> Hi Björn,
>
> first of all thank you for keeping up to date the Oculus integration!
>
> I have just updated to SDK 0.7 + osgOculus head and the viewer works, but:
>
> 1. while the provided Oculus demos are really smooth with respect to
> motion,
> the osg viewer example results quite jerky, especially the rotation of the
> head causes a sort of "hiccup"
> during the motion
>
> 2. when using the osg viewer example, the right eye monitor has some
> flickering every second or so,
> a part of the screen becomes black/corrupted for some frames.
>
> Have you ever noticed such behaviors?
> Have you got any suggestion to fix them?
>
> Thank you,
> Ricky
>
> On Wed, Sep 9, 2015 at 1:46 PM, Björn Blissing 
> wrote:
>
>> Hi,
>>
>> I just fixed a performance related bug.
>>
>> Due to misuse of an enum I had accidentally disabled all culling. (This
>> bug would probably been avoided if strongly typed enum a'la C++11 were
>> used).
>>
>> This bug only affects users using Oculus SDK 0.6 and 0.7. I urge all
>> users of these versions of OsgOculusViewer to update to the head revision
>> on GitHub.
>>
>> Best regards,
>> Björn
>>
>> --
>> Read this topic online here:
>> http://forum.openscenegraph.org/viewtopic.php?p=65077#65077
>>
>>
>>
>>
>>
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Riccardo Corsi]

Hi all,

thanks Björn for the MSAA pointer - it was not the cause of the issue but
the explanation on the 75Hz helped me solve the problem:
I had to remove the V-sync setting from the driver configuration.

Works like a charm now :)

So to keep a smooth experience the osg application must be able to render
at 75Hz for both eyes - is that correct?
This is an important tip to keep in mind...

I also have some questions about post-process but I'll switch to a
different thread.
Thanks again!
Ricky


On Fri, Sep 25, 2015 at 11:09 AM, Björn Blissing 
wrote:

> Hi Ricky,
>
> We have recently added support for MSAA in the OsgOculus integration
> (credits to Chris Denham). Rendering with MSAA enabled will require some
> extra GPU horse power and is probably the reason you see the stuttering in
> the rendering. If you look at the performance HUD (by pressing '2' on the
> keyboard), you will see what frame rate the compositor is working with.
> Anything under 75fps will cause stutter (on the DK2) and the performance
> HUD will report by incrementing the value: "Compositor Missed V-Sync Count".
>
> To disable the MSAA change this line to a zero (or you could try to lower
> the amount to 2 and see if that helps):
>
> https://github.com/bjornblissing/osgoculusviewer/blob/d0c425d3eda01b8134518ef524906e736a6aed9b/src/viewerexample.cpp#L50
>
> This is probably also related to the flickering you are seeing.
>
> Best regards
> Björn
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=65210#65210
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Björn Blissing]

Hi,

I just fixed a performance related bug. 

Due to misuse of an enum I had accidentally disabled all culling. (This bug 
would probably been avoided if strongly typed enum a'la C++11 were used).

This bug only affects users using Oculus SDK 0.6 and 0.7. I urge all users of 
these versions of OsgOculusViewer to update to the head revision on GitHub.

Best regards,
Björn

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=65077#65077





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Jan Ciger]

On Mon, Sep 7, 2015 at 9:37 PM, Björn Blissing  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
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Jan Ciger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/09/15 19:48, Björn Blissing wrote:
> I concur with your conclusion that it is highly likely that Oculus 
> are in fact using the asynchronous solution in the SDK0.6 and 0.7, 
> BUT they have not stated officially that the are using this. In 
> theory positional re-projection could be done in synchronous 
> rendering (although unlikely).

Positional reprojection could certainly be done synchronously (modulo
artifacts, etc), but the Reddit video you have posted explictly shows
framerate "smoothing".

That wouldn't happen if you do the warping at the end of each frame
(as before), regardless whether only rotational warp is done or both
positional and rotational. The framerate will be the same or even a
bit worse than before because more calculation has to be done per
frame. However, the tracking latency will be perceived as lower,
because the time between the movement and the change making it to the
screen will be shorter.

That's why I have concluded that the video is showing the new
asynchronous timewarping technique - that one actually permits to
fill-in for the missing frames and allows to smooth over framerate
jitter and occasional missed vsync deadline. The "old style"
timewarping doesn't do that (and was not advertised as a tool for that
neither).

J.



-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iD8DBQFV709In11XseNj94gRAjXnAKCJHP+0FeNrcRr42q/GtTxRrU1T+QCg0WTy
3LeldC81cWSvU5YFT1OPF3k=
=lrOB
-END PGP SIGNATURE-
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Björn Blissing]

Jan Ciger wrote:
> 
> Oh careful there.
> 


Not my words, I was only quoting the author of the videos.


Jan Ciger wrote:
> 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.
> 


In the "Oculus Rift Developer Guide" you will not find a word about 
asynchronous time warp. They are only saying that the compositing framework is 
handling distortion, timewarp, and GPU synchronization, whatever that incurs... 

I don't know if this means that Oculus currently are doing pure "original 
timewarp", pure "asynchronous timewarp" or a combination of the two (since its 
all happening inside the closed source part of the Oculus SDK). But the feature 
shown in the videos is currently available.

/Björn

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=65062#65062





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Jan Ciger]

On Tue, Sep 8, 2015 at 4:26 PM, Björn Blissing  wrote:

> In the "Oculus Rift Developer Guide" you will not find a word about 
> asynchronous time warp. They are only saying that the compositing framework 
> is handling distortion, timewarp, and GPU synchronization, whatever that 
> incurs...

It is described in this post (that you have mentioned too):
https://developer.oculus.com/blog/asynchronous-timewarp-examined/
It was one of the reasons they had to go to Nvidia (the other being
the direct mode support), because it is not possible to implement it
without driver support.

>
> I don't know if this means that Oculus currently are doing pure "original 
> timewarp", pure "asynchronous timewarp" or a combination of the two (since 
> its all happening inside the closed source part of the Oculus SDK). But the 
> feature shown in the videos is currently available.

Yes, that is the asynchronous timewarping in the new SDK. The
"original timewarp" does not have any effect on framerate (you still
need to render every frame + you are rendering the warping at the
end), only on perceived tracking latency. The difference is explained
in that blog article by their chief software architect. The original
timewarping by J. Carmack is described here:
https://web.archive.org/web/20140719085135/http://www.altdev.co/2013/02/22/latency-mitigation-strategies/


Regards,

J.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Björn Blissing]

Jan Ciger wrote:
> It is described in this post (that you have mentioned too):
> https://developer.oculus.com/blog/asynchronous-timewarp-examined/
> It was one of the reasons they had to go to Nvidia (the other being
> the direct mode support), because it is not possible to implement it
> without driver support.


I feel that you are misunderstanding what I am trying to say. I will try to 
reformulate myself.

First of all, we have two types of warping that could be performed:

1. Rotational - A pure 2D transformation, we only need a color texture for this.

2. Positional - A 3D re-projection were every pixel has to be transformed with 
its depth taken into account. This requires us to have a color texture, a depth 
texture and the projection matrices used.

Both techniques can be used either in sync with rendering (as was performed 
with rotational timewarp in SDK0.5 and earlier) or in a separate thread. The 
benefit of having it in a separate thread is that we can handle the case of the 
rendering is not done when the HMD requires a new image. But with the drawback 
that it requires low level support in OS/Driver. 

I concur with your conclusion that it is highly likely that Oculus are in fact 
using the asynchronous solution in the SDK0.6 and 0.7, BUT they have not stated 
officially that the are using this. In theory positional re-projection could be 
done in synchronous rendering (although unlikely). 

/Björn

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=65069#65069





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Christian Buchner]

wow, thank you.

did I understand correctly that the time warping feature cannot be
disabled, as it is a built-in feature of the Oculus SDK?


2015-09-07 13:16 GMT+02:00 Björn Blissing :

>
> cbuchner1 wrote:
> > let me use this thread to suggest a new feature. I would like the
> positional tracking of the osgoculusviewer to be optional, possibly by
> calling a member function oculusDevice->setPositionTracking(false);
> >
>
>
> Hi Christian,
>
> I have now added the feature to toggle the positional tracking (using the
> X-key on the keyboard). The state is handled inside the event handler which
> calls the following function in OculusDevice:
>
>
> Code:
> void OculusDevice::setPositionalTrackingState(bool state)
>
>
>
> Best regards,
> Björn
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=65045#65045
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Björn Blissing]

cbuchner1 wrote:
> 
> did I understand correctly that the time warping feature cannot be disabled, 
> as it is a built-in feature of the Oculus SDK?
> 


My understanding is that time warp is enabled by default. And I have not found 
a simple way of disabling it. I have posed a question on the Oculus forum, but 
have not received any replies, yet.

But when I have read some more about how positional time warp works I 
discovered that to be able to use it the compositing layer must of type 
ovrLayerType_EyeFovDepth. And currently the osgoculusviewer is using the 
simpler ovrLayerType_EyeFov layer type, which only supports rotational time 
warp.

Best regards
Björn

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=65047#65047





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Jan Ciger]

On Sun, Sep 6, 2015 at 7:34 PM, Björn Blissing  wrote:
> Hi Jan,
>
> Since SDK 0.6 Oculus have implemented both rotational AND positional 
> timewarp. The positional time warp require you to submit both a image texture 
> as well as a depth texture. This depth texture is then used to calculate the 
> tiny parallax effect due to movement between render and presentation.

Hum, alright. I was searching the documentation and the changelogs for
this but haven't seen it mentioned anywhere. I do wonder whether it
actually has any perceptible impact, considering the added complexity
and the relative slowness of the position tracking.

J.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Björn Blissing]

cbuchner1 wrote:
> let me use this thread to suggest a new feature. I would like the positional 
> tracking of the osgoculusviewer to be optional, possibly by calling a member 
> function oculusDevice->setPositionTracking(false);
> 


Hi Christian,

I have now added the feature to toggle the positional tracking (using the X-key 
on the keyboard). The state is handled inside the event handler which calls the 
following function in OculusDevice:


Code:
void OculusDevice::setPositionalTrackingState(bool state)



Best regards,
Björn

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=65045#65045





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Björn Blissing]

Jan Ciger wrote:
> 
> Hum, alright. I was searching the documentation and the changelogs for
> this but haven't seen it mentioned anywhere.


Hi Jan,

You will find it on page 22 in the 0.7 developer guide. It is a bit hidden 
inside the ovrLayerType_EyeFov description, the section about DepthTexture:

"Provides depth data for the EyeFovDepth layer type, and is used by positional 
timewarp to try to apply the correct parallax for the layer..." 

Michael Antonov also mentions it in a post on the Oculus blog:
https://developer.oculus.com/blog/asynchronous-timewarp-examined/

Best regards
Björn

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=65049#65049





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Jan Ciger]

Hi,

On Mon, Sep 7, 2015 at 2:52 PM, Björn Blissing  wrote:
> Hi Jan,
>
> You will find it on page 22 in the 0.7 developer guide. It is a bit hidden 
> inside the ovrLayerType_EyeFov description, the section about DepthTexture:
>
> "Provides depth data for the EyeFovDepth layer type, and is used by 
> positional timewarp to try to apply the correct parallax for the layer..."
>

Good catch, I didn't think to dig in there that deep. Well, they have
been really silent about a fairly major change like that. I would have
expected it mentioned in the changelog and/or some blog post ...

> Michael Antonov also mentions it in a post on the Oculus blog:
> https://developer.oculus.com/blog/asynchronous-timewarp-examined/

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.

J.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Björn Blissing]

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. 
"

Best regards
Björn

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=65056#65056





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Jan Ciger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

On 05/09/15 21:59, Björn Blissing wrote:
> Hi Christian,
> 
> Well, the simplest way of disabling the positional tracking is
> just to physically cover the lens of the Oculus Camera. ;)
> 
> I could make an option to disregard the positional information
> from the Oculus SDK. But since the new compositor framework
> introduced in Oculus SDK 0.6 the time-warp feature is enabled by
> default. So even if we don't use the positional information from
> the SDK, the positional information would be used in warping of the
> image (postional timewarp). So depending on how you overlay your
> video feed you may get strange juddering because of this feature.
> 

AFAIK, the timewarp uses only the current orientation from the
high-speed IMU that is on board. I have never heard about "positional
timewarp" being used (or even being developed). It probably wouldn't
make much sense, because the position tracker is much slower - around
60-120fps - compared to the IMU. So you wouldn't be likely to get a
"new" information towards the end of the frame warranting a
reprojection/warping.

J.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iD8DBQFV7B1Wn11XseNj94gRAosaAJ99Ady2i7IhJ9tcGN1tgKWCudSznQCeOufU
EaLvtVkeXlf1YcX5hIwB0YA=
=hpuj
-END PGP SIGNATURE-
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Björn Blissing]

Hi Jan,

Since SDK 0.6 Oculus have implemented both rotational AND positional timewarp. 
The positional time warp require you to submit both a image texture as well as 
a depth texture. This depth texture is then used to calculate the tiny parallax 
effect due to movement between render and presentation. 

Best regards
Björn

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=65033#65033





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Björn Blissing]

Hi Christian,

Well, the simplest way of disabling the positional tracking is just to 
physically cover the lens of the Oculus Camera. ;) 

I could make an option to disregard the positional information from the Oculus 
SDK. But since the new compositor framework introduced in Oculus SDK 0.6 the 
time-warp feature is enabled by default. So even if we don't use the positional 
information from the SDK, the positional information would be used in warping 
of the image (postional timewarp). So depending on how you overlay your video 
feed you may get strange juddering because of this feature.

Best regards,
Björn

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=65030#65030





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Christian Buchner]

Hi Björn,

let me use this thread to suggest a new feature. I would like the
positional tracking of the osgoculusviewer to be optional, possibly by
calling a member function oculusDevice->setPositionTracking(false);

If you remember my use case, there is a camera strapped to a person's head,
which already tracks the head position. Superimposing an external tracking
would cause some issues.

In the 0.5.0.1 version of the osgoculus viewer I've already added a switch
to disable the tracking, but it seems I will have to repeat it for the
current 0.7.0.0 enabled version (the master branch)

Also, somewhat off-topic: I may have found an alternative to the DK2 head
set by using an iphone 6 and Google Cardboard like devices, such as the
Zeiss VR One. Combine this with the duet display driver (duetdisplay.com)
and you can use this iphone-based headset with sufficiently low latency at
60 FPS while using the PC for rendering the graphics. As I need no
positional tracking from the phone fed back from the PC, this will work for
me.

Christian


2015-09-02 22:27 GMT+02:00 Björn Blissing :

>
> cbuchner1 wrote:
> > Trying to build the current osgoculus master branch against Oculus SDK
> 0.7.0.0 using OSG 3.2.1
> >
> >
> > the following code from oculusdevice.cpp is making trouble. For OSG 3.2
> the variable "ctx" is undefined.
> >
> > void OculusTextureBuffer::setRenderSurface(const osg::State& state)
> > {
> > #if(OSG_VERSION_GREATER_OR_EQUAL(3, 4, 0))
> > const osg::GLExtensions* fbo_ext = state.get();
> > #else
> > const osg::FBOExtensions* fbo_ext =
> osg::FBOExtensions::instance(ctx, true);
> > #endif
> > ...
> >
> > void OculusDepthBuffer::setRenderSurface(const osg::State& state)
> > {
> > #if(OSG_VERSION_GREATER_OR_EQUAL(3, 4, 0))
> > const osg::GLExtensions* fbo_ext = state.get();
> > #else
> > const osg::FBOExtensions* fbo_ext =
> osg::FBOExtensions::instance(ctx, true);
> > #endif
> > ...
> >
>
>
>
> cbuchner1 wrote:
> > A followup: inserting the following line into both #else branches fixes
> it
> >
> > const unsigned int ctx = state.getContextID();
> >
>
>
> Ah, the woes of trying to have support for multiple OSG version at the
> same time. I did some refactoring yesterday and this bug obviously slipped
> through without being tested. Sorry about that.
>
> Another user already submitted a pull request with a fix, which is merged.
>
> Best regards
> Björn
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=65002#65002
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Christian Buchner]

Trying to build the current osgoculus master branch against Oculus SDK
0.7.0.0 using OSG 3.2.1

the following code from oculusdevice.cpp is making trouble. For OSG 3.2
the variable "ctx" is undefined.

void OculusTextureBuffer::setRenderSurface(const osg::State& state)
{
#if(OSG_VERSION_GREATER_OR_EQUAL(3, 4, 0))
const osg::GLExtensions* fbo_ext = state.get();
#else
const osg::FBOExtensions* fbo_ext = osg::FBOExtensions::instance(ctx,
true);
#endif
...

void OculusDepthBuffer::setRenderSurface(const osg::State& state)
{
#if(OSG_VERSION_GREATER_OR_EQUAL(3, 4, 0))
const osg::GLExtensions* fbo_ext = state.get();
#else
const osg::FBOExtensions* fbo_ext = osg::FBOExtensions::instance(ctx,
true);
#endif
...


2015-09-01 16:31 GMT+02:00 Jan Ciger :

> On Tue, Sep 1, 2015 at 2:57 PM, Christian Buchner
>  wrote:
> >
> > In this case I am using a slightly modified DirectShow OSG plug-in,
> running
> > the osgviewer in single threaded mode. The plug-in provides an
> > osg::ImageStream and updates a texture that is displayed in the OSG
> scene.
> > The camera is an USB 3.0 model, and I would expect it to be one of the
> > fastest "web cams" out there.
>
> The DirectShow filter chain alone will add you several frames of
> latency easily. DirectShow is far from a real time, low latency API.
>
> The fact that the camera is an USB 3.0 model is a red herring - that
> only affects how fast it could *theoretically* transfer data but has
> no impact on the various buffering and processing done once the data
> are in your machine.
>
> > I am hoping that OpenGL applications also benefit from the low level
> driver support created for the Oculus and similar VR devices.
>
> Even if they didn't, even the plain old Rift DK1 has a sub 20ms
> latency. So that is certainly not the source of your problem.
>
> J.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Christian Buchner]

A followup: inserting the following line into both #else branches fixes it

const unsigned int ctx = state.getContextID();


2015-09-02 11:06 GMT+02:00 Christian Buchner :

>
> Trying to build the current osgoculus master branch against Oculus SDK
> 0.7.0.0 using OSG 3.2.1
>
> the following code from oculusdevice.cpp is making trouble. For OSG 3.2
> the variable "ctx" is undefined.
>
> void OculusTextureBuffer::setRenderSurface(const osg::State& state)
> {
> #if(OSG_VERSION_GREATER_OR_EQUAL(3, 4, 0))
> const osg::GLExtensions* fbo_ext = state.get();
> #else
> const osg::FBOExtensions* fbo_ext = osg::FBOExtensions::instance(ctx,
> true);
> #endif
> ...
>
> void OculusDepthBuffer::setRenderSurface(const osg::State& state)
> {
> #if(OSG_VERSION_GREATER_OR_EQUAL(3, 4, 0))
> const osg::GLExtensions* fbo_ext = state.get();
> #else
> const osg::FBOExtensions* fbo_ext = osg::FBOExtensions::instance(ctx,
> true);
> #endif
> ...
>
>
> 2015-09-01 16:31 GMT+02:00 Jan Ciger :
>
>> On Tue, Sep 1, 2015 at 2:57 PM, Christian Buchner
>>  wrote:
>> >
>> > In this case I am using a slightly modified DirectShow OSG plug-in,
>> running
>> > the osgviewer in single threaded mode. The plug-in provides an
>> > osg::ImageStream and updates a texture that is displayed in the OSG
>> scene.
>> > The camera is an USB 3.0 model, and I would expect it to be one of the
>> > fastest "web cams" out there.
>>
>> The DirectShow filter chain alone will add you several frames of
>> latency easily. DirectShow is far from a real time, low latency API.
>>
>> The fact that the camera is an USB 3.0 model is a red herring - that
>> only affects how fast it could *theoretically* transfer data but has
>> no impact on the various buffering and processing done once the data
>> are in your machine.
>>
>> > I am hoping that OpenGL applications also benefit from the low level
>> driver support created for the Oculus and similar VR devices.
>>
>> Even if they didn't, even the plain old Rift DK1 has a sub 20ms
>> latency. So that is certainly not the source of your problem.
>>
>> J.
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Björn Blissing]

cbuchner1 wrote:
> Trying to build the current osgoculus master branch against Oculus SDK 
> 0.7.0.0 using OSG 3.2.1
> 
> 
> the following code from oculusdevice.cpp is making trouble. For OSG 3.2  the 
> variable "ctx" is undefined.
> 
> void OculusTextureBuffer::setRenderSurface(const osg::State& state)
> {
> #if(OSG_VERSION_GREATER_OR_EQUAL(3, 4, 0))
>     const osg::GLExtensions* fbo_ext = state.get();
> #else
>     const osg::FBOExtensions* fbo_ext = osg::FBOExtensions::instance(ctx, 
> true);
> #endif
> ...
> 
> void OculusDepthBuffer::setRenderSurface(const osg::State& state)
> {
> #if(OSG_VERSION_GREATER_OR_EQUAL(3, 4, 0))
>     const osg::GLExtensions* fbo_ext = state.get();
> #else
>     const osg::FBOExtensions* fbo_ext = osg::FBOExtensions::instance(ctx, 
> true);
> #endif
> ...
> 



cbuchner1 wrote:
> A followup: inserting the following line into both #else branches fixes it
> 
> const unsigned int ctx = state.getContextID();
> 


Ah, the woes of trying to have support for multiple OSG version at the same 
time. I did some refactoring yesterday and this bug obviously slipped through 
without being tested. Sorry about that. 

Another user already submitted a pull request with a fix, which is merged.

Best regards
Björn

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=65002#65002





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Jan Ciger]

On Tue, Sep 1, 2015 at 11:15 AM, Christian Buchner
 wrote:
>
> Can you make any statements regarding latency improvements upgrading from
> the 0.6 SDK to 0.7 for osgoculusviewer based applications?
>
> Our current use case is currently, attaching an Intel RealSense camera to
> the front of the Oculus DK2 and streaming a live image into the viewer's
> eyes. Our latency is currently in the area of about 3-4 video frames @75 Hz,
> amounting to 40-50 ms. This is a bit too high and causes some motion
> sickness and slow reactions in our unfortunate test persons. ;)
>
> Christian

I haven't tried the latest Oculus SDK, but the problem you are
describing is most likely due to your implementation of the video
streaming than the Oculus SDK. I doubt they would release code that is
THAT broken, especially when they go to the trouble of having custom
functionality built into the Nvidia driver to squeeze down the latency
even more.

How much latency has the RealSense camera itself?

J.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Christian Buchner]

Can you make any statements regarding latency improvements upgrading from
the 0.6 SDK to 0.7 for osgoculusviewer based applications?

Our current use case is currently, attaching an Intel RealSense camera to
the front of the Oculus DK2 and streaming a live image into the viewer's
eyes. Our latency is currently in the area of about 3-4 video frames @75
Hz, amounting to 40-50 ms. This is a bit too high and causes some motion
sickness and slow reactions in our unfortunate test persons. ;)

Christian




2015-08-28 14:41 GMT+02:00 Björn Blissing :

> Hi,
>
> I am happy to report that support for Oculus SDK 0.7.0.0 is added and
> merged into the master branch.
>
> The latest Oculus SDK v0.6 development has been merged back into the 0.6
> branch:
> https://github.com/bjornblissing/osgoculusviewer/tree/sdk-v0.6
>
> Best regards
> Björn
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=64934#64934
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Björn Blissing]

cbuchner1 wrote:
> Can you make any statements regarding latency improvements upgrading from the 
> 0.6 SDK to 0.7 for osgoculusviewer based applications?


Hi Christian,

I have not had time to do any measurements regarding latency differences 
between 0.6 and 0.7 yet. Sorry.



cbuchner1 wrote:
> Our current use case is currently, attaching an Intel RealSense camera to the 
> front of the Oculus DK2 and streaming a live image into the viewer's eyes. 
> Our latency is currently in the area of about 3-4 video frames @75 Hz, 
> amounting to 40-50 ms. This is a bit too high and causes some motion sickness 
> and slow reactions in our unfortunate test persons. ;)


Are you talking about pure rendering latency (motion to photon) or the camera 
to HMD latency (photon to photon)?

If you are talking about the latter 40-50 is quite good I would say. And as Jan 
says, the camera is probably the limiting factor in that case. Another problem 
can be if you run the camera capture in the same thread as the rest of the 
rendering. Moving the camera capture to an own thread gave me a great 
performance boost, but results in the cameras running asynchronous with the 
rendering. This in turn can gives a larger variance in latency.

Best regards
Björn

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=64975#64975





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Christian Buchner]

In this case I am using a slightly modified DirectShow OSG plug-in, running
the osgviewer in single threaded mode. The plug-in provides an
osg::ImageStream and updates a texture that is displayed in the OSG scene.
The camera is an USB 3.0 model, and I would expect it to be one of the
fastest "web cams" out there.

I am hoping that OpenGL applications also benefit from the low level driver
support created for the Oculus and similar VR devices.

Christian


2015-09-01 12:48 GMT+02:00 Björn Blissing :

>
> cbuchner1 wrote:
> > Can you make any statements regarding latency improvements upgrading
> from the 0.6 SDK to 0.7 for osgoculusviewer based applications?
>
>
> Hi Christian,
>
> I have not had time to do any measurements regarding latency differences
> between 0.6 and 0.7 yet. Sorry.
>
>
>
> cbuchner1 wrote:
> > Our current use case is currently, attaching an Intel RealSense camera
> to the front of the Oculus DK2 and streaming a live image into the viewer's
> eyes. Our latency is currently in the area of about 3-4 video frames @75
> Hz, amounting to 40-50 ms. This is a bit too high and causes some motion
> sickness and slow reactions in our unfortunate test persons. ;)
>
>
> Are you talking about pure rendering latency (motion to photon) or the
> camera to HMD latency (photon to photon)?
>
> If you are talking about the latter 40-50 is quite good I would say. And
> as Jan says, the camera is probably the limiting factor in that case.
> Another problem can be if you run the camera capture in the same thread as
> the rest of the rendering. Moving the camera capture to an own thread gave
> me a great performance boost, but results in the cameras running
> asynchronous with the rendering. This in turn can gives a larger variance
> in latency.
>
> Best regards
> Björn
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=64975#64975
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Jan Ciger]

On Tue, Sep 1, 2015 at 2:57 PM, Christian Buchner
 wrote:
>
> In this case I am using a slightly modified DirectShow OSG plug-in, running
> the osgviewer in single threaded mode. The plug-in provides an
> osg::ImageStream and updates a texture that is displayed in the OSG scene.
> The camera is an USB 3.0 model, and I would expect it to be one of the
> fastest "web cams" out there.

The DirectShow filter chain alone will add you several frames of
latency easily. DirectShow is far from a real time, low latency API.

The fact that the camera is an USB 3.0 model is a red herring - that
only affects how fast it could *theoretically* transfer data but has
no impact on the various buffering and processing done once the data
are in your machine.

> I am hoping that OpenGL applications also benefit from the low level driver 
> support created for the Oculus and similar VR devices.

Even if they didn't, even the plain old Rift DK1 has a sub 20ms
latency. So that is certainly not the source of your problem.

J.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Björn Blissing]

Hi Christian,


Well, I don't know how the OSG-DirectShow plugin works regarding threading and 
latency.


When I did a similar setup I used OpenCV and wrote a plugin that spawn a thread 
for image acquisition. Here is my code:

https://github.com/bjornblissing/osgopencv


Hopefully the new Oculus SDK has cut the latency a bit, BUT this does not 
matter much if the main part of the latency comes originates from the image

acquisition.


Best regards

Björn


Från: osg-users <osg-users-boun...@lists.openscenegraph.org> för Christian 
Buchner <christian.buch...@gmail.com>
Skickat: den 1 september 2015 14:57
Till: OpenSceneGraph Users
Ämne: Re: [osg-users] Oculus+OSG


In this case I am using a slightly modified DirectShow OSG plug-in, running the 
osgviewer in single threaded mode. The plug-in provides an osg::ImageStream and 
updates a texture that is displayed in the OSG scene. The camera is an USB 3.0 
model, and I would expect it to be one of the fastest "web cams" out there.

I am hoping that OpenGL applications also benefit from the low level driver 
support created for the Oculus and similar VR devices.

Christian


2015-09-01 12:48 GMT+02:00 Björn Blissing 
<bjorn.bliss...@vti.se<mailto:bjorn.bliss...@vti.se>>:

cbuchner1 wrote:
> Can you make any statements regarding latency improvements upgrading from the 
> 0.6 SDK to 0.7 for osgoculusviewer based applications?


Hi Christian,

I have not had time to do any measurements regarding latency differences 
between 0.6 and 0.7 yet. Sorry.



cbuchner1 wrote:
> Our current use case is currently, attaching an Intel RealSense camera to the 
> front of the Oculus DK2 and streaming a live image into the viewer's eyes. 
> Our latency is currently in the area of about 3-4 video frames @75 Hz, 
> amounting to 40-50 ms. This is a bit too high and causes some motion sickness 
> and slow reactions in our unfortunate test persons. ;)


Are you talking about pure rendering latency (motion to photon) or the camera 
to HMD latency (photon to photon)?

If you are talking about the latter 40-50 is quite good I would say. And as Jan 
says, the camera is probably the limiting factor in that case. Another problem 
can be if you run the camera capture in the same thread as the rest of the 
rendering. Moving the camera capture to an own thread gave me a great 
performance boost, but results in the cameras running asynchronous with the 
rendering. This in turn can gives a larger variance in latency.

Best regards
Björn

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=64975#64975





___
osg-users mailing list
osg-users@lists.openscenegraph.org<mailto:osg-users@lists.openscenegraph.org>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Björn Blissing]

Hi,

I am happy to report that support for Oculus SDK 0.7.0.0 is added and merged 
into the master branch.

The latest Oculus SDK v0.6 development has been merged back into the 0.6 branch:
https://github.com/bjornblissing/osgoculusviewer/tree/sdk-v0.6

Best regards 
Björn

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=64934#64934





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Björn Blissing]

Hi,

I am happy to report that support for Oculus SDK 0.6.0.1 is now complete.  This 
has now been merged into the master branch at GitHub.

The Oculus SDK v0.5, which is the last version supporting MacOS and Linux has 
been branched to:
https://github.com/bjornblissing/osgoculusviewer/tree/sdk-v0.5

Best regards
Björn

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=64755#64755





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Björn Blissing]

Hi Christian,

I have not seen this error before, but I have had similar errors. These can 
vary with Platform (Windows/Linux/MacOS), OS version (Win7/Win8 etc.), Oculus 
SDK version, Oculus Runtime version, Graphic card (Nvidia/AMD), Graphic Card 
Driver version and monitor setup. It is impossible to cover all possible 
configurations. 

My best advice is to try to find the offending GL command which triggers the 
error. Last time this type of error happened to me I had to instrument the OSG 
code which called the GL commands with extra debug output to find the offending 
GL command.

See this issue for the process used that time:
https://github.com/bjornblissing/osgoculusviewer/issues/36

If you find a solution I will gladly merge your changes.

Regards,
Björn

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=64610#64610





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Christian Buchner]

Hi,

Great work on the OSG oculus support! It built and ran beautifully, for the
most part.

The OculusViewerSDK example continuously gives the following error message
while running. There are no observable graphics issues though - the sample
runs fine it appears.

Warning: detected OpenGL error 'invalid operation' after applying attribute
Viewport 00ABF10CF6F0

I've been building osgoculusviewer-master against the Oculus SDK 5.0.1 on
Windows 8.1 64bit. The underlying OSG version is 3.2.1

I am using an nVidia GTX 970 card with the most recent WHQL drivers. My
Rift Display Mode is set to Direct HMD access

Is there any known cause to this error, or a possible workaround?

Christian
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Jan Ciger]

Hi,

On Thu, May 21, 2015 at 2:20 AM, Björn Blissing bjorn.bliss...@vti.se
wrote:

 Hi again,

 I have finally been able to solve the last piece of the puzzle. This means
 that for Oculus SDK v0.5.0.1 the examples can do both client- and SDK based
 distortion rendering.

 The v0.5.0.1 version of the Oculus SDK is also the last version with
 support for Linux and Mac, due to the fact that Oculus has halted (the
 official wording is paused) development of the SDK for all platforms but
 Windows. This version is also the last version with client distortion
 rendering support.

 Now I focus my efforts on getting support for the latest SDK version
 v0.6.0.0. This version contains some major changes which will require some
 major refactoring on my part as well as some new features that will have to
 be integrated (i.e. the new layers concept).



Could you branch/tag the new Windows-only code into a separate branch,
please? It would make life easier for the folks like me who have the older
DK1/DK2 HMDs and need it to work on Linux/Mac for example.

rant
It is really unfortunate that Oculus is making the integration of their
stuff harder and more complicated with every SDK revision instead of the
opposite :( I am seriously starting to look at the alternatives now, the
Oculus kit is becoming way too much pain to deal with and for little
benefit.

I also wonder how is the OpenHMD (http://openhmd.net/) effort doing - the
last I have looked they had DK1 support, now they seem to have DK2 as well,
but no positional tracking support. However, there seems to be some
impressive independent work being done on that here:
http://doc-ok.org/?p=1095

There is also OSVR which includes HMD support, but I believe they have only
plugins using the official SDK (?)

So in the end, it might be possible to have a fully independent, open and
*sane* SDK even for Oculus.
/rant

J.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Jan Ciger]

On Thu, May 21, 2015 at 3:55 PM, Björn Blissing bjorn.bliss...@vti.se
wrote:


 The head of the master branch is currently supporting the v0.5.0.1 of
 Oculus SDK. The work with v0.6.0.0 is currently located in a separate
 branch. I have not decided yet on how to proceed with the branches. I
 usually tag the last working commit of an SDK version before pushing
 commits belonging to a new SDK version. But since Linux and Mac will be
 abandoned, it may be a demand for a separate branch for the continuous
 development based on SDK v0.5.0.1.

 I will keep the idea in mind...


I think that for the time being it is completely enough to simply tag the
last good version and document the tag name somewhere, so that when
someone needs it the revision can be found easily. A branch can be done at
any time later, if required.


 Well, I guess they believe that reducing the number of accessible parts of
 the SDK makes the product easier to integrate. BUT as they keep closing the
 SDK they also reduces the ways people can use the product. They seem 100%
 focused on (windows) games (which maybe the smart business decision), but
 they leave out the people how like to hack stuff and create solutions which
 no one at Oculus Inc. imagined.


The problem is that they are shooting themselves in the foot, even when it
comes to the mainstream (i.e. game) applications. I was working quite a
bit with the Unreal Engine 4 and their rendering code recently because of
my work and there the Oculus integration is a token effort at best and a
horrible, bolted on kludge at worst. The last time I checked (4.7.x
version) there wasn't even support for the DK2 and things like post render
warping yet. Perhaps this has changed in the upcoming 4.8, but I didn't
have time to check so far.

 UE4 renders in such way that there are several rendering threads
collecting rendering and compositing commands (UE4 uses deferred shading
approach) into tasks and that is then queued for another thread to be
actually executed by one of the RHI (D3D/GL/GL ES/...) backends. That is
all happening asynchronously, in order to achieve the best performance. The
engine architecture is such that integrating deeply intrusive features like
the post render warping or the predistortion from the Oculus SDK is a major
and messy work, having to introduce the Oculus-specific code all over the
place.

The SDKs my way or the highway approach pretty much flies in the face of
all the abstraction and architecture work in these engines :( And that is
all for a single HMD - what about Valve, Morpheus and perhaps yet another
major player that could appear? All those (will) require their own hacks
like this. I doubt that this is going to be a sustainable development model
- the costs of maintaining the resulting code mess will be enormous. Or the
engine developers end up saying that they support only HMD X on a platform
Y and that's it. In the worst case the company decides that VR is so niche
market that the effort to support an HMD is simply not worth it. And those
are commercial developers, good luck to indies or the open source ones
without the resources and access that Epic or Unity have ...


 Hopefully the competition will benefit the HMD manufacturer which is most
 open, but I guess that the winner will be the one who can provide the
 killer application (or in this case; the killer game).


I wonder what will be the actual adoption rate by the game studios. So far
there was a lot of hype, but very few have explicitly announced support for
HMDs in their upcoming titles (it isn't something you can just bolt on
after the fact, for both technical and usability reasons). Moreover, pretty
much the only game engine on the market with good support for the Rift is
Unity3D right now. And that is only because Oculus engineers are working on
it, AFAIK.

I guess we need to wait until the next year and see what happens once the
mass market CV1 is released.

J.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Björn Blissing]

Jan Ciger wrote:
 Could you branch/tag the new Windows-only code into a separate branch, 
 please? It would make life easier for the folks like me who have the older 
 DK1/DK2 HMDs and need it to work on Linux/Mac for example. 


The head of the master branch is currently supporting the v0.5.0.1 of Oculus 
SDK. The work with v0.6.0.0 is currently located in a separate branch. I have 
not decided yet on how to proceed with the branches. I usually tag the last 
working commit of an SDK version before pushing commits belonging to a new SDK 
version. But since Linux and Mac will be abandoned, it may be a demand for a 
separate branch for the continuous development based on SDK v0.5.0.1. 

I will keep the idea in mind...


Jan Ciger wrote:
 It is really unfortunate that Oculus is making the integration of their stuff 
 harder and more complicated with every SDK revision instead of the opposite 
 :( I am seriously starting to look at the alternatives now, the Oculus kit is 
 becoming way too much pain to deal with and for little benefit. 


Well, I guess they believe that reducing the number of accessible parts of the 
SDK makes the product easier to integrate. BUT as they keep closing the SDK 
they also reduces the ways people can use the product. They seem 100% focused 
on (windows) games (which maybe the smart business decision), but they leave 
out the people how like to hack stuff and create solutions which no one at 
Oculus Inc. imagined. 

Hopefully the competition will benefit the HMD manufacturer which is most open, 
but I guess that the winner will be the one who can provide the killer 
application (or in this case; the killer game).

Best regards
Björn

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=63793#63793





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Björn Blissing]

Hi again,

I have finally been able to solve the last piece of the puzzle. This means that 
for Oculus SDK v0.5.0.1 the examples can do both client- and SDK based 
distortion rendering. 

The v0.5.0.1 version of the Oculus SDK is also the last version with support 
for Linux and Mac, due to the fact that Oculus has halted (the official wording 
is paused) development of the SDK for all platforms but Windows. This version 
is also the last version with client distortion rendering support. 

Now I focus my efforts on getting support for the latest SDK version v0.6.0.0. 
This version contains some major changes which will require some major 
refactoring on my part as well as some new features that will have to be 
integrated (i.e. the new layers concept). 

I will keep you posted on my progress.

Best regards
Björn

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=63776#63776





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Björn Blissing]

PhoenixBF wrote:
 
 Just a question:
 are there significant differences in performance on the long run / scaling up 
 to complex models 
 when using the composite viewer approach (compositeviewerexample) rather than 
 view config (viewconfigexample) or basic viewerexample?
 
 Bruno Fanini
 
 3D Graphics, Natural Interaction Developer  Digital Artist
 


Hi Bruno,

I had not profiled the application before, but your post made me curious. I 
downloaded the Qijang city mode which is quite large 
(http://openscenegraph.org/downloads/3rdParty-Data/Qjiang/qjiang.ive) and  
tested running the application with gDebugger in profiling mode and recorded 
the following metrics:

[Image: http://i.imgur.com/fSwrqmJ.png ]
http://i.imgur.com/fSwrqmJ.png

[Image: http://i.imgur.com/nlyqj1U.png ]
http://i.imgur.com/nlyqj1U.png

[Image: http://i.imgur.com/4QIYwC7.png ]
http://i.imgur.com/4QIYwC7.png

This shows very little difference in performance. Looking at the pure OpenGL 
between the different examples, then ViewerExample and ViewConfigExample is 
pretty much identical. CompositeViewer does some more calls, but that does not 
seem to affect performance.

Best regards
Björn

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=63009#63009





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Christian Buchner]

it took a little digging on their web site, but here's the list of editions
and their specific features.
http://www.worldviz.com/products/vizard#Editions

it seems the Light Edition will annoy you with a persistent watermark and
there are restrictions regarding packaging and distributing your created
works: In both Vizard Free and Vizard Lite, published executables are
branded and exit after 5 minutes.
Customization of rendering and scene graph also isn't available in the Lite
edition.


2015-03-09 9:08 GMT+01:00 Christian Buchner christian.buch...@gmail.com:


 This Vizard product looks neat - and it's based on OpenSceneGraph. Wow.
 Would anyone know the specific limitations of the Vizard Lite Edition?


 2015-02-26 10:14 GMT+01:00 Robert Osfield robert.osfi...@gmail.com:

 Hi Max,

 On 25 February 2015 at 19:26, Max Maslov maxmaslov.k...@gmail.com
 wrote:

 Is there any OSG apps with Oculus support?


 I am not sure the status of range of publicly available OSG apps that
 have Oculus support but there are several OSG users discussing work with
 it.  One package that has just gone public with Oculus support is Vizard
 5.1 from WorldViz.com:


 http://www.worldviz.com/newsletter/vizard-5-1?utm_source=wysijautm_medium=emailutm_campaign=2015_02_Newsletter


 And looking forward to supporting Samsung Gear VR.  8)


 I don't know that situation with Samsung Gear.  It's based on a Galaxy
 Note 4 display so limits one to using a specific Android device.  I do like
 the idea of standalone VR headset though.

 Robert.

 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org



___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Christian Buchner]

This Vizard product looks neat - and it's based on OpenSceneGraph. Wow.
Would anyone know the specific limitations of the Vizard Lite Edition?


2015-02-26 10:14 GMT+01:00 Robert Osfield robert.osfi...@gmail.com:

 Hi Max,

 On 25 February 2015 at 19:26, Max Maslov maxmaslov.k...@gmail.com wrote:

 Is there any OSG apps with Oculus support?


 I am not sure the status of range of publicly available OSG apps that have
 Oculus support but there are several OSG users discussing work with it.
 One package that has just gone public with Oculus support is Vizard 5.1
 from WorldViz.com:


 http://www.worldviz.com/newsletter/vizard-5-1?utm_source=wysijautm_medium=emailutm_campaign=2015_02_Newsletter


 And looking forward to supporting Samsung Gear VR.  8)


 I don't know that situation with Samsung Gear.  It's based on a Galaxy
 Note 4 display so limits one to using a specific Android device.  I do like
 the idea of standalone VR headset though.

 Robert.

 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Bruno Fanini]

Hi osgusers and Bjorn,
Very good work indeed! I tested latest svn on a Windows 8 PC and it works
fine so far.
I confirm it works without judder on Direct Mode, also with positional
tracking
I had no paricular issue into integrating the oculus viewer with our walk
manipulator.

Just a question:
are there significant differences in performance on the long run / scaling
up to complex models
when using the composite viewer approach (compositeviewerexample) rather
than view config (viewconfigexample) or basic viewerexample?

All the best


On Thu, Feb 26, 2015 at 10:14 AM, Robert Osfield robert.osfi...@gmail.com
wrote:

 Hi Max,

 On 25 February 2015 at 19:26, Max Maslov maxmaslov.k...@gmail.com wrote:

 Is there any OSG apps with Oculus support?


 I am not sure the status of range of publicly available OSG apps that have
 Oculus support but there are several OSG users discussing work with it.
 One package that has just gone public with Oculus support is Vizard 5.1
 from WorldViz.com:


 http://www.worldviz.com/newsletter/vizard-5-1?utm_source=wysijautm_medium=emailutm_campaign=2015_02_Newsletter


 And looking forward to supporting Samsung Gear VR.  8)


 I don't know that situation with Samsung Gear.  It's based on a Galaxy
 Note 4 display so limits one to using a specific Android device.  I do like
 the idea of standalone VR headset though.

 Robert.

 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org




-- 
Bruno Fanini
*3D Graphics, Natural Interaction Developer  Digital Artist*
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Robert Osfield]

Hi Max,

On 25 February 2015 at 19:26, Max Maslov maxmaslov.k...@gmail.com wrote:

 Is there any OSG apps with Oculus support?


I am not sure the status of range of publicly available OSG apps that have
Oculus support but there are several OSG users discussing work with it.
One package that has just gone public with Oculus support is Vizard 5.1
from WorldViz.com:

http://www.worldviz.com/newsletter/vizard-5-1?utm_source=wysijautm_medium=emailutm_campaign=2015_02_Newsletter


 And looking forward to supporting Samsung Gear VR.  8)


I don't know that situation with Samsung Gear.  It's based on a Galaxy Note
4 display so limits one to using a specific Android device.  I do like the
idea of standalone VR headset though.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Max Maslov]

Is there any OSG apps with Oculus support?
And looking forward to supporting Samsung Gear VR.  8)

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=62814#62814





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Jan Ciger]

On Tue, Feb 17, 2015 at 11:21 AM, Björn Blissing bjorn.bliss...@vti.se wrote:
 * Direct mode works well, but sometimes you will have to perform a bit of an 
 odd procedure to get the Rift to work in Direct mode (this applies to all 
 Oculus Apps, not just the OpenSceneGraph integration): IF the LED on your 
 Oculus Rift unit flashes alternating blue/orange. Go to the Rift Display Mode 
 selector, select Extend desktop to the HMD and push apply. Then directly 
 select Direct HMD access from Apps and push apply again. This procedure may 
 have to be performed every time the Rift unit is reconnected to your computer.

Good work on the Oculus integration, Björn!

And yes, what you describe about the direct mode is pretty much par
for the course - I haven't seen an app (Unity, Unreal or whatever
based) that didn't have problems like that. It is the consequence of
their driver hackery.

Also another thing to keep in mind is that the GeForce cards support
only 2 simultaneous monitors, even if the card has more than two
physical connections. So if someone is using dual monitor setup for
development you will have to disable one before the Rift will even
want to start working. Otherwise Windows will see it present but it
won't be active, no matter what juggling is done.

Another trick we have found is that if you are using a DisplayPort to
HDMI converter (e.g. some laptops don't have HDMI but have DP
connectors), it may trip up the Rift drivers into thinking that the
Rift isn't connected - sometimes these adapters don't pass along the
display identification data correctly ...

It is pretty much black magic getting this thing working sometimes :(

J.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Robert Osfield]

Hi Björn,

Yesterday I tried out building the osgoculusviewer under Kubnutu 14.10,
against OSG-svn/trunk and ovr_sdk_linux_0.4.4 and found quite a few
warnings generated from OSG headers so I've cleaned these up where I can
and have just checked these fixes into svn/trunk.

I couldn't get everything to compile, as there was one error, and a number
of warnings for the OVR SDK, and one warning from a forward declare of
Image in oculushealthwarning.h.  I've attached the error/warnings.  Are the
OVR team responsive to fixes to their code?

Cheers,
Robert.
[ 12%] Building CXX object 
src/CMakeFiles/OsgOculus.dir/oculushealthwarning.cpp.o
In file included from /usr/include/c++/4.9/cstdint:35:0,
 from oculushealthwarning.cpp:10:
/usr/include/c++/4.9/bits/c++0x_warning.h:32:2: error: #error This file 
requires compiler and library support for the ISO C++ 2011 standard. This 
support is currently experimental, and must be enabled with the -std=c++11 or 
-std=gnu++11 compiler options.
 #error This file requires compiler and library support for the \
  ^
In file included from 
/home/robert/3rdParty/ovr_sdk_linux_0.4.4/LibOVR/Include/../Src/Kernel/OVR_Math.h:39:0,
 from 
/home/robert/3rdParty/ovr_sdk_linux_0.4.4/LibOVR/Include/OVR.h:31,
 from oculusdevice.h:12,
 from oculushealthwarning.cpp:18:
/home/robert/3rdParty/ovr_sdk_linux_0.4.4/LibOVR/Include/../Src/Kernel/OVR_Alg.h:847:31:
 warning: use of C++11 long long integer constant [-Wlong-long]
  ((vuint64_t(0x00FFULL))40) |
   ^
/home/robert/3rdParty/ovr_sdk_linux_0.4.4/LibOVR/Include/../Src/Kernel/OVR_Alg.h:848:31:
 warning: use of C++11 long long integer constant [-Wlong-long]
  ((vuint64_t(0xFF00ULL))24) |
   ^
/home/robert/3rdParty/ovr_sdk_linux_0.4.4/LibOVR/Include/../Src/Kernel/OVR_Alg.h:849:31:
 warning: use of C++11 long long integer constant [-Wlong-long]
  ((vuint64_t(0x00FFULL))8)  |
   ^
/home/robert/3rdParty/ovr_sdk_linux_0.4.4/LibOVR/Include/../Src/Kernel/OVR_Alg.h:850:31:
 warning: use of C++11 long long integer constant [-Wlong-long]
  ((vuint64_t(0xFF00ULL))8)  |
   ^
/home/robert/3rdParty/ovr_sdk_linux_0.4.4/LibOVR/Include/../Src/Kernel/OVR_Alg.h:851:31:
 warning: use of C++11 long long integer constant [-Wlong-long]
  ((vuint64_t(0x00FFULL))24) |
   ^
/home/robert/3rdParty/ovr_sdk_linux_0.4.4/LibOVR/Include/../Src/Kernel/OVR_Alg.h:852:31:
 warning: use of C++11 long long integer constant [-Wlong-long]
  ((vuint64_t(0xFF00ULL))40) |
   ^
In file included from /home/robert/OpenSceneGraph/include/osg/State:24:0,
 from /home/robert/OpenSceneGraph/include/osg/RenderInfo:17,
 from /home/robert/OpenSceneGraph/include/osg/Drawable:21,
 from /home/robert/OpenSceneGraph/include/osgText/Text:18,
 from 
/home/robert/OpenSceneGraph/include/osgViewer/ViewerEventHandlers:18,
 from oculushealthwarning.h:11,
 from oculushealthwarning.cpp:7:
/home/robert/OpenSceneGraph/include/osg/Timer:24:27: warning: ISO C++ 1998 does 
not support ‘long long’ [-Wlong-long]
 typedef unsigned long long Timer_t;
   ^
In file included from oculushealthwarning.cpp:7:0:
oculushealthwarning.h:14:12: warning: declaration ‘class osg::Image’ does not 
declare anything
 class osg::Image;
^
In file included from 
/home/robert/3rdParty/ovr_sdk_linux_0.4.4/LibOVR/Include/OVR.h:31:0,
 from oculusdevice.h:12,
 from oculushealthwarning.cpp:18:
/home/robert/3rdParty/ovr_sdk_linux_0.4.4/LibOVR/Include/../Src/Kernel/OVR_Math.h:230:2:
 warning: extra ‘;’ [-Wpedantic]
 };
  ^
/home/robert/3rdParty/ovr_sdk_linux_0.4.4/LibOVR/Include/../Src/Kernel/OVR_Math.h:238:2:
 warning: extra ‘;’ [-Wpedantic]
 };
  ^
In file included from 
/home/robert/3rdParty/ovr_sdk_linux_0.4.4/LibOVR/Include/OVR.h:33:0,
 from oculusdevice.h:12,
 from oculushealthwarning.cpp:18:
/home/robert/3rdParty/ovr_sdk_linux_0.4.4/LibOVR/Include/../Src/OVR_CAPI.h:220:45:
 warning: comma at end of enumerator list [-Wpedantic]
 ovrTrackingCap_Idle = 0x0100,
 ^
/home/robert/3rdParty/ovr_sdk_linux_0.4.4/LibOVR/Include/../Src/OVR_CAPI.h:239:58:
 warning: comma at end of enumerator list [-Wpedantic]
 ovrDistortionCap_ProfileNoTimewarpSpinWaits = 0x1,  /// Use when 
profiling with timewarp to remove false positives
  ^
src/CMakeFiles/OsgOculus.dir/build.make:126: recipe for target 

Re: [osg-users] Oculus+OSG

[Björn Blissing]

Hi,

Anders and I had a off-list discussion where we managed to solve these Windows 
issues. And the examples now performs on par with Oculus own examples.

Some bullet points which may help others:

* I have implemented a function to automatically disable desktop composition 
when running in extended mode. So now the user do not need to disable this 
manually. Sadly this function is not available in Windows 8 and later, due to 
limitations set by Microsoft. 

* Direct mode works well, but sometimes you will have to perform a bit of an 
odd procedure to get the Rift to work in Direct mode (this applies to all 
Oculus Apps, not just the OpenSceneGraph integration): IF the LED on your 
Oculus Rift unit flashes alternating blue/orange. Go to the Rift Display Mode 
selector, select Extend desktop to the HMD and push apply. Then directly 
select Direct HMD access from Apps and push apply again. This procedure may 
have to be performed every time the Rift unit is reconnected to your computer.


simon wrote:
 
 I also believe that oculusosgviewer uses it's own rendering code, and does
 not take advantage of Oculus' optimized code and/or timewarping.
 


OsgOculus uses pretty much identical code path regarding rendering as the 
Oculus examples. It also supports all standard Oculus features such as: direct 
mode, time warp, dynamic prediction and low-persistent display mode (last one 
only works with DK2 and direct mode rendering).

Best regards
Björn

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=62694#62694





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Björn Blissing]

Hi Robert,

I think I have been able to fix the error you saw and the warnings inside the 
code I can control.

Regarding the warnings from the Oculus SDK. I really don't know the best way of 
handling the reporting of errors in the SDK. 

Oculus have a support forum, but it is sadly a huge mess. There is a section 
for reporting errors with the SDK. But that section is filled with lots of 
hardware issues and angry teenage gamers who can't get the latest game to work 
with their new toy (even though the game lacks official support).

I have tried to report a couple of things during the years. Some have been 
picked up by the Oculus staff, others have just downed in the noise. 

Best regards,
Björn

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=62699#62699





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Björn Blissing]

Hi Anders et al,

Since I am the main author of the OsgOculusViewer I will try to answer some of 
your questions.

First of all, you are not the first user which seem to experience these types 
of problems. The judder you are seeing have been reported by many Oculus users 
for all kinds of applications (not just OsgOculusViewer) and can have different 
origins. Known issues are:

* Updates on another monitor may interfere with timing on the Rift and this can 
manifest as visible tearing in the Rift. This can be eliminated in Windows 7 by 
disabling Windows composition.
* Setting the Oculus Rift as secondary monitor (running at 75 Hz) and having 
the primary monitor is running at 60 Hz.
* On some AMD Radeon graphics cards, multi-sampling may cause judder or what 
appears to be rapid vibration as you move your head.

Try one of the following suggested solutions:
* Disable Windows composition
* Set the Oculus Rift as the primary screen.
* Overclocking the non-Rift primary display to 75 Hz.
* Setting the Oculus Rift to use 60Hz instead of 75Hz.

I have recently (9th of January) updated the library with support for 
DirectMode rendering, which may help you.

Regarding the fact that OsgOculusViewer uses its own rendering code and not the 
built in rendering code from Oculus. OsgOculusViewer uses pretty much the same 
rendering code as in the official OculusWorldDemo, although adapted to use OSG 
instead of pure OpenGL/DirectX. The reason for not using the Oculus SDK based 
rendering is that the SDK code path makes some rather broad assumptions about 
OpenGL initialization order and since OSG uses lazy initialization you will end 
up with quite a lot of catch 22 situations. I have tried to get it working, but 
as of today I am stuck with crashes deep inside graphics driver code or inside 
the Oculus SDK. The code is available at the sdk-rendering branch on github, 
if anyone wants to give it a try.

Best regards,
Björn

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=62652#62652





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Björn Blissing]

Hi again,

Just a follow up on my last post. I tried running OsgOculusViewer with  the 
following variations of settings:

* Extended Mode + Desktop Composition On = Serious Judder
* Extended Mode + Desktop Composition On + Single Threaded = Serious Judder

* Extended Mode + Desktop Composition Off = No Judder
* Extended Mode + Desktop Composition Off + Single Threaded = No Judder

* Direct Mode + Desktop Composition On = No Judder
* Direct Mode + Desktop Composition On + Single Threaded = No Judder

* Direct Mode + Desktop Composition Off = No Judder
* Direct Mode + Desktop Composition Off + Single Threaded = No Judder

So the conclusion is that IF you have to run with Extended Mode the solution 
seems to be to disable desktop composition in Windows.

I was unable to make the matching test using the OculusWorldDemo, since it 
opens on the wrong screen in extended mode when running in OpenGL mode (ie. 
with the flag: OculusWorldDemo.exe -r GL). 

Best regards
Björn

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=62653#62653





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Jan Ciger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello Anders,

I haven't touched this in a long while, but perhaps I could help you.

Which Rift and SDK version are you using? I am not sure the DK2 is
actually supported. I think Bjorn did some work on it later, but no
idea about the state of the code.

Could you time where is it spending most of the time? I suspect it is
going to be either the tracking or there is something wrong with the
shaders - are there any messages being printed out? Does it actually
display a meaningful scene, apart from the jumping?

If you are using a modern/recent SDK which has the binary runtime, you
may want to try to turn off your firewall - the runtime is talking to
the libOVR using a network socket and perhaps it is interfering.

J.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iD8DBQFU1zDcn11XseNj94gRAgoXAKC0mT76ZpWKi2Hyz3vhs5X0+7OnVACfYVXb
hRlrM2dfcEcySzEAe47Nch0=
=Zsrq
-END PGP SIGNATURE-
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Anders Backman]

It's a Dk2. Windows osg 3.2 64 bit.
Oculus sdk 0.4.4

I believe it is generally working. I get tracking, stereo just fine. The
difference is in picture stability. The sample apps from oculus are dead
stable, with very little latency. The osg oculus viewer with a very tiny
model on the other hand demonstrate a clear lag. Might all be lag, or some
additional artifact hard to tell.
 It is certainly not model complexity.

Might be some new extrapolation feature not enabled...

/Anders

On Sunday, February 8, 2015, Jan Ciger jan.ci...@gmail.com wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hello Anders,

 I haven't touched this in a long while, but perhaps I could help you.

 Which Rift and SDK version are you using? I am not sure the DK2 is
 actually supported. I think Bjorn did some work on it later, but no
 idea about the state of the code.

 Could you time where is it spending most of the time? I suspect it is
 going to be either the tracking or there is something wrong with the
 shaders - are there any messages being printed out? Does it actually
 display a meaningful scene, apart from the jumping?

 If you are using a modern/recent SDK which has the binary runtime, you
 may want to try to turn off your firewall - the runtime is talking to
 the libOVR using a network socket and perhaps it is interfering.

 J.
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iD8DBQFU1zDcn11XseNj94gRAgoXAKC0mT76ZpWKi2Hyz3vhs5X0+7OnVACfYVXb
 hRlrM2dfcEcySzEAe47Nch0=
 =Zsrq
 -END PGP SIGNATURE-
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org javascript:;
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org



-- 
__
Anders Backman, HPC2N
90187 Umeå University, Sweden
and...@cs.umu.se http://www.hpc2n.umu.se
Cell: +46-70-392 64 67
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Jan Ciger]

On Sun, Feb 8, 2015 at 5:17 PM,  si...@mungewell.org wrote:
 I also believe that oculusosgviewer uses it's own rendering code, and does
 not take advantage of Oculus' optimized code and/or timewarping.


AFAIK, you can do both, but integrating the Oculus rendering is a
fairly big PITA, because of how deep in the pipeline the code sits.

The timewarp feature will at best fool your viewer thinking that the
latency is less than a frame, nothing more. It has to usably work
without the timewarp as well.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[simon]

 Hi Anders,

 To get down latency for the osg viewer to run single threaded - this will
 reduce the latency by a frame.  Another thing you could do is use
 svn/trunk
 version of the OSG as this add a sync option that uses swap buffer sync
 that ensures the main loop doesn't get too far ahead of the swap buffers
 on
 the graphics card.

If building yourself, you might want to read:
http://forum.openscenegraph.org/viewtopic.php?t=14105

I found that OSG built with debug enabled, and was 3x slower than distro's.


I also believe that oculusosgviewer uses it's own rendering code, and does
not take advantage of Oculus' optimized code and/or timewarping.

Simon

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Robert Osfield]

Hi Anders,

To get down latency for the osg viewer to run single threaded - this will
reduce the latency by a frame.  Another thing you could do is use svn/trunk
version of the OSG as this add a sync option that uses swap buffer sync
that ensures the main loop doesn't get too far ahead of the swap buffers on
the graphics card.

Robert.

On 8 February 2015 at 10:17, Anders Backman ande...@cs.umu.se wrote:

 It's a Dk2. Windows osg 3.2 64 bit.
 Oculus sdk 0.4.4

 I believe it is generally working. I get tracking, stereo just fine. The
 difference is in picture stability. The sample apps from oculus are dead
 stable, with very little latency. The osg oculus viewer with a very tiny
 model on the other hand demonstrate a clear lag. Might all be lag, or some
 additional artifact hard to tell.
  It is certainly not model complexity.

 Might be some new extrapolation feature not enabled...

 /Anders

 On Sunday, February 8, 2015, Jan Ciger jan.ci...@gmail.com wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hello Anders,

 I haven't touched this in a long while, but perhaps I could help you.

 Which Rift and SDK version are you using? I am not sure the DK2 is
 actually supported. I think Bjorn did some work on it later, but no
 idea about the state of the code.

 Could you time where is it spending most of the time? I suspect it is
 going to be either the tracking or there is something wrong with the
 shaders - are there any messages being printed out? Does it actually
 display a meaningful scene, apart from the jumping?

 If you are using a modern/recent SDK which has the binary runtime, you
 may want to try to turn off your firewall - the runtime is talking to
 the libOVR using a network socket and perhaps it is interfering.

 J.
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iD8DBQFU1zDcn11XseNj94gRAgoXAKC0mT76ZpWKi2Hyz3vhs5X0+7OnVACfYVXb
 hRlrM2dfcEcySzEAe47Nch0=
 =Zsrq
 -END PGP SIGNATURE-
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org



 --
 __
 Anders Backman, HPC2N
 90187 Umeå University, Sweden
 and...@cs.umu.se http://www.hpc2n.umu.se
 Cell: +46-70-392 64 67

 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org