PCVR/Link Development

The idea is simply that the rift in my opinion should have a Blow Sensor shipped with it. That is to say a transducer/sensor of sorts that can detect rates of airflow from the users mouth. This would add relatively little cost to the development kit and offer developers a phenomenal array of ways to use it in games and applications. Below are a few example of the myriad of things that can be done. 1. Playing a woodwind, brass or other type of instrument (music lessons) or even applying it in a game like ocarina of time to play the ocarina. 2. Super Powers. Think of being mario and being able to spit fire or SuperMan and being able to create gusts of wind with your mouth, or be a dragon and breath fire, blow a forcefield bubble...etc3. picking up a dandelion and blowing the seeds and watching them scatter. 4. Blow smoke5. Blow out a candle, match or torch.6. Blow bubbles7. Blow spitballs8. Blow a blowdart9. Blow a pattern and use it for gestures.10. Be able to s

Is this actually official?http://betanews.com/2014/05/02/oculus-rift-launch-date-officially-confirmed-for-2015/I'd love to know a general range of ship date for company strategy project planning reasons. (Its hard to make a game with no clue of when a ship date will be.) I'm really excited if they pushed it off six months with the late shipping of the DK2s :)Thanks!-Matt

Tadaa... just to confirm: some OpenGL Oculus Rift rendering inside a wxGLCanvas. No real surprises here.@jherico: note that the vertical positioning of the image is correct here, opposed to GLFW.These are the handles I pass on to ovrHmd_ConfigureRendering:m_OpenGLContext->GetGLRC() // This is the OpenGL context (wxGLContext) that we store as a member in the canvas.(HWND) GetHandle()GetDC((HWND) GetHandle())So it takes the handles to the wxGLCanvas, which would be undecorated. Opposed to the handles to the window that we pass to GLFW, which is decorated. Maybe?Thanks,Daniel Dekkers

I've been following the advancements with stereo 360 video recording and been impressed with the progress that everyone is showing with developing realtime spatial capture. One limitation that I've seen of current stereo lens systems that are most commonly used is that the fixed focal point and lens convergence restricts the viewer to a fixed point in space. This creates two problems with re-creating the environment in VR. One problem is that because the convergence is fixed, the capture looks fine so long as the viewer observes the recording from the same angle that matches that of the camera used to record. This creates problems with true presence as the viewer in realtime VR will never remain perfectly stationary. The other problem is that it is very difficult to match multiple angles in one complete seamless stiched image. Partially because there are minuscule calibration variations between cameras as well as differing convergence between stereo pairs pointed in 90 degree increme

With the 0.2.x SDK I had my stereo rendering code working using the sample code from the docs to calculate the left and right projection offsets with code like this:float viewCenter = hmd.HScreenSize * 0.25f;float eyeProjectionShift = viewCenter - hmd.LensSeparationDistance*0.5f;float projectionCenterOffset = 4.0f * eyeProjectionShift / hmd.HScreenSize;// Projection matrix for the "center eye", which the left/right matrices are based on.Matrix4f projCenter = Matrix4f::PerspectiveRH(yfov, aspect, 0.3f, 1000.0f);Matrix4f projLeft = Matrix4f::Translation(projectionCenterOffset, 0, 0) * projCenter;Matrix4f projRight = Matrix4f::Translation(-projectionCenterOffset, 0, 0) * projCenter;Now I'm attempting to integrate the 0.3.1 SDK to use the SDK distortion rendering, but the examples in the docs seem to now be using the new C API and I can't figure out how to access the same information I used to get from the HMDInfo struct through this API. I see the ovrMatrix4f_Projection function being use

I'm getting the following compile error when building a project that includes the oculus SDK headers:Integer constant is too large for 'long' type in ../LibOVR/Include/../Src/Kernel/OVR_Alg.h line 812.I'm getting that error when building with GCC on Mac OSX with 32bit target. I don't get it when targeting 64bit, and I don't get it when targeting 32bit compiling with clang. So it is an error specific to using GCC with 32bit target.Any ideas?

I'm trying to use Oculus Rift with our existing OpenSG enviroment . OpenSG is a 3D engine based on OpenGL.I have created 2 differents FBO viewport, one for each eye, and i have rendered my scene in a single 1280x800 shared texture. (a red background with some planets moving around, just for testing purposes).I'm trying to apply OVR distortion but this is what i get:cacca.jpgThis is my how i set up the SDK: OculusVR->eyes[0].Eye = ovrEye_Left; OculusVR->eyes[1].Eye = ovrEye_Right; OculusVR->eyes[0].Fov = OculusVR->HMDDesc.DefaultEyeFov[0]; OculusVR->eyes[1].Fov = OculusVR->HMDDesc.DefaultEyeFov[1]; OculusVR->eyes[0].TextureSize = RenderTargetSize; OculusVR->eyes[1].TextureSize = RenderTargetSize; OculusVR->eyes[0].RenderViewport.Pos = Vector2i(0,0); OculusVR->eyes[0].RenderViewport.Size = Sizei(RenderTargetSize.w / 2, RenderTargetSize.h);

