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!

Thanks,

Yves

any progress?

currently occupied by other projects. Hope the patch is a head start for anyone who wants to investigate further.

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

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 ?

Nope, haven't dug any further. Only a start to stereoscopic rendering and display.

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.

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.)

I can help test. sounds great. you can get me at bob(at)zealousy(dot)com.

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?)

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.

Bob.

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!

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,

mattt.

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.

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

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?

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 192.168.1.64:8051

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

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: https://github.com/grrrwaaa/grrrwaaa_maxobjects/tree/master/oculus

Graham

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.

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:

https://github.com/grrrwaaa/grrrwaaa_maxobjects/tree/master/oculus

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…

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?

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

For anyone still reading, I've moved this object to it's own repository here: https://github.com/grrrwaaa/max_oculus

Great work!!! Thx for sharing.

Fantastic work! Any plans to support dk2 in this object?

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?

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.

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.

Today I got access to a DK2, so I'll be updating the https://github.com/grrrwaaa/max_oculus project now :-)

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.

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.

Hi,

I have a dk2 (not dk1) does this patch work with dk2 yet? I cant get the patch to recognise the dk2.

Thanks

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.

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 ;)

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.

Hi,

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.

Thanks!

Joe

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.

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.

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.

Does anyone have the DK2 working with MAX? I'd love to try it out!

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.

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?

Graham

Hi,

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...

Richard

ps if you're interested in what I'm doing with this stuff, see my occasionally updated blog at www.musigui.com.

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...

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.

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.

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.

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.

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?

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!

Just to let you know this will be fixed in the next update (thanks to Rob Ramirez!)

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).

Richard

That is great news! How is the update coming? I'm getting more and more dependent on max7 everyday.

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;

with

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.

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?

Thanks.

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...!

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?

Thanks

any news with win mxe?

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.

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...)

that are wonderful news! really looking forward and many thanks all for your work!

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.

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.

Hi,

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

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!

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.)

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.

Thanks

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.

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?

Thanks

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

@APS502:

(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.

@JÖRG:

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.

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/

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).

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!

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

@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.)

Graham,

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!

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?

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

phiol

@phiol:

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.)

@Tobias:

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?

Graham

@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.

phiol

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.

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).

Hi,

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.

Thanks

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.

Here's the patcher

Hi Graham,

It's great to see you working so hard to bring the Occulus rift into Max ! I'm considering buying an Occulus but I'm a little hesitant at the moment. I mainly work in Jitter and would love to experiment with the Occulus, is it easy to get the Occulus working with your current patch on the Mac os ? Are you planning on maintaining development until the current version is finished ? I'd just like to know it's going to work before I spend that much money :) Thanks !

Works fine on OSX, but it would need to be a high-end machine for Oculus work in general (not just for Oculus on Max, but for Unity etc. also). I have a fairly new high-end macbook pro, and it can just about handle it, so long as the scene isn't too complex. I.e. good enough for development, but just not quite good enough for regular use.

Yes I'll be continuing to maintain it, and hopefully soon other HMDs too (albeit not at a breakneck pace...)

Thanks for the info Graham. I've got a macbook pro thats about 5 years old. 1 gig graphics card. 8 Gig ram. Hopefully thats enough to pull it off.

I've banged my head against this for awhile and haven't come close... I'm wanting to create a regular view of the oculus world in another openGL context for viewing on a projector for the audience to see what the wearer is seeing. With best frame rate possible, and also the camera view settings synced to the oculus world. Has anybody done this yet that would be willing to share, otherwise at least let me know how I might do this.

It's not really a solution but I've been thinking about this aswell. I'm planning on doing it with Unity though and make life easier I'll be controlling another camera on another instance of the Virtual world on a second machine via UDP messages.

Maybe a similar method would work in MAX?

I'd be glad to know how you get on either way.

Thanks

A couple of different ways of doing it.

A) One way is to run two Max applications, synchronized via network commands. This works well if the content behaves deterministically or is derived from a database that can be accessed by both applications, or application state is simple enough to be shared via local network messages. The second screen viewpoint can be different than the oculus viewpoint.

B) Otherwise, you can use a second window with a shared context. Set the [jit.window oculus] to have @shared 1. Create a 2nd window, also shared, e.g. [jit.window 2nd @shared 1], and create the corresponding renderer as [jit.gl.render 2nd @shared_context oculus]. This will let you share textures between the two windows. To get the oculus view into this second window, there are a couple of options:

