Ogre / Oculus Rift DK2 Progress

A place for users of OGRE to discuss ideas and experiences of utilitising OGRE in their games / demos / applications.
User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7157
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 534

Re: Ogre / Oculus Rift DK2 Progress

Post by Kojack »

The arabic city looks cool, might give that a shot.
duststorm wrote:And they would have to be converted to Ogre assets.
That's the easy part (I wrote the original ogre sketchup exporter afterall). :)

I really need to finish this thing, but I'm a little reluctant until the next ogre 2.0 release, in case bits have changed.
I tried running Unreal Engine 4 with the rift last night. The bare default project (grey room with a few white boxes) got only 38fps on my geforce gtx 680 when in rift mode and had bad judder.
User avatar
cybereality
Hobgoblin
Posts: 563
Joined: Wed Jul 12, 2006 5:40 pm
x 12

Re: Ogre / Oculus Rift DK2 Progress

Post by cybereality »

Kojack wrote:The bare default project (grey room with a few white boxes) got only 38fps on my geforce gtx 680 when in rift mode and had bad judder.
In most cases, judder just means slow performance. Since the Oculus SDK forces V-Sync at 75Hz, if you miss just one frame you will drop to 37.5fps (which is probably what you saw).

I guess the strange part is why would that happen on an empty scene. That I don't know. However, you can play with the ScreenPercentage to try to boost the speed (try "hmd sp 100").
tmason
Kobold
Posts: 39
Joined: Wed Feb 11, 2015 8:30 am
x 1

Re: Ogre / Oculus Rift DK2 Progress

Post by tmason »

Hello,

Is any of the referenced code or examples ready for a spin?

I'd love to try this out. I need to implement the Rift in an Ogre3D project I have now.

I am willing to work with any experimental code.

Thank you!
avengre
Halfling
Posts: 83
Joined: Fri Nov 11, 2005 6:27 am
Location: Lancaster, PA
x 1
Contact:

Re: Ogre / Oculus Rift DK2 Progress

Post by avengre »

Any updates on this Kojack?
ChristophLGDV
Gnoblar
Posts: 18
Joined: Mon Jun 01, 2015 3:09 pm

Re: Ogre / Oculus Rift DK2 Progress

Post by ChristophLGDV »

Hi,

I hope this thread is still active.

I need some help getting direct mode (Oculus SDK .5) working.

I have a working example that uses SDL2.

Extended mode works of course.

What do I have to do to get direct mode running.

Best Regareds
User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7157
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 534

Re: Ogre / Oculus Rift DK2 Progress

Post by Kojack »

I actually made some slight progress. I now have a black screen on the rift.
It's not supposed to be black (should be pink with a green statue in front), but it's not crashing, so that's a good thing I guess! :)

It seems that any time I make a bit of progress, the oculus sdk changes and I get set back (and then give up for a while). With the CV1 on the way (knowing the sdk could change again before 1.0) plus Vive and OSVR having sdks released, it's hard to keep up enthusiasm.

Evolution of the oculus sdk:
- dk1 early versions: simply render in stereo and use a compositor with a shader from the sdk docs. Rendering is done as a standard ogre full screen app, just pick the right monitor (the rift one).
- dk2 versions: things that were open source are now closed and hidden behind a network link, making debugging harder. Direct mode added that uses driver hacks to trick windows into not seeing a monitor. Still rendering the same way for extended mode (using the rift as a monitor). More of a push to "don't do it yourself, let us handle things".
- shader based distortion changed to mesh based distortion. Instead of rendering the post process using a single quad, we now need to use a mesh of around 8000+ tris. That's getting trickier to do (Ogre 2.1 has custom mesh compositors, but it seemed very complex to use).
- directx 9 dropped (where I do most of my ogre work)
- removal of extended mode and client rendering. No more simple rendering to a monitor or user distortion rendering. Now we render stereo to a texture and hand it to the oculus sdk. It does all the distortion rendering.
- latest sdk: we no longer give the oculus sdk the texture. Instead it wants to create the texture and give it to us to render into. It's the reverse of the previous sdk style. But ogre's texture management code is massive. Especially for DX11 and GL3 (which I'm not familiar with, I'm a dx9 coder), I'm not sure how much of ogre's code is needed. The texture manager doesn't support injecting textures from outside sources.

