Oculus Rift Support
Monkey Forums/Monkey Programming/Oculus Rift Support
| ||
I'm just gonna leave this here:Strict
Import monkeyovr
Function Main:Int()
' init oculus
Ovr.Initialize()
' create a device
Local hmd := Ovr.CreateHmd(0)
If Not hmd Then
Print "Error creating Hmd."
Error("")
End
' start the sensor
hmd.StartSensor(ovrSensorCap_Orientation | ovrSensorCap_YawCorrection | ovrSensorCap_Position, 0)
Repeat
' get the sensor state
Local state := hmd.GetSensorState(Ovr.GetTimeInSeconds())
' get stuff from it!
If state Then
Print state.RecordedPoseOrientationX+","+state.RecordedPoseOrientationY
End
Forever
' destroy the device
hmd.Destroy()
' shutdown oculus
Ovr.Shutdown()
Return 0
EndCurrently it only reads from the sensors to get the orientation of the device. I'm working on the rest of the API. I have a DK1, so I know it works. :) Note: Obviously this only works for the C++ tool and GLFW targets. I've only tested Windows, not Mac nor Linux. |
| ||
| VERY COOL! |
| ||
| Awesome! |
| ||
| @Samah - Good timing on this, I know there are a few monkeycoders that have the DK1 and preordered DK2 so this may be the start of the elusive Monkey-X Rift demo, at least I have never found one. Are you planning to make this module and/or demo available any time soon? The obvious choice for many is Unity as there are plenty of examples out there already. I am wondering about the tooling required for Monkey-X Rift development. Here is a start, your monkeyovr module, mini3d, blender, with a GLFW target, is that sufficient to create a compelling Rift demo with Monkey-X? |
| ||
| Are you planning to make this module and/or demo available any time soon? So far all it does is initialise the device and read from the sensors. For now, I'm hoping to get it rendering with multiple cameras with just raw Mojo. Once I can prove it renders correctly (you need to enable fisheye distortions to correct the lens), I'll make a very rudimentary demo available. The obvious choice for many is Unity as there are plenty of examples out there already. This is the reason I wanted to look at Monkey bindings. Hopefully we can get some OR developers to look at Monkey instead of Unity/UDK! Here is a start, your monkeyovr module, mini3d, blender, with a GLFW target, is that sufficient to create a compelling Rift demo with Monkey-X? Once I have it rendering, I'll look at interfacing with miniB3D. I'd rather keep it a separate module rather than forking miniB3D, in case people want to just read the sensors for whatever reason. |
| ||
| Nice. Coincidentally, I've been looking for a VR-friendly 3D development solution this week. Monkey + miniB3d + this might fit the bill. Good luck getting it all inter-operating correctly... |
| ||
| Well done! Thanks a lot. |
| ||
| @Samah - Thanks, will be watching here for your progress! |
| ||
| Interested in this! Got my DK2 on Monday and it would be amazing to be able to use monkey instead of UE or Unity! I was pondering doing the bindings at some point (if I got a free moment) so glad someone is taking the bull by the horns. |
| ||
| @Skn3 - Not sure where you were headed with the 2D scene system with cameras stuff you were working on, but for kicks I suppose you could somehow use the Rift to control the camera? |
| ||
| hadn't though of that, would be cool! I guess Id have to figure out some way to add a depth multiplier that offsets according to each eye. It would have to be applied to all entities rendered. Or perhaps just rely on changing the z order in openGL. I tried out the virtual boy emulator and the wario game. It was a pretty neat concept and I think 2D games could still be viable in VR. |
| ||
| Ok, so here's the dilemma. LibOVR won't compile properly with mingw32, I have to use mingw-w64 and cross compile 32-bit. GLFW 2 won't compile properly with mingw-w64, I have to use mingw32. I therefore can't link these properly due to C/C++ sucking bollocks. I've already made a new GLFW target specifically for Oculus Rift, and in theory it should work... Possible solutions for desktop target: 1) Drive myself even more insane trying to get it to work. 2) Convert GLFW target to use GLFW 3 so that it will compile in mingw-w64. 3) Somehow try to compile GLFW with the Microsoft toolchain rather than mingw, since LibOVR has precompiled binaries for VC++. 4) Write a new desktop target using SDL or similar. My thoughts on these: 1) Call your local sanitarium and tell them to expect a visit from me very soon. 2) Maybe Mark could do this for us? Pretty please? 3) This might be the most promising option... maybe. 4) Would be brilliant since an SDL context can be used for both OpenGL and Direct3D. This is a challenge I wouldn't mind taking on eventually. stdcpp target works fine with mingw-w64 since it doesn't link with GLFW. Thoughts? |
| ||
| 2 or 4 and 3 if neither of those are viable. It would be good to get monkey brought uptodate with GLFW3. Drop XNA and focus on GLFW3. |
| ||
| 1) Call your local sanitarium and tell them to expect a visit from me very soon. On the other hand if you get it working you could just check into a virtual sanitarium :) or you could just go listen to some tunes at http://www.sanitarium.fm/archives/4589 I think 2D games could still be viable in VR. If the Rift catches on at a consumer level there would certainly be room for 2D games and it could be a niche that many developers might completely ignore. That would make it easier for indies to get some traction compared to going up against AAA content. |
| ||
| I think I might look at copying the glfw target and upgrading it to glfw3. If I can get it compiling correctly with mingw-w64, we can compile 64-bit desktop applications! :D Once that's all working, I'll copy paste again and make an Oculus Rift target. Don't expect it to be done overnight, but I currently have no broadband and this will help fill the void in my life. XD |
| ||
| Don't expect it to be done overnight, but I currently have no broadband and this will help fill the void in my life. XD A blessing in disguise! If the Rift catches on at a consumer level there would certainly be room for 2D games and it could be a niche that many developers might completely ignore. That would make it easier for indies to get some traction compared to going up against AAA content. Yeah definitely. In the 3 days I have had the DK2, one of the lasting impressions is simply the scale you can achieve, even a flat 2d wall of video looks immense! I have a 120" screen for normal tv watching (projector) but viewing the video in the helix demo, or the video billboard in techno lust demo seems more like 120 feet! Literally mind blowing! Imagine having some kind of 2D game where you implement this massive scale somehow! |
| ||
| I have a 120" screen for normal tv watching... Where do you find space for your furniture in that cinema complex? :) |
| ||
| Haha, mostly just huddle up in the corner and peer upwards. I was quite lucky when looking at houses to rent. The house has joined dining area and living area so we have a giant long wall to create a face melting screen! |
| ||
| Ok, GLFW3 target is 90% complete. Just some bugs to iron out to do with maintaining the update rate (they removed glfwSleep) and some false positives with key/mouse events. So far everything else works. Here's the gotcha: I can't get it compiling properly in 32-bit. So welcome to 64-bit land, everybody. |
| ||
| Wow fast going! Good stuff! Wonder if this is something Mark would consider? |
| ||
| Wow fast going! Good stuff! You can tell he hasn't got his full net access yet, cant ya! ;) Could push it to the github repo, if you wanted... or you could charge "one million dollars!" (little pinkie at the side of the mouth) |
| ||
| Ok, forking/cloning the github repo now, but it's taking forever... :( I'll throw the new target in there for you to peruse. Hopefully it should all work fine, but please rip it to pieces if you can! Also uploaded a glfw3 native file for Diddy. Edit: I can't clone for some reason (I blame Optus) so here's a puush. http://puu.sh/aBaCx/c33239ac1e.zip Edit 2: Get this: http://nuwen.net/mingw.html Edit 3: New topic here: http://www.monkey-x.com/Community/posts.php?topic=8835 |
| ||
| Ok, now that the GLFW3 target seems to be working OK, I'm back on this project. I'm hoping I can keep it mostly within its own module as a standalone graphics/input driver. In that case, the only change to the GLFW3 target would be to add the native library(ies) to the Makefile. I'm tossing up as to the best way to interface with Mojo though. My ideas so far: 1) A single call to OnRender, and the user is responsible for splitting the view down the middle of the screen, most likely using SetScissor (although that could be automatic). This would require (in theory) no changes to Mojo nor the target. 2) Two calls to OnRender each loop, one for each eye. The user could render the entire screen and Mojo would scale it down per eye. Since I can't change the method signature, the user would need to call something like GetCurrentEye() to find out which eye they are rendering. This might require hacks to the target. 3) Add OnRenderLeft and OnRenderRight. This would most likely require a change to Mojo and probably the target, which I'm hesitant to do. Also I don't want to add an OnRenderMiddle if humans evolve a third eye. I'm preferring option 1 at the moment, because it requires the least hacks and miniB3D can nicely handle multiple cameras with different viewports. Option 2 or 3 would still be OK with miniB3D, but you would have to enable/disable cameras every other frame and call RenderWorld twice per loop. Sensor state would most likely be read from a custom InputDevice. Thoughts? |
| ||
| I like option 1 the most, good work on getting this going, looking forward to trying my DK2 with Monkey :) |
| ||
| Sigh... Getting a memory access violation calling ovrHmd_ConfigureRendering. This isn't looking good. I have a feeling the LibOVR build I'm using isn't the latest, but effort getting the new one working with mingw. C++, I hate you. |
| ||
| Does anyone have experience building the GLFW target with Visual Studio? LibOVR comes with precompiled VS libraries and preconfigured VS projects to build it yourself. Does the XNA target use MinGW or VS? I know I compiled it at one point to test out Diddy's threading side-module, but I can't remember how. |
| ||
| Since XNA is a C# based framework I doubt it's using MinGW. |
   |