1) The easiest way is to attach the outlet of the [jit.gl.camera world] (inside the [p oculus_render] sub patcher) to a [jit.gl.videoplane 2nd @transform_reset 2]. You could also change @scale to fit nicely into your window dimensions.

2) Alternatively, create a new [jit.gl.camera world @capture 1] and hook that up to your [jit.gl.videoplane 2nd @transform_reset 2]. This gives you more flexibility, including having the 2nd-person view having a different location/view than the oculus HMD, but will be more expensive as it requires an additional render of the scene. You probably also want to set the camera resolution to match the 2nd display, e.g. [jit.gl.camera world @capture 1 @adapt 0 @dim 1024 768] etc.

Hope that helps.

Here's a replacement oculus.maxhelp that uses option B1 above.

Thank you. It is working great!

Hi Graham,

Got the patch working just fine. constant FPS between 60-66-fps with sync off.

- Get the famous " head jitter effect". refresh rate is 75 hz. Resolution 1920 1080 (1080p) Any tips on how to reduce this ??

Got a AMD Radeon HD 6750M 1024 MB. 8gig of Ram. Mac osx 10.9.5. All tips welcome and great work by the way !!

Hi Andro,

I was also seeing more judder thank I think there should be, FPS is also good. I streamlined the navigation subpatcher and now it looks a bit smoother to me; could you try downloading again and let me know how it is for you? https://github.com/grrrwaaa/max_oculus

I'm hoping that adding the timewarping will improve the experience even more. I will be working on it next week.

Graham

Hi Graham, got the oculus for 3 more days. I'll be able to test it out tomorrow. I already tried running the patch in presentation mode, with the preview window turned off. No joy though. I think rendering it directly to the rift is key here. Doesn't the oculus have to run at 75 FPS to eliminate judder ? I also tried lowering the resolution of jit.gl.node from 2048 x 2048 to 1024 x 1024. Playback seemed a lot smoother but i think the shader doesn't support the resolution as i get glitches during playback. Is it possible to make a simple toggle function to half the resolution for testing purposes ? Having a low,med,high quality setting would allow people to do a more detailed benchmark test on different machines. I'll also be testing this patch on my desktop PC tomorrow to measure the differences.

Hi Andro,

Running at 75Hz is preferable, but unless your primary monitor display is also running at 75Hz (unlikely) your GPU might be doing juddery things to the DK2. A lot of DK2 users have reported this issue. Here are some of the common workarounds to try:

- If your primary monitor can do 75Hz (sometimes possible at a lower resolution), that would be the first thing to try. - On Windows, Aero forces all monitors to vsync to the primary display, perhaps disabling it might help. - Alternatively you could try setting both monitor and DK2 at 60Hz and see if that is better (though you might see flicker... varies from person to person). - Another option is to use the rift as primary (or only) display, but that's a rather drastic solution, as handling the desktop in the HMD is almost impossible.

I've also just pushed another update that adds the low persistence option as an attribute. This might also help improve the experience -- if you have time to try this and/or the resolution/refresh rate options it would be good to hear your results.

Direct to rift might preferable, but I've also seen developers complain about the 60/75Hz judder in that mode too. In any case, until oculus update the SDK this just won't be possible via Max because their support for OpenGL is just not there yet. I'll keep following the oculus developer updates and try again for that if there's a change. There was an SDK update on Mar 26, but I'm hearing mixed responses so far, will wait a bit before updating.

About the resolution question: "I also tried lowering the resolution of jit.gl.node from 2048 x 2048 to 1024 x 1024. Playback seemed a lot smoother but i think the shader doesn’t support the resolution as i get glitches during playback." -- I can't reproduce any error here. I've just updated the oculus.maxhelp again and added a more friendly umenu for trying out resolutions -- can you let me know if it works? Thanks!

And finally, I will also work on timewarp later this week, which may also help.

Graham

Okay, I just tested on my Windows desktop in the office, and can confirm these conditions of judder / no judder:

- main display at 75Hz, rift at 75Hz -> no judder - main display at 60Hz, rift at 75Hz -> horrible judder - main display at 60Hz, rift at 60Hz -> no judder, but some faint blur/flicker

So overall it is essential that the main display and rift are set to the same refresh rate. Your main display might support 75Hz at lower resolutions.

Enabling the low persistence attribute definitely helps keep things in focus when turning the head. The motion blur becomes more like a faint ghosting effect. This is probably the same thing as the "black smear" mentioned in http://doc-ok.org/?p=1082