Hey there,I've never published anything on any platform, so when I think about publishing something for the Rift, it appears as a huge mountain to me, with steep cliffs to climb up.Would be really kind, if someone could just give me some hints on the rough roadmap, some words or places I can google. Or an overview of the process.My ideas are about simple but fun concepts involving a bit of multiplayer, so someone with better coding skills (all of you) might pull off in a week what I did in 2 months.So, would showing early prototypes invite copycats to get your ideas quicker to market (than yourself)? What do you think?Thanks,Mike

Is it for rendering to a standard screen ("one eye")? Or is it something involving possibly more than two eyes?

Any chance Vireio 2.0 may support this? I'm eager.

I'm wondering whether Oculus VR has plans to provide official cross-platform Java bindings in the SDK? Did they ever comment on this? And if so, will it be a JNI wrapper or even a native API?The current situation for integrating the Rift on the JVM is imho rather cumbersome. Thanks to the great efforts of other users here, we currently have a few options for JNI based wrappers and we even have an approach which natively reads the HID and reimplements parts of the official SDK. This is not bad in order to get it to work, but since there are many more possibilities to deviate from the recommended implementation standard, it's more likely to end up with an unpleasant experience (for instance when you have a bug in your reimplementation of sensor fusion etc). Furthermore any SDK update will cause a significant amount of work. Currently I'm really looking forward to the upcoming 0.3 SDK, but probably moving from 0.2 to 0.3 will be pretty tough for the JVM world. So it would be really great

For a while now I've been wondering about the effect of the C#/Mono/.NET or Java garbage collectors on VR games. Garbage collectors are well known to cause hitching and stuttering in games. For a long time it has common practice for C# and Java game developers to minimize their garbage creation with techniques like object pooling. I even went to all the trouble of pooling my objects in a 2D Java game I wrote a while back, because I read in several places that you should do this. But I never really knew if I was just wasting my time or not.Anyway, in VR it is more important than ever to avoid hitches and stutters so the user doesn't get sick. Yet we have Unity being used for a lot of VR projects, garbage collector and all.Does anyone know just how bad GCs are for the VR experience?

On roughly line 645:OVR_EXPORT void ovrHmd_ResetFrameTiming(ovrHmd hmd, unsigned int frameIndex, bool vsync);Should that "bool vsync" be "ovrBool vsync"?Thanks!

I did the anti screen door effect mod with two sheets Laminating Pouches .It removes the screen door effect completely but it is very blurry.It took me 10 minutes to finish this mod it is very easy.I took a Laminating Pouches in A3 size format .No need to cut something.It looks like you are watching through a 4k super blurry screen.

I have spent a few weekends organizing my notes, here should be everything you need to build a skeleton Oculus Rift project in Xcode-Start with a blank Cocoa appDrag LibOVR into Xcode Project, uncheck all “Add to Target”Linked Frameworks and Libraries:libovr.a (LibOVR/Lib/MacOS/Debug) IOKit.frameworkArchitecturesArchitectures : 64-bit Intel (x86_64)Apple LLVM 5.0 - Language - C++C++ Standard Library : libstdc++ (GNU C++ standard library) Enable C++ Exceptions : No Enable C++ Runtime Types : NoSearch PathsHeader Search Paths : LibOVR/Src, LibOVR/IncludeLibrary Search Paths : - Debug : LibOVR/Lib/MacOS/Debug - Release : LibOVR/Lib/MacOS/Release------Any classes which include OVR.h, and the classes which include THOSE classes, must be named *.mm, or must be marked as Objective-C++ source------for reference: here is this example’s folder location for how they reference the header/search paths------to check if everything got setup correctly, edit main.mm:#import <Cocoa/Cocoa.h>#includ

I run into a couple of issues getting started with the Oculus SDK v0.2.3 on Ubuntu 13.04 using a Radeon HD 7950. I created a quick start guide for Ubuntu 13.04 that details the steps required to get the SDK working:https://developer.oculus.com/wiki/Ubuntu_13.04The part that details how to configure the virtual screens in Ubuntu 13.04 requires the Catalyst Control Center and is therefor applicable to AMD GPUs only, but similar instructions will likely work on other hardware as well.

Hi,After a call to ovrHmd_EndFrame(), the vertex arrays in my own render loop no longer showed up.Took me another hour to find that glBindBuffer(GL_ARRAY_BUFFER, ...) kept its specific binding.This is now my code surrounding ovrHmd_EndFrame():glDisable(GL_CULL_FACE); // Oculus wants CW orientations, avoid the problem by turning of culling...glDisable(GL_DEPTH_TEST); // Nothing is drawn with depth test on...ovrHmd_EndFrame(l_Hmd);glBindBuffer(GL_ARRAY_BUFFER, 0); // Unbind GL_ARRAY_BUFFER for my own vertex arrays to work...glEnable(GL_CULL_FACE); // Turn back on...glEnable(GL_DEPTH_TEST); // Turn back on...glClearDepth(1); // Oculus set this to 0 (the near plane), return to normal...glUseProgramObjectARB(0); // Oculus shader is still active, turn it off...Does anyone have / know of some kind of OpenGL state snapshot functionality so that I can take a before / after "picture" and compare the two? Thanks,Daniel Dekkers