So my current plan is to leave ogre as is and try to trick the oculus sdk into using our textures instead of it's own. I think I'm missing setting a couple of member variables. Currently I'm giving ogre dx11 render textures to the oculus sdk and it's turning on and doing frame submits without errors, it's just showing black instead of the scene.

So no guarantees, but I'm slightly distracted enough to resume some hacky tries.
User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7157
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 534

Re: Ogre / Oculus Rift DK2 Progress

Post by Kojack »

Still no luck getting an ogre texture displayed on the rift.

ovr created textures render correctly (I filled them with a colour gradient).
ogre created textures have the same gradient added and save correctly, so they aren't blank. But the view is just black when I use them.
I checked the texture description structure for both, everything is the same. Except for the sharable flag, Ogre has no way of setting that. I hacked the dx11 renderer to set it, but it made no difference (as expected. The share flag is for sharing textures between devices, but the ovr sdk is using the same device as ogre).

The main difference is that the ovr code doesn't create a shader resource view. I tried hacking ogre to not create one, still just black. Passing the ogre shader resource view in didn't work either.

Neither directx 11 or the oculus sdk are giving errors, so I have no idea why it's just black.
arkeon
Goblin
Posts: 272
Joined: Fri Dec 04, 2009 6:02 pm
x 38

Re: Ogre / Oculus Rift DK2 Progress

Post by arkeon »

yes no luck :/
I didn't had the time to get a closer look into the latest SDK but I was just disapointed to see all this important changes every time.
OpenSpace 3D Project manager
http://www.openspace3d.com
User avatar
mkultra333
Gold Sponsor
Gold Sponsor
Posts: 1894
Joined: Sun Mar 08, 2009 5:25 am
x 114

Re: Ogre / Oculus Rift DK2 Progress

Post by mkultra333 »

I am following this thread with interest. I really wanted to add Oculus support to my game, though I hadn't got as far as getting the SDK. But they seem to making it harder and harder, to the point of it becoming almost impossible. Dropping DX9 really sucked.

I don't know the technical ins and outs, but it seems as if they're going out of their way to complicate something that should be really straightforward. Just allow devs to treat Oculus as if it was just another monitor (albeit with a groovy orientation reading system, and special distorting lenses). Game renders side by side stereo view, Occulus shows it. Why are they turning this into a nightmare?
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.
User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7157
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 534

Re: Ogre / Oculus Rift DK2 Progress

Post by Kojack »

mkultra333 wrote:Just allow devs to treat Oculus as if it was just another monitor
While that makes things easier for developers, it makes for a horrible experience for users, which is far more important.

Full screen issues, primary monitor issues, screen refresh rate issues, multi monitor issues, getting my desktop settings messed up every time I wanted to run a rift demo. With direct mode, the rift is hidden from windows. Start a game, it goes to the rift directly. Much nicer.

Now both AMD and Nvidia are supporting direct mode in their drivers, so hopefully every VR headset will move to this model.

I just wish they didn't move the code to closed source (I understand why, I'm just not happy about it), so I could actually debug the problem.
User avatar
mkultra333
Gold Sponsor
Gold Sponsor
Posts: 1894
Joined: Sun Mar 08, 2009 5:25 am
x 114

Re: Ogre / Oculus Rift DK2 Progress

Post by mkultra333 »

While that makes things easier for developers, it makes for a horrible experience for users, which is far more important.
But the thing is, by not even having that as a fall back option, the experience for users is no experience at all, since I can't add Rift support to my game.
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.
User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7157
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 534

Re: Ogre / Oculus Rift DK2 Progress

Post by Kojack »

Some slight progress.
I've got ogre dx11 rendering into the rift. It's icky though. Every frame I use the DX11 CopyResource method to copy the ogre render textures over the top of the oculus created textures.
I have no idea how badly that will affect performance. Seems fine so far.
This is a bit like what SCS are doing in Euro Truck Sim 2. It's a DX9 game. When Oculus dropped DX9 support, SCS added a DX11 surface and copied the DX9 output to it every frame, then gave that to the Oculus sdk. The result is one of the best VR games so far.

