Oculus Rift

    May 07 2013 | 2:15 pm
    anyone else here got an oculus rift? (I bet some folks do!)
    I've been playing with a sterescopic patch shared on the forums by Perry Hoberman: http://www.perryhoberman.com/page44/index.html
    and I've modified it for the oculus rift. It's still a work in progress but it includes a mostly finished jit.gl.pix shader to compensate for the rifts optics.
    no head tracking yet - managed to see the head tracker as a hi device but it wasn't spitting anything out. Haven't dug any further.
    Would love to connect with anyone else experimenting with this!

    • May 27 2013 | 1:46 am
      Hey ZEAL!
      I'm not currently experimenting with the Rift, but hope to be soon. I'm especially interested in the head tracking, so if anyone does get some data from the tracker, I'd love to hear about it!
    • Jul 09 2013 | 2:22 pm
      any progress?
    • Jul 19 2013 | 3:59 am
      currently occupied by other projects. Hope the patch is a head start for anyone who wants to investigate further.
    • Aug 06 2013 | 10:42 pm
      I have an oculus dev kit.
      Really just looking to get the head tracking data in msp.
      Anyone have any luck or somewhere they can point me?
    • Jan 14 2014 | 12:19 am
      Hi I just get the kit today and would like to play with it a little bit using Jitter did you get any progress with the head tracking ?
    • Jan 15 2014 | 11:42 pm
      Nope, haven't dug any further. Only a start to stereoscopic rendering and display.
    • Jan 23 2014 | 6:34 am
      It's been over a week, so quick check if anyone made progress on head tracking since the last post. If not, I will take a decent stab at it over the next short while, will post a patch and instructions here if I manage to get it.
      I have a good track record, got Kinect and recently Move data coming into Max (Win only for now, with ports planned in the future to Mac OS).
      Thanks to Zeal for the stereoscopic starting point. We have a really fun project planned that anyone can try if they get all the same hardware we'll be using.
    • Feb 04 2014 | 10:46 pm
      Just adding an update, the work is not all done yet, but I am confident I will be able to share a small utility to help the head tracking data to get into Max. Using Zeal's shared patch as a test, we will be able to see that Rift head tracking data will be able to drive the rotations about XYZ axes via an OSC stream hacked onto the Rift SDK's SensorBoxTest.
      For C# hacks I tended towards the Ventuz.OSC.dll for simplicity, but in this case I will be trying out this oscpack utility: http://www.rossbencina.com/code/oscpack
      I don't see any more obstacles in the way of getting this, just a matter of time. Since I have a project to get this working for, it's safe to expect that I will share the utility along with a modified version of Zeal's patch showing it all working together.
      Can anyone volunteer to help me test that I don't accidentally release it in a way where it actually only works on my machine?
      And sorry that this will be a bit of a hack, the reason being I would rather take my time integrating this into a larger project I am doing called "GestureLab", that will be a central interfacing application for HCI devices (Wiimote, Kinect, PS Move, Rift, etc.) that will have Max in mind as its initial output destination, but could go on to support other output destinations as well eventually (music applications, Unity, etc.)
    • Feb 05 2014 | 12:17 am
      I can help test. sounds great. you can get me at bob(at)zealousy(dot)com.
    • Feb 09 2014 | 10:37 am
      Thanks! Looks like I will definitely need a tiny bit of help with the tail end of this, but maybe I can send you what I have so far and we can probably work out the rest.
      I have the option of sending quaternions or converted euler angles into Max, which is still a step away from the nice degree-based rotatexyz option your patch defaults to (though I notice other options such as quat which look promising).
      The trick here is to get the data where it needs to go with the minimum number of conversions so as to prevent loss of precision. (for example, notice the note for quat2euler object here: http://www.maxobjects.com/?v=libraries&id_library=111 , which goes as far back as SIGGRAPH 1985, see here, where he warns the same: http://www.cs.ucr.edu/~vbz/resources/quatut.pdf )
      I am a CS animation student at the moment, so I hesitate to claim to know the best course of action.
      Shall I send you what I have so far? (also, do you have a VS2010 environment already set up by chance?)
    • Feb 09 2014 | 11:00 am
      Sounds good. shoot me what you've got. Don't have VS2010 set up right now but need to get it going for other max external work anyway so yes, send me source as well.
      Just got one of these little fellas - http://ovrvision.com/ - so I'm keen to get back into some rift experimentation.
    • Feb 09 2014 | 11:09 am
      Should have held out a little longer before my last message - success! I have managed to pipe the quaternion data directly without any conversions.
      I'll send it all over momentarily, and cool, I didn't know there were 3rd party accessories for the Rift already!
    • Feb 17 2014 | 8:34 pm
      Hi Oculo-Maxists,
      I'm also interested in helping out if you need more hands. I'm on a Mac set up if that still matters. That ovr vision business is pretty rad, btw.
      I'm at tennie[dot]here[at]gmail.
      Let me know what I can do to help.
    • Apr 02 2014 | 9:06 pm
      Hey mattt. Do you have Bootcamp set up on your Mac?
      Do you have a Kinect by chance? Either way, we are trying to work on a slight bit of overlap on the far left/right edges of the displays for Rift alone.
      With Kinect involved I'm also working on a slightly trickier problem.
    • Apr 15 2014 | 3:35 pm
      I am a student in interactive visual arts and I am working on different projects using the Oculus Rift, and I would like to be able to implement its usage in Max / Msp. The only problem is I have no idea how to get the head tracking data inside Max.
      If anyone has some progress on how to get the head tracking data in Max / Msp, please, send me a message or share your patch here. It seems like the only thread about that subject anywhere as far as I know.
      You can reach me at guillaumebou (at) gmail (dot) com
      Thank you
    • Apr 25 2014 | 8:00 am
      I am thinking of buying the rift, but only if it can work in max with full featureset. I am hoping someone will make this possible... pretty please? This is like the future, right?
    • May 29 2014 | 4:49 pm
      Hello Guys, I have no idea If this topic is still being followed..
      One of our clients asked us If it was possible to control some phisical
      objects with oculus rift… we came out with this idea:
      in unity ( our programmer is very comfortable with it ) we developed a
      udp client that dumps the oculus XYZ, this was developed today for mac
      Get the bridge here:
      compiled for osx X86 and working on osx 10.8.5 on powerbook
      first box ip , second box port then save… the default values are
      we did just a small test and the values get dump with this code:
      ( I remind u this is just a small test, very very beta, not official release or anything, just a work around
      that works for our challenge… )
      "boxes" : [ {
      "box" : {
      "maxclass" : "newobj",
      "text" : "mxj net.udp.recv @port 8051",
      "fontsize" : 12.0,
      "numinlets" : 1,
      "patching_rect" : [ 291.0, 134.0, 165.0, 20.0 ],
      "id" : "obj-4",
      "numoutlets" : 2,
      "outlettype" : [ "", "" ],
      "fontname" : "Arial"
      , {
      "box" : {
      "maxclass" : "newobj",
      "text" : "print",
      "fontsize" : 12.0,
      "numinlets" : 1,
      "patching_rect" : [ 297.0, 184.0, 34.0, 20.0 ],
      "id" : "obj-2",
      "numoutlets" : 0,
      "fontname" : "Arial"
      "lines" : [ {
      "patchline" : {
      "source" : [ "obj-4", 0 ],
      "destination" : [ "obj-2", 0 ],
      "hidden" : 0,
      "disabled" : 0
      "appversion" : {
      "major" : 6,
      "minor" : 1,
      "revision" : 6,
      "architecture" : "x86"
      Have Fun
    • May 30 2014 | 6:15 am
      Hi all,
      I've been working on an oculus max object over the last couple of days, and seems to be working well. I wondered if I could reach out to you Rift owners to get some feedback, especially about the rendering distortion (and thanks to Bob ZEAL (and Perry Hoberman) for inspiration on how to do the Jitter patching for that). The OVR SDK documentation is pretty obscure, so there was some guesswork involved. Currently I only have it built for OSX, but it should be possible to build on Windows.
      Binary attached, code here:
    • May 30 2014 | 6:27 am
      I should add that I was pleasantly surprised to get 60fps on my macbook pro with mediocre integrated Radeon 6490M GPU, though the scene is fairly simple. It's not easy to do complex scenes for the Rift because of the multi-pass rendering. (Plus some effects that work well in 2D don't translate well to stereoscopic display, e.g. many screen-based effects). But I think there are still some improvements that could be made to the rendering pass / distortion stuff in the max patch, which might speed it up a bit more.
    • Jun 02 2014 | 7:10 pm
      Updated to LibOVR version 0.3.2, which resolved most of the ambiguities, and now uses the faster mesh-based rendering, and implements chromatic aberration correction:
    • Jun 03 2014 | 11:13 am
      This works quite well on my mac pro
      the only thing I can't get working is the orientation
      does it work ?
      Amazing Job u got here…
    • Jun 03 2014 | 12:52 pm
      Orientation works, though I haven't gone to town with the prediction/timewarp stuff... I'm not sure if that's going to be possible in Jitter.
      Just built for Win32 too, also working. I'm testing with the DK1 headset, is that what you are using?
    • Jun 03 2014 | 1:55 pm
      I am sorry , by bad, I had a problem with the usb cable, now everything is working
      very well… I'm gonna connect a servo so I can control it with the headset…
      Amazing work u done here
    • Jun 11 2014 | 7:21 am
      For anyone still reading, I've moved this object to it's own repository here:
    • Jun 25 2014 | 11:05 am
      Great work!!! Thx for sharing.
    • Aug 26 2014 | 7:24 pm
      Fantastic work! Any plans to support dk2 in this object?
    • Aug 26 2014 | 8:35 pm
      Yes of course, as soon as my DK2 arrives, hopefully by October. I can try to port sooner, but of course I can't test it... do you have a DK2?
    • Aug 26 2014 | 8:50 pm
      Yes of course, as soon as my DK2 arrives, hopefully by October.
      The SDK that supports the DK2 is currently only in beta. It also depends on a global service running in the background, which currently means users would need the SDK installed. I guess there'll probably be a separate runtime installer available once it gets out of beta.
    • Aug 26 2014 | 11:27 pm
      My DK2 arrived two days ago. Would be happy to help with testing.
      I installed the latest runtime and it did install the global background service on its own, without the SDK. Mountain Lion or higher is now required.
    • Sep 10 2014 | 5:32 pm
      Today I got access to a DK2, so I'll be updating the https://github.com/grrrwaaa/max_oculus project now :-)
    • Sep 11 2014 | 4:16 am
      Well, I managed to get the new SDK working with position tracking, but the performance is disappointing. Might be something I've done wrong so I won't upload yet, but on a GTX 780 (Windows 7, Nvidia driver 335.23) I was only getting ~40fps with the oculus full screen and a minimal scene.
      Obviously the DK2 has twice resolution, but with the DK1 I had consistent 60fps even with highly complex scenes, and multiple additional displays. I can't believe that the resolution alone is to blame; I've probably made some silly mistake somewhere; will keep digging to see if I can figure it out.
    • Sep 11 2014 | 7:59 am
      Thanks for the update, and for your work on this. I look forward to hearing what you figure out -- I have heard that there are issues with using extended desktop mode with dk2. On my Mac it will only work in mirrored mode using the supplied Unity demo.
    • Sep 25 2014 | 7:43 pm
      I have a dk2 (not dk1) does this patch work with dk2 yet? I cant get the patch to recognise the dk2.
    • Sep 26 2014 | 12:17 am
      I've been swamped with other work and will be for a couple of weeks more, but will be looking at it again after that. What I was seeing was very poor performance on a pretty high-end Windows machine + GPU. I may need to try the non-extended desktop mode for Windows, but this will break compatibility with Mac; need more time to experiment. OTOH it might be necessary to change how it works for the time warp stuff to be usable anyway.
      FWIW the updated code is up on github though (in the sdk 0.4.2 branch), but no binaries yet.
    • Sep 26 2014 | 3:06 am
      I'd be happy to take a look, now that I have my DK2 Graham. I should really have posted the DK1 code I had at the time in here, but frankly it was everything I could do to just complete my animation project and move on, the DK1 really made me dizzy and a little nauseous every time I used it.
      At least I will have both your codebase and my own to work from, so maybe I can get some insight as to where the bottleneck is that's preventing 60 FPS.
      Also remembering to check the Notify Me checkbox in case I forget to log in to the forum for months at a time again ;)
    • Oct 09 2014 | 10:23 pm
      Here is a quick update:
      I just received my VR Developer Mount for the Leap Motion, and affixed it to my DK2. I am going to be working on a project for the next little while that combines the usage of these two devices with a Kinect for Windows (v2) in an avateering context.
      I'll try and set up some kind of a blog to show progress, so I will post a link once I've gotten far enough to be able to show something.
      I did already have the Kinect and Rift working together in Jitter on a previous project, but there were plenty of issues remaining to work around. Hopefully it will be possible to get a really nice stereoscopic image via the DK2, and be able to toggle between Rift and Kinect-based positional head-tracking. I will try to complete a scene graph that has toggles like this - i.e. another one to toggle between Kinect and Leap Motion for driving skeletal nodes in the hand.
    • Oct 09 2014 | 11:38 pm
      I have Max/Msp/Jitter/Gen, Rift DK2, Leap Motion (+ vr developer mount), Kinect, a Mac and a Windows computer (spec'd highly for the dk2 and beyond).
      Count me in for testing out DK2 + max integration.
    • Oct 10 2014 | 4:57 am
      Ditto. I did a project a couple of months pairing a couple of kinects (not v2) with a Rift (DK1) and using an Aruco marker for tracking, which worked pretty well but not perfectly. As well as the Rift external I have Kinect, Aruco and some OpenCV & PCL externals in development, but not fully stable yet. Planning to open source these later in the year (when my schedule relaxes a bit) and would be very happy to co-develop if anyone is interested.
    • Oct 13 2014 | 7:47 pm
      DK2 max 6.1.8 on osx 10.8.5.
      Thanks Graham the perspective correction looks amazing. No luck with the head tracking yet though. I can run Tuscany Demo and it works with that. I also installed Latest beta from OculusVr. Does any one have it working or whatsup ? When I go to configure it looks like it finds the headset but not grabbing rotation values. Attached is what prints from max when I click configure message.
    • Oct 13 2014 | 7:56 pm
      Good to know - In the spring we had head tracking working but perspective correction was a bit broken.
      I know exactly what is needed to implement head tracking (should still be there in my old modification of the cube rotation demo) so I will try and submit a pull request with the code.
    • Oct 22 2014 | 5:36 pm
      Does anyone have the DK2 working with MAX? I'd love to try it out!
    • Oct 23 2014 | 4:39 am
      Having the Kinect 2 and DK2 working in Max has me very excited to get my hands dirty in max again! Thanks for all the info so far.
    • Oct 23 2014 | 6:03 am
      Received my DK2 finally, but will be tied up with moving country for the next few weeks, and won't have time to get back to the oculus external until probably mid-November. Will post as soon as I do.
      @KCOUL, did you make any progress?
    • Nov 06 2014 | 11:20 am
      For those who can't wait (like me) I've got Graham's object working for DK2 and SDK 0.4 - many thanks to Graham for sharing the code. The Mac binary can be downloaded here. It works on Mavericks with DK2, but not tested on anything else - use at own risk. The help patch demo runs at ~34FPS here on my 2.3 GHz i7 MBP with GT650 1GB. I need to tidy up my edits to the source code, but then happy to share.
      I'm also using this with Leap (V2 SDK), Kinect etc. I'm getting around 63 FPS max with animation of Leap data - using automatic mode to work with the Oculus, jit.gl.multiple + jit.gl.gridshape to animate the finger joints and tips, connecting lines using jit.gl.sketch, screenshot attached (fullscreen it on the Oculus display to view in stereo). Any tips to further optimise GL scenes welcome...
      ps if you're interested in what I'm doing with this stuff, see my occasionally updated blog at www.musigui.com.
    • Dec 02 2014 | 8:17 am
      First of all thank you guys! Both versions of the object work in max6. In max7 one "eye" is darkened, though making it unusable. So I will keep working with it in max6. But thought you should know, also does anyone have any idea why? Here is a screenshot...
    • Dec 02 2014 | 8:21 am
      Hi Chris,
      The reason for this is likely due to the DK2 rendering in portrait rather than landscape. I am working on a new version as well, so hopefully I will have something to share soon.
    • Dec 02 2014 | 11:47 am
      I get the same problem here. It seems to be an issue with capturing to texture with the 2 cameras in the same world, which is done in the oculus_render sub-patch - which ever jit.gl.camera is instantiated first seems to render correctly, and the second appears darkened. Or if capture to texture is turned off on one camera, the other appears correctly. I've not explored further yet, but at first glance this seems to me like a Max 7 OpenGL bug.
    • Dec 02 2014 | 2:06 pm
      Have made a test patch which demonstrates this is a rendering problem in Max 7. Have reported it to cycling 74. Not found a workaround at this point.
    • Dec 03 2014 | 6:53 pm
      Ah this explanation makes sense - it could be a combination of both things - the OpenGL interface in Max 7 didn't have a case to deal with unusual resolutions like DK2's where the "screen" is in portrait orientation. If the eye that's dark is the one that's higher in the orientation, this would make sense. Also, if someone had a monitor set to portrait orientation they could repro with, then this would be the real reason for sure.
      Either way, I guess we will have to wait for a fix for Max 7. At least Max 6 works in the meantime.
      I am still working on my patch, which I will try to find optimizations for to get the frame rate a bit higher.
    • Dec 04 2014 | 11:32 pm
      That indeed illustrates the problem, and to confirm it has not been fixed in max 7.0.1. I wonder if it happens in windows? I wonder if there is a small chance it could be related to the much poorer performance of mac vs. pc?
    • Dec 05 2014 | 7:38 pm
      I doubt the portrait orientation is the issue, but I've also asked to see what might be going wrong. Hopefully something with my patch, but I'm suspecting some OpenGL state is leaking, or maybe the depth buffer. If you really need to use Max 7, one workaround could be to use different nodes for each eye (but that implies a lot of ugly patching/scripting...)
      BTW I have time again (finally) to work on the oculus object. RP, would you mind sending me whatever changes you made (ideally as a pull request on github, or just the individual edits/edited files if not)? Thanks!
    • Dec 07 2014 | 3:38 pm
      Just to let you know this will be fixed in the next update (thanks to Rob Ramirez!)
    • Dec 09 2014 | 1:52 pm
      Great news that it will be fixed in the next update!
      I've attached the edited source file here - all changes should be commented (labelled *RP* to locate easily).
      (Here I also had to change at least one MacOS framework in the project due to compiling on Mavericks/Xcode 6).
    • Dec 18 2014 | 10:00 pm
      That is great news! How is the update coming? I'm getting more and more dependent on max7 everyday.
    • Dec 21 2014 | 8:54 am
      Hi all,
      I've forked the project and updated it to the latest 0.4.4 SDK, and also applied RP's changes. I've just submitted a pull request for these changes. I just realized though - the original repo had only the single LibOVR directory, which I assumed was the Mac SDK. So, my pull request included the Mac version of the SDK.
      Perhaps in a 2nd pull request, I could re-link the Visual Studio solution on the Windows side to the Windows SDK, that could sit side by side with the Mac SDK? I can't immediately see how to do it though - the way the dependencies are represented in Visual Studio is part of a giant folder of External Dependencies with no apparent separation of the LibOVR folder - when I swapped in the new SDK on the Windows side, it just seems to reconnect to the updated files.
      Christopher - Max 7 compatibility will need to come from the Cycling '74 side of things, not us. Hopefully the bug will be fixed in Max 7.0.2!
      On the Mac side, there were some issues with the latest SDK, I had to remove some private files (OVR_OSX_FocusObserver and OVR_OSX_FocusReader) that were added for some reason, and in CAPI_GLE_GL.h I had to comment out as follows:
      //#if defined(__gltypes_h_)
      // #error gltypes.h should be included after this, not before.
      Finally, I had to replace
      typedef ptrdiff_t GLintptr;
      typedef ptrdiff_t GLsizeiptr;
      typedef intptr_t GLintptr;
      typedef intptr_t GLsizeiptr;
      But after this it seems to compile.
      On the Windows side, I've updated the Windows project files to be compatible with VS2013, but should probably leave those changes out of the repo as the repo should really only contain either the Mac or Windows SDK. Since it seems like it was the Mac SDK that was there before, people building on Windows can just overwrite the LibOVR folder and build the .lib files. Here's a good trick for getting around linker errors:
      This only helped me build in debug mode - on two machines, I can't seem to get around some linker errors in Release mode. Not sure if it'll be a big issue, will wait to see how high the FPS is.
    • Jan 13 2015 | 1:55 am
      I'm a little lost with all the various posts and forks and what not.
      Id like to use the oculus external in Max 6 on Windows 7 (32 or 64bit).
      Can someone give me a prod in the right direction?
    • Jan 13 2015 | 2:19 am
      APS502: here's a recap from my understanding:
      I've just helped to update the code to be compatible with latest LibOVR, but noticed that the code structure makes it hard to maintain both Mac and Win against their respective Oculus SDKs unless another commit separates out the Mac and Win LibOVR directories (did there use to be only a single SDK for Mac and Win?).
      You don't have to wait - jus download from Graham's repo and then download the Win Rift SDK, delete the LibOVR folder from the codebase's folder, drop in the one from the Win SDK, and fix whatever's broken in Visual Studio.
      If you'd rather wait to have this all done, I can probably add another pull request to map the VS solution to a parallel folder for the Win LibOVR folder and then you could just download that and it would probably work OOB.
      Keep in mind that to totally sync with the project you'll have to be using the same year of Visual Studio. I was planning to build against VS2013 but if anyone prefers VS2012...!
    • Jan 13 2015 | 2:29 am
      KCOUL As it happens I'm using VS 2012 so that would be preferred.
      I think i'll wait as that sounds a bit beyond me at this point!
      Is it not better to make it for the oldest VS as the newer versions will be able to convert or is this a naive assumption on my part?