Oculus Rift

    May 07 2013 | 2:15 pm
    Heya, 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?
      Thanks, Brandon
    • 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. Cheers,
    • 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.
    • 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: https://github.com/grrrwaaa/max_oculus
    • 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. //#endif
      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: https://forums.oculus.com/viewtopic.php?f=17&t=11838
      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?
    • Jan 19 2015 | 5:32 pm
      any news with win mxe?
    • Jan 19 2015 | 5:37 pm
      You can build the mxe easily by following the steps I had provided.
      APS502: its only a matter of switching the build tools in the project properties and a few other things. Its good practice to be acquainted with such settings.
      To reiterate:
      On Windows: Download Git code. Download Oculus Win SDK. Replace LibOVR folder. Adjust build settings in project properties.
      We will need to wait for Grahams decision on whether we can set up his repo to be compatible on Mac and Win OOB.
    • Jan 21 2015 | 10:40 pm
      I'm working on it. Today updated to 0.4.4 SDK (ironically still in the 0.4.2 branch...) and tried things out on mac; builds & runs fine after a couple of small tweaks. Shouldn't be a problem to merge with windows.
      That said, on the mac there isn't an easy way to rotate the displays, so the rendering sub patch needs to be modified (it's a simple fix of adding @rotatexyz 0 0 90 to both the meshes). Also confirmed that the rendering is working fine again in Max 7 development head. Still a sickening ~30fps on my laptop, and even more laggy tracking, but hey -- don't use DK2 on a macbook...
      For Windows I'd really like to have a go at rendering direct to rift, since that seems to be the recommended way going forward (and sounds like that's what they plan for OSX too). The main task is sharing an OpenGL texture or two with the Rift display, and being careful about the threads; I think that should be possible from Jitter. Hopefully that will also reduce some of the overhead affecting tracking latency.
      But first I'll get this repo cleaned up and a working .mxe again, and them swap this branch with master. Will update on progress ASAP.
      (BTW @KCOUL, I've been manually merging the mac oculus SDK into the windows SDK. The only differences are in the /Lib and the /Src/Displays folders. Seemed to make more sense than having two copies of the SDK in the repo...)
    • Jan 21 2015 | 11:02 pm
      that are wonderful news! really looking forward and many thanks all for your work!
    • Jan 23 2015 | 8:40 pm
      OK with a couple of project tweaks it builds fine in VS2012. I'm building this against the VS2010 sdk though, since that's what is currently recommended by the Max SDK. Uploaded new .mxo and .mxe to https://github.com/grrrwaaa/max_oculus with a few changes -- there's now two more outlets for position and tracking status. Runs fine on Windows 7 (Max in 32-bit) here, 60fps. The next beta/update will fix the issue in Max 7 of no lights in the right eye.
      TODO: show the health & safety warning, try predictive tracking, time warp in shaders, rendering direct to rift.
    • Jan 23 2015 | 8:45 pm
      OH -- and for the DK2 you'll probably want to apply @rotatexyz 0 0 90 to the two meshes. I'll add something to the help file for this.
    • Jan 24 2015 | 6:28 pm
      I find riftshader.jxs used in the help patch need a bit of modification to make it work with DK2+SDK0.4.4 on win8.1 + HD4000 graphics.
      Firstly I had to change all valuable name "flat" to something else to get around syntax errors. Then I had to comment out "uniform sampler2D scene;". With these it works perfectly. Please check, cheers.
      Takashi Watanabe
    • Jan 26 2015 | 1:32 am
      Graham thanks so much! It works fine in Win7 with DK2 after i did the shader changes as described by Takashi. Looking forward to the next Max Update now!
    • Jan 26 2015 | 4:58 pm
      Thanks, I missed that comment. I've made those changes and pushed to the repo.
      (Oddly the shader code wasn't a problem on my Win7 machine. Must be a graphics driver difference.)
    • Jan 28 2015 | 12:05 pm
      While I wait for it to download, I presume that I do not need to build the external from source unless I want to make specific changes to it? Can I otherwise simply use the built external in the repo for win7 max6 oculus sdk 0.4.4?
      UPDATE: I opened the oculus.maxhelp file and these are the messages I got after I clicked the qmetro button, the display was all distorted, but I don't know what I should be seeing in the first instance, however the distorted display does at least respond to physical movement of the headset and the fps is at 66fps. I've also posted an image of the distorted view as viewed on desktop.
      Jitter initialized oculus: initialized LibOVR 0.4.4 oculus: 1 HMDs detected oculus: serial 204WXA05T9MM oculus: hmdType ovrHmd_DK2 oculus: Manufacturer Oculus VR oculus: ProductName Oculus Rift DK2 oculus: Firmware 2 12 oculus: CameraFrustumHFovInRadians 1.291544 oculus: CameraFrustumVFovInRadians 0.942478 oculus: CameraFrustumNearZInMeters 0.4 oculus: CameraFrustumFarZInMeters 2.5 oculus: DisplayDeviceName \\.\DISPLAY3\Monitor0 oculus: DisplayId -1 oculus: Resolution 1920 1080 oculus: EyeRenderOrder 1 jit.gl.shader: -- START GLSL INFO LOG: vp -- 0(18) : error C1008: undefined variable "flat" jit.gl.shader: -- END GLSL INFO LOG: vp -- jit.gl.shader: GLSL program failed to compile. jit.gl.shader: error deleting GLSL program object: GL Error: Invalid value jit.gl.shader: -- START GLSL INFO LOG: vp -- 0(18) : error C1008: undefined variable "flat" jit.gl.shader: -- END GLSL INFO LOG: vp -- jit.gl.shader: GLSL program failed to compile. ob3d_draw_preamble render lights: GL Error: Invalid value jit.gl.light: warning: jit.gl.node cannot contain lights - adding to parent render context jit.gl.shader: -- START GLSL INFO LOG: vp -- 0(18) : error C1008: undefined variable "flat" jit.gl.shader: -- END GLSL INFO LOG: vp -- jit.gl.shader: GLSL program failed to compile. jit.gl.shader: -- START GLSL INFO LOG: vp -- 0(18) : error C1008: undefined variable "flat" jit.gl.shader: -- END GLSL INFO LOG: vp -- jit.gl.shader: GLSL program failed to compile.
    • Jan 28 2015 | 9:55 pm
      Sorry about that -- typo in the shader. I've uploaded the fix to the repo. If you don't want to download it all again, you can just edit line 29 of riftshader.jxs, to change "flat" to "flattened".
      Note that currently the oculus object doesn't support direct to rift so you'll need to have the rift driver running in extended mode. You can either rotate the window in the Windows display driver, or you can tick the box for portrait mode in the max patch.
    • Jan 29 2015 | 11:19 am
      That seemed to do the trick, i can now see that i'm in a wireframe cage with 3 doughnuts. Head tracking is working as well as positional data at a solid 66 fps!
      Hopefully you could clarify a few points for me:
      (1) When I turn my head very slowly the wireframe cage appears to shimmer with colour much like a CD does when reflecting light, is this the same for everyone or do I have a graphics issue?
      (2) When the mouse is focused on the render window (by clicking and holding), the mouse movements do not rotate the scene, instead the scene moves a little bit initially but then judders and springs back to its original position when i let go of the mouse button, is this intentional as well?
      (3) In the world patch, changing the @shape attribute from "opencube" to "sphere" does not result in a sphere enclosure being perceived in the scene. Instead the top and bottom of the "sphere" are elongated alot, much like a rugby ball shape. Is this the same for everyone else?
    • Feb 01 2015 | 12:27 am
      graham, this is awesome. Do you have any idea how i could improve my fps. right now its around 40.
      my specs: Oculus Rift DK1 Firmware 0.18 Processor 2,3 GHz Intel Core i7 Memory 16 GB 1600 MHz DDR3 Graphics NVIDIA GeForce GT 750M 2048 MB Software OS X 10.9.5
    • Feb 01 2015 | 2:20 am
      (1) This is due to a combination of the chromatic aberration distortion in the shader, which is needed to cancel out the chromatic aberration induced by the oculus rift's lenses. It's never perfect though, and most visible with moving lines. I should have given the example world a skybox instead...
      (2) Not intentional. I need to fix up the combination of jit.anim.drive and the oculus data.
      Right -- the specs of my mac laptop are almost the same, and I also get about 40fps. The Rift really wants to use a gamer GPU. (Also the Oculus Rift SDK definitely considers Windows before mac, because of the principal audience no doubt...)
      One thing you could try is reducing the texture dim in the renderer patch. I get 60fps on the help example with the texture dim reduced to 1024x1024, but it also makes things a bit more blurry.
    • Feb 01 2015 | 4:10 am
      Had a bit of fun improving the example world in the maxhelp. Funnily enough, I'm now getting 60fps at full resolution! You'll want to download the skybox.png separately from http://reije081.home.xs4all.nl/skyboxes/
    • Feb 04 2015 | 6:36 pm
      no lights now in 6.1 either. I just installed max 6.1 on my new iMac in order to use the oculus there. I don't know if the light issue crept into your external, or if it is newer computer related. On my 3-year old powerbook the lights worked in 6.1, but not max7, I haven't had a chance to check it on that machine since the last update. I'm starting to get worried as I am using the oculus in a piece in 8 weeks. Hopefully max7.02 will come out soon and fix this problem, but now I am suspicious seeing it is not just limited to max7, but seems to be my whole machine. (new iMac 5K).
    • Feb 04 2015 | 6:42 pm
      works again in Max6.1! - I unplugged and replugged all oculus cords and lights now work on my iMac in 6.1 (still not in max7). Go figure....
      Thank you for your work!
    • Feb 04 2015 | 7:29 pm
      This may be of interest to people watching this thread, a simple UDP based bridge between Oculus, Unity and MAX that also sends out your characters location in the virtual world... https://github.com/asouth/Oculus-Unity-MAX
    • Feb 04 2015 | 10:02 pm
      @Christopher, I'm glad to hear the lights are working. They also work in 7.0.2, which will be released very soon.
      @APS502, thanks for sharing. Nice to have if your main platform for rift graphics development is Unity, but e.g. the audio is in MSP. (You might still get better latency using the Max oculus external for orientation though -- if latency is important.)
    • Feb 06 2015 | 6:55 pm
      Good point regarding latency although I haven't run into any issues myself but im not doing anything that is latency critical (within reason). Yes re. Visuals in Unity and Audio in MSP, this is exactly why I put it together!
    • Feb 12 2015 | 12:08 am
      one question regarding the lights: when moving the head, the light also seems to move. I have a scene where i placed 5 lamps at the top, which i want to light static areas (later they move). it somehow works, but one light always seems to follow the headmovement. is there any parameter i can adjust?
    • Feb 12 2015 | 8:23 pm
      First of all I would like to thank all of you who participated in making the occulus possible in jitter. Especially Gramham for the external! Much much thanks mates :-)
      I just got an oculus DK2 about 2 hours ago
      Here is my input:
      Mbp(oct 2014) Mac osx 10.9.5 Maverick 2.8Ghz i7 Memory 16G
      In Max 7:
      Had a lot problems @ 1st when trying to get it to work in Max7.0.1 But when I tried it in Max6 everything worked like charm on the 1st shot.
      Then when I tried it again in Max7.0.1 it now worked but not perfectly. I have the same dark left eye problem. Also, the headtracking is a lot more jittery-shaky than in Max6. :-(
      -fps 35
      - Graham , tried your patch posted on January 31, 2015 | 8:10 pm and I still saddly get a 35 fps and lots of jitter.
      Funny, that I get no headmovement shaking in Max6.1.9
      Anyways, I have it (Dk2) now and I’ll keep following this thread and posting my results
      Many Thanks again
    • Feb 12 2015 | 8:41 pm
      Hi, thanks for the detailed feedback.
      The dark left eye problem is due to an issue with jit.gl.light in Max 7.0.1, which is already resolved for Max 7.0.2. Max 7.0.2 is going to be released imminently.
      I'm curious about the head tracking difference between Max 6.1.9 and Max 7. I wonder if that is related to the dark eye problem? I'll have to look into that here.
      The Windows machine I have is pretty strong; I get 60fps with the pyramid example patch with Max 7.0.2. (The older example is slower, presumably because of all the antialiasing on the cube lines.)
      I'm not sure -- could you send me a simple example patch? I'm not convinced I've got the jit.anim.node stuff right yet, this could definitely use some work; maybe that's related?
    • Feb 13 2015 | 2:24 am
      @graham just a little update to say that I had not tried your patch posted on "January 31, 2015 | 8:10 pm" in Max6.1.9. I get a solid 66fps !!
      Just to let you know :-)
      Thanks again for the amazing work. wow! will be such a practical tool for me.
    • Feb 24 2015 | 12:05 am
      Update on direct-to-rift mode path: initial research suggested that this is not possible with the Oculus SDK's current design, and I've just had that confirmed on the Oculus dev forum: https://forums.oculus.com/viewtopic.php?f=20&t=20569&p=247551#p247551
      Until that changes, Oculus in Max is limited to using extended desktop mode (if you are a Mac user that doesn't matter). I'm going to put that to one side and look at other things on the TODO list.
    • Mar 12 2015 | 4:53 pm
      Max 7.0.2 was just released, and works great with the oculus external (it includes the lighting fix that resolves the dark left eye bug mentioned above).
    • Mar 18 2015 | 4:30 pm
      Is anyone experiencing judder in the demo scenes? It is worst the faster you move.
      I've tried it on both MAX 6 Windows 64 bit, GeForce GTX 780 and on a brand new MacBook Pro (with ALL trimmings) running Windows 7 and MAX 7. Both systems run at 66 fps reliably.
      Any input is appreciated. Configuration Demo and Tuscany Demo works very nicely on both systems.
    • Mar 18 2015 | 8:41 pm
      Are the demo patchers is running at 60fps consistently? If you can try the patcher below, it has a sub patcher with more useful fps tracking; the fpsgui might only be showing an average.
      Also try reducing the resolution of the frame buffer -- there are some variants on the right-hand side of [p oculus_render]. If reducing the resolution helps, then the issue is GPU bound.
      It might also be worth trying turning @sync off on the jit.window, see if that helps?
      One thing that has not yet been implemented for Max is the time warping, which could have a big impact on reducing judder; that might well be the difference. I'm working on it...
      Another thing is, to make a fair comparison, you should run non-Max demos in extended display mode (not direct-to-rift). It might make a difference. Unfortunately, the current Oculus SDK just isn't compatible with running direct-to-rift or software rendering from a plugin (which is what we need for Max), so extended display + client rendered is our only option for now. Not sure if this makes a big difference to performance or not.
    • Mar 18 2015 | 8:42 pm
      Here's the patcher