Although not everything is perfect. The textures are upside down and the right eye render target isn't clearing the back buffer (so hall of mirrors effect). That last one is odd, since I copied the compositor code from the Ogre 2.1 stereo rendering sample. (the right eye issue is not related to vr, it's failing in general ogre)

I'd still prefer to find a way to get the Oculus sdk to accept ogre textures. Then again, maybe the 0.9 sdk will bring it back (or break even more compatibility).

The OpenVR sdk (Valve's non steam sdk for the Vive) is working correctly on the oculus 0.8 runtimes, maybe I should look at that. They only have a single opengl demo, but it creates textures that somehow end up on the rift. Although the really documentation sucks.
User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7157
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 534

Re: Ogre / Oculus Rift DK2 Progress

Post by Kojack »

Ok, right eye issue is fixed. The stereo sample rendered both eyes into one texture, but I changed it to render into two (one per eye). Due to the mask values, it wasn't clearing the second one.

Upside down also fixed, it was a flag to the layer class (moved the 0,0 location on the texture).

So, that's better. But it's 7:36am and I haven't gone to bed yet. Sleep time. Maybe more tomorrow.
arkeon
Goblin
Posts: 272
Joined: Fri Dec 04, 2009 6:02 pm
x 38

Re: Ogre / Oculus Rift DK2 Progress

Post by arkeon »

Full screen issues, primary monitor issues, screen refresh rate issues, multi monitor issues, getting my desktop settings messed up every time I wanted to run a rift demo. With direct mode, the rift is hidden from windows. Start a game, it goes to the rift directly. Much nicer.
I got a ride of this in Ogre directx9 plugin by adding direcx heading refresh when needed. (oculus on / off) so it was working well until they remove the extended mode.
I also avoid the use of compositors for that.
I made a scene with a camera and the distortion mesh rendered in it. then I place the scene RTT for left and right eye on the meshes.

so when stereo is enabled the the main viewport camera just become the one from the stereo manager.
you can find the code here https://svn.scolring.org/trunk/scol/plu ... anager.cpp
Maybe you'll find some interest in it.

the method to render DX9 textures into a DX11 layer is also interesting, but I wonder how we could make this clean into ogre.
OpenSpace 3D Project manager
http://www.openspace3d.com
User avatar
mkultra333
Gold Sponsor
Gold Sponsor
Posts: 1894
Joined: Sun Mar 08, 2009 5:25 am
x 114

Re: Ogre / Oculus Rift DK2 Progress

Post by mkultra333 »

This is a bit like what SCS are doing in Euro Truck Sim 2. It's a DX9 game. When Oculus dropped DX9 support, SCS added a DX11 surface and copied the DX9 output to it every frame, then gave that to the Oculus sdk. The result is one of the best VR games so far.
That is very interesting. Sounds like this, and your method, might be a simple hack to get things working. Does this mean I could get a DX9 game working without having to update to DX11/Ogre1.10, and also have head tracking? Or would I miss out on the head tracking?
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.
User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7157
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 534

Re: Ogre / Oculus Rift DK2 Progress

Post by Kojack »

You'd get head tracking, that's the easiest part of all. (The sdk gives you one quaternion and one vector, already in the same coordinate system as ogre, the renderer doesn't matter)

You'd still need to have dx11 active in the program somehow. I don't know if ogre is going to like having two renderers active at once (one for the scene in dx9 and one just for a dx11 texture) so you'd have to do that part by hand (set up dx11 device, set up texture, etc). Then work out the fastest way to copy memory between two different render systems (CopyResource won't work, since it expects dx11 resources as both source and destination).
But in theory it would mean you could run any renderer on the oculus (dx8? software?) as long as the computer is capable of dx11 for the final distortion.

Or if you don't like dx11 you could use opengl for the oculus part too. The textures are going to be the same format in ram, just need a way to copy between them (maybe that's harder, I don't know. Never tried copying from dx9 to gl).

In my case, I've moved to Ogre 2.1 anyway, so lack of dx9 for oculus doesn't affect me. :)
User avatar
mkultra333
Gold Sponsor
Gold Sponsor
Posts: 1894
Joined: Sun Mar 08, 2009 5:25 am
x 114