For some time I've been interested in creating a more immersive communications experience than something like a video call in Skype would allow - something that feels more like a face to face encounter.I was thinking of using a Kinect sensor with the open source Kinfu (http://pointclouds.org/documentation/tutorials/using_kinfu_large_scale.php) to create real-time texture mapped 3d models of people, then manipulating the models to, say, put people around a virtual table (or whatever else) that's displayed on a Rift. However, since all these people would be wearing Rifts, no one could see each other's eyes. Since eye contact is such an important part of communication, that wouldn't work very well. I was thinking about putting one or two very small cameras inside the rift to get facial images and try (perhaps with the help of some photos taken beforehand) to paste the facial images into the texture mapped model.Is there enough space or light inside the Rift for the cameras to work?I real

Due to some redesign work, the Stem system is now going to ship in October instead of July.https://www.kickstarter.com/projects/89577853/stem-system-the-best-way-to-interact-with-virtual/posts/827198Originally, Stem consisted of 3 parts: Stem sensors, Stem packs and Stem hand controllers. The Stem pack is the unit that you attach to body parts and contains the force feedback and battery. The sensor is the actual bit that does the tracking, and needs to be plugged into a pack or hand controller. The new design integrates the sensor into the pack and hand controller.That shouldn't affect most of us (I ordered the version with 2 hand controllers, 3 packs and 5 sensors), although the larger versions might have to change a bit (the $1000 version included 5 hand controllers, 5 packs and 5 sensors, 10 devices total but only 5 could have a sensor attached at once).The new design is looking pretty cool (there's pics on the kickstarter update page) and apparently the new design reduces some late

With the release of timewarping in the latest Windows 0.3.x SDK I figured I should dump a couple of paper's I've worked on regarding the technique. They're pretty theory-heavy, but there may be something of interest to other developers in there.https://www.cs.auckland.ac.nz/~epee004/archive/WarpQuality.pdfhttps://www.cs.auckland.ac.nz/~epee004/archive/HmdLatency.pdfThe methods discussed are slightly different to what's in the SDK but the core theory is the same. I'm happy to answer any questions people might have on the technique as well.

Perhaps this is straightforward, but:I'm wondering how the SDK-managed portions of the rendering pipeline (e.g., warping) are going to be handled by a service running in another process. Is there some way the contexts can be shared between processes?

Hey. Final Year Project is coming up and I have started incorporating my Hydras into the project. I thought they worked fine but as I used it more, it seems something is up. I already sent back for replacements in December as 1 was faulty but this seems like a new issue, and I'm not sure if it is hardware or softwareside.So basically the Hydras seem to work fine when near the base. Seems quite steady etc. Now they have a decently sized cable so I'm assuming it should be able to extend that distance. If i want to use the Hydras with my Rift for positional tracking I need some distance. However when I stand like 2-3 feet away from the base, it jitters unbearably. So if i have positional tracking it is unplayable.Also if I am upclose to the base, and I am using one Hydra to act as a gun, it allows me to move the gun really far away in the game which you shouldn't be able to do, so I do need some distance. Does this sound like an interference issue or a Hydra related issue? I probably wont

This image was leaked on Facebook. Not sure where it was taken but Virtuix have confirmed that it's an R&D project they've been working on with a university. Appears to allow full crouching. Not sure if this is being made specifically for the military but maybe it will become available to the public?Pretty cool eh? I'd love to see a video of this in action :)

Hi,I'm integrating OculusSDK.I'm now integrating only the "gamepad" (input) and not the rendering.Initialization is: ovr_Initialize(); ovrHmd l_Hmd = ovrHmd_Create(0); ovrHmdDesc l_HmdDesc ; ovrHmd_GetDesc(l_Hmd, &l_HmdDesc);That works fine and I get a seems-legal descriptor.Later I call: XINPUT_STATE xis; int l_rc = XInputGetState(0, &xis); if (l_rc == ERROR_SUCCESS ) Log("Controller connrected");But I always get l_rc==1167 and constant looks-like-garbage state.Could you help?

Hi,Has anyone figured out what the least amount of work is that should be done implementing OnSize() in a windowed environment (not fullscreen). The texture size shouldn't change, I would think, because that is based solely on the field of view (leaving aspect ratio out for the moment). But the ovrGLConfig struct, with cfg.OGL.Header.RTSize does. Do I have to call ovrHmd_ConfigureRendering(...) again?Thanks,Daniel