Ogre Forums

Cool, I've now had confirmation that the sample version 0.4 works correctly for rendering and tracking.
But it's cleanup code is breaking. That's hard to test because without the headset I can't fully set up all the objects, so I can't test how they are being cleaned up afterwards. I might need to hack the oculus sdk to make a fake headset available. Or just stare at code until I get inspiration.
Enough Oculus for today, got three other coding projects to do in the next 12 hours.

I'll get a code release ready soon (in a couple of days).

I'll be happy to help test this, but even as a kickstarter backer, I'm not likely to get my headset for a couple more weeks. This looks awesome!

Source release time.

Mercurial repository:
https://bitbucket.org/rajetic/ogreoculus
Binary using the same code:
https://bitbucket.org/rajetic/ogreoculu ... o1_v0.5.7z

It still needs work. Like docs, more comments, etc. But it's in working order and should be fairly easy to use.
The included demo is a simple ogre windows app. It includes a Visual Studio 2010 solution, but the oculus class code should be compiler independent.

Basic use for Oculus class:

• Add the ogreoculus.h and ogreoculus.cpp to your project.
• Include ogreoculus.h
• Add the following code to set everything up (after setting up ogre):

  Code: Select all

  Oculus oculus;
  oculus.setupOculus();
  oculus.setupOgre(sceneManager, window);

  (where sceneManager is your scene manager and window is the render window returned by creating ogre's root)
• In your game loop, you can update the ogre cameras to the oculus orientation using:

  Code: Select all

  oculus.update();

  Or you can manually do it (in case you have a hierarchy like a body and head):

  Code: Select all

  oculus.getCameraNode()->setOrientation(oculus.getOrientation());

• If you want to move around, use something like:

  Code: Select all

  oculus.getCameraNode()->translate(velocity);

  (getCameraNode returns a standard SceneNode that contains the two cameras used for stereo rendering)
• At the end, shut down using:

  Code: Select all

  oculus.shutDownOgre();
  oculus.shutDownOculus();

Build instructions for OgreOculusDemo1:

• You'll need an Ogresdk (with the OGRE_HOME environment variable set
• You'll also need the Oculus sdk. The demo is set to look for the sdk in the subdirectory OculusSDK in the parent of the demo's solution directory. You may need to change that in the include and library settings.
• Build and enjoy.

Kojack wrote:Source release time.

Some of the sweetest words in the english language.
Nice work Kojack.

Excellent Kojack!

This and other things motivates me a lot to get my game finish ASAP (certainly around the end of the year) so that I can port it to Occulus Rift, as I think it would be perfect match!

It was also a good excuse to get around to trying bitbucket, some of my students want to use it so I need a bit of practice.

What we really need now is a good looking scene using acceptably licensed art assets.
I'd love something like the NeoAxis village demo, or something like Dear Esther.
I can rip the look of the Unity demo, but I don't want to just copy it.

Damn, looks like I've broken the rendering again (hard to test without a headset). While cleaning up my code I broke part of it. But the fix is annoying.
Sigh. Using a listener class to set one float on a compositor instance just seems such a waste of code. Or I need to clone materials and give out two identical compositors.

Thanks for all your hard work Kojack, I can't wait to try it out in ORC. It'll probably be a long 4-6 weeks before it arrives! Should be fun

Thanks!
Ash

I've got some ideas for a future demo. But it may not be popular with everyone. I'm interested in the amount of motion sickness people are getting (not everyone, but a lot), so I want to see how far I can push vertigo in a vr world.

But for now I'll probably just stick in some paged geometry, skyx, hydrax, etc. That should be cool.

A tightrope over a gushing waterfall?

AshMcConnell wrote:A tightrope over a gushing waterfall?

Adding to the list...

Kojack wrote:I've got some ideas for a future demo. But it may not be popular with everyone. I'm interested in the amount of motion sickness people are getting (not everyone, but a lot), so I want to see how far I can push vertigo in a vr world.

I think if you have an environment that is user-paced, you won't have any issues with popularity. If the user can choose to just walk around peacefully if they want, or if they're curious about vertigo, thy can walk up to a cliff/across a tightrope/onto a roller coaster/etc. Leaving that out would be sad ^_^

No-o-o... Let them all suffer! Pure evil

Extreme vertigo, strobing lights and sudden jump scare shock images, while justin bieber music circles around you.

Kojack wrote:Extreme vertigo, strobing lights and sudden jump scare shock images, while justin bieber music circles around you.

It started off as a demo, it became A LIVING HELL

Kojack wrote:Extreme vertigo, strobing lights and sudden jump scare shock images, while justin bieber music circles around you.

If you make something scary first, it will create a big buzz.

Good point. I'll focus on the Justin Bieber music first.

Kojack wrote:Good point. I'll focus on the Justin Bieber music first.

I wasn't thinking about that kind of scary. It's highly unethical.

He gets all the chicks and you are jealous of him.
If you make a Bieber game, you'll get filthy rich. I'm sure of it.

saejox wrote:He gets all the chicks and you are jealous of him.

Indeed! But I'm not jealous of what he makes or his hair.

If you make a Bieber game, you'll get filthy rich. I'm sure of it.

Haha I'm sure that's true.

Found this yesterday, I wonder if it would work with ogre:
http://www.vireio.com/

as you can see here it already works with a lot of games:
http://www.mtbs3d.com/phpbb/viewtopic.php?f=141&t=15570

Hey Kojack you asked how much nausea etc we were experiencing with our rifts?

For me a fair amount at the moment but it is getting better, however some are much worse than others.
This vid: http://youtu.be/bxKQdckCigQ full screened nearly made my eyes bleed and me vomit all over the keyboard, I hear it is better with it linked to your own head motions but holy crap!

So if you want to hurt people with your demo's this is the kind of way to go imo.

One one got a Rift yet?

I am wondering about how much it stains the eyes.
Normally if i stand to my monitor less than 50cm or so my eyes starts burning, tears come out and vision gets blurry. Much worse if screen flashes frequently.
How does Rift feel after a few hours?

Well, since the rift lenses sit close enough that your eyelashes will probably touch them every time you blink, I'd guess it would be worse than sitting 50cm from a monitor.

I should get a new code update out to support the 0.2 sdk (it has yaw drift correction, which must be started manually). I'd like Razer Hydra support in there too, but I haven't got the positioning working as well as I'd like (the joysticks and buttons/triggers are easy, but my code for hand movement seems to have a flaw).
Oh, and I need to make a new shader. The oculus sdk now has a chromatic aberration shader (it compensates for the colour fringing that the lenses cause). It will be dx11 hlsl, so I'll need to convert it to SM2.0 CG (or SM3.0, this one might be too complicated for SM2.0).

Hehe, that wingsuit video is awesome.
(I don't have the oculus yet, but I can just diverge my eyes (like a magic eye book) and see the video in 3d. Not wide fov though)

Argh, WTF cg?

Here's a part of my new oculus distortion shader, ported from the official dx11 hlsl to sm2.0 cg: There's a bunch of stuff above that's different but not important to see. Ignore the *1.0000 bit, that will be explained soon.
So we have one render texture, the render of a single viewport (left or right eye). To correct the chromatic aberrations I need to read each colour channel from a different set of uv coords.
I've rendered the tcBlue, tcGreen and tcRed texture coords to the screen, they are all different.
But when I combine the channels like in the last line, I get a result which looks like all three channels use the same texture coords.

If I change the above code to have 1.00001 instead, it works correctly. Each channel is now scaled differently and overlap each other. Why is scaling the brightness of a colour channel by a non 1.0 value changing it's texture coordinates?

I bet if I renamed the file to hlsl and changed the program definition to hlsl it would work fine (I've had that in the past).

It's like it's caching the texture read and reusing it instead of doing three reads.

Weird stuff, but have you looked into the differences between the compiler output for both cases?