Re: Ogre / Oculus Rift DK2 Progress

Post by mkultra333 »

How possible would it be to add a dx11 surface to Ogre 1.x with the dx9 render system running? Not necessarily in a "nice" or well integrated way, I wouldn't care if it was a dirty hack if it worked. I don't know much about the internals and limitations of DirectX or Ogre 1.x.

For instance, would it be difficult to have a fairly isolated part of the DX9 render system create a DX11 surface, quite separate from all the other render system parts, and then just cludge some brute-force memory copy from a standard DX9 surface onto the DX11 surface?

Or would this be incredibly difficult/impossible given either the limitations of DirectX or the Ogre 1.x render system?

(Actually, I guess I don't understand... I vaguely thought the DX11 surface was created by the O.R. and then you passed anything you wanted to it.)

Sorry if I'm basically asking the same question again, I just don't really know how these things work. This is the kind of "under the hood" mud I usually prefer not to think about and leave to Ogre.

Edit: Or another thought, have a separate program create a dx11 render system and texture, then somehow copy the screen from one program to the other, via a passed pointer or something.

Edit2: A quick search seems to indicate that DirectX 9ex allows you to somehow share or copy surfaces with DX11. Not saying I understand any of the details.
http://gamedev.stackexchange.com/questi ... eviceconte
https://msdn.microsoft.com/en-us/librar ... s.85).aspx

There are a few sporadic mentions of 9ex on the Ogre forums, again I don't understand the details. Looks like I need to change one or two minor things about surface creation to make it work.
http://www.ogre3d.org/forums/viewtopic.php?f=4&t=71366
http://www.ogre3d.org/forums/viewtopic.php?f=2&t=70093

Not meaning to derail the thread, just very interested in possibility of getting Oculus Rift support in Ogre 1.8 (or 1.x) dx9 render system. Do the above things make this plausible?
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.
User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7157
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 534

Re: Ogre / Oculus Rift DK2 Progress

Post by Kojack »

The DX9 render system couldn't create a dx11 surface.

All you should need to do is create a dx11 device (few lines of code) and give that to the oculus sdk (it then does the distortion rendering and texture creation for you). I don't know if things like swap chains are set up as well or if the sdk does all that for you.

For the actual copying, here's an msdn page that talks about sharing a texture between dx9 and dx11: https://msdn.microsoft.com/en-us/librar ... 85%29.aspx
There's a bunch of restrictions, but doesn't look too hard. The dx9 texture needs to be created in a special way, so you might need to hack ogre's source code a little.
User avatar
cybereality
Hobgoblin
Posts: 563
Joined: Wed Jul 12, 2006 5:40 pm
x 12

Re: Ogre / Oculus Rift DK2 Progress

Post by cybereality »

The developers that have made their Dx9 games work with recent Oculus runtimes (I think) were using Dx9Ex.

I don't actually know the exact code, but somehow with Dx9Ex you can share a surface with Dx11. However, you will still incur a performance penalty versus using Dx11 natively.
User avatar
mkultra333
Gold Sponsor
Gold Sponsor
Posts: 1894
Joined: Sun Mar 08, 2009 5:25 am
x 114

Re: Ogre / Oculus Rift DK2 Progress

Post by mkultra333 »

I'm wondering if the work needed to hack Oculus to use dx9 is less than the effort to convert my project to Ogre 1.10 dx11. Assuming I could get it to work in either case, that is, since there doesn't seem to be much success getting Ogre dx11 to work with the Rift anyway.

Such a pity. I find myself wondering, why do developers of these kinds of technologies always make them such an absolute pain to integrate? Yeah, I read the excuse for not giving a simple way above, but I don't really buy it. While it might be fine to have big studios making new games jump through 20 hoops to get ideal integration, I think it's stupid to not provide some fallback method that sacrifices some convenience in order to make basic integration simple.

As a long time 3D vision user, I know that end users are willing to sacrifice some convenience to have a good game experience. It's practically the norm to have to modify all kinds of system settings using special programs just to get a game to run half decent in 3D Vision.

As an example, 3D Vision could have been the simplest thing in the world. Let developers just add a side-by-side stereo mode. Instead they did this "clever" method using the z depth of vertex buffers... which is utterly useless in virtually all games. Way too late, they added a depth buffer method, but it's not great and still doesn't work half the time. Mostly, if you want to get 3D vision working, you have to code all your shaders especially for it, which no one can be bothered to do. I've done it in my own game, two different renderers, one for normal and one for 3D vision, and it's horribly painful maintaining both.

Sometimes I really want to slap clever people for being so stupid.
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.
User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7157
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 534

Re: Ogre / Oculus Rift DK2 Progress

Post by Kojack »

The CV1 with sdk 1.0 will start shipping to select developers with Q1 releases this week!
Maybe if they give me one I might resume work on an Ogre wrapper... :)

(I start my holidays tomorrow (until feb), so I might actually get time to work on coding again. Although I have so many work related projects to do too)
User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7157
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 534

Re: Ogre / Oculus Rift DK2 Progress

Post by Kojack »

Over on the oculus forum it's been confirmed that the oculus sdk does magic in the background, it's render textures are not normal render textures. We can't give ogre textures to it, we have to use theirs.
So three current options:
- modify ogre to accept rendering into externally created render targets (I really don't want to touch the internals of ogre's texture system. It's huge)
- do a texture to texture memory copy every frame from our render target to the oculus render target
- use the Steam OpenVR sdk instead. It does let us use our own texture and is oculus compatible, but I fear it's just doing the memory copy internally anyway (it just uses the oculus sdk too), and I've heard it's pretty crap at the moment.

I'll probably go with option 2. Although 3 will need to be done at some point, but I can't be bothered supporting the Vive until I actually own one (hint hint Valve!).
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: Ogre / Oculus Rift DK2 Progress

Post by dark_sylinc »

Do you have a link to that info? I'm curious about that magic.
User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7157
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 534

Re: Ogre / Oculus Rift DK2 Progress

Post by Kojack »

User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7157
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 534

Re: Ogre / Oculus Rift DK2 Progress

Post by Kojack »

Hmm, my suspicions might be right.
The reason using ogre's textures results in just black with no errors, no log messages, no crashes, is because it seems to never actually use them.

Here's how the oculus pipeline normally works:
- Create a texture set for each eye (the sdk uses a circle buffer of textures, every frame it advances to the next one for rendering. I have it set to 1 texture in the texture set).
- Call ovr_CreateSwapTextureSetD3D11 for each eye, giving it the texture descriptor (pixel format, etc) and a pointer to the texture set. It fills in the texture set pointers.
- Create a layer object (layers are used by the oculus compositor system).
- Assign the texture set of each eye to the layer object.
- When rendering, call ovr_SubmitFrame, giving it the layer object (well, an array of layer object pointers, but I only have one). It takes the textures in the texture sets, distorts them and sends them to the rift for display.

That works fine.
What I did was between the 2nd and 3rd steps. After creating the texture sets and using ovr_CreateSwapTextureSetD3D11 on them, I replaced the ID3D11Texture2D pointers and shader resource view pointers inside of each texture set with an ogre render texture pointer and shader resource view pointer. The ogre textures are therefore in the layer and should be used for rendering.

But I just tested it, it's not using the textures in the layer to render! It's still using the original ovr_CreateSwapTextureSetD3D11 textures. I did some pixel manipulation of the textures, the original oculus textures are the ones appearing on the rift. Modifying the textures that are actually passed to the ovr_SubmitFrame function does nothing. That's why I was only getting black, I wasn't changing the original textures after I overwrote their pointers.

Either the entire layer system is being ignored, or there's redundant storage somewhere in the texture set or layer. How is the pointer from ovr_CreateSwapTextureSetD3D11 getting into the submit call when I pass it a different pointer?
Back into the memory debugger I go...
Post Reply