USB camera module with similar FOV to Rift?

You can mod a PSEye camera with different lenses with wider FOV.

I just saw that on Reddit too. Even better, I already have 2x PS Eye cameras so I just need to buy the mounts & suitable lenses :) Time to hunt for a UK/EU supplier though...

For anybody who comes across this thread on Google, I've ended up buying these mounts;

http://www.ebay.co.uk/itm/111107303287?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1497.l2649

And these lenses;

http://www.onlinesecurityproducts.co.uk/genie-cctv-lenses/genie-cctv-gl25-pcb-minature-dome-lens-25mm-.html

I'm not affiliated with either of these companies, btw. I'll update when the parts arrive & I've had a chance to try them out.

I've discussed pretty much exactly what you're describing here: viewtopic.php?f=29&t=2311

You can use a standard high quality webcam, a metal washer and a fish-eye lens designed for use with an iphone camera, and mount the lens magnetically. I also include a link to the software I used to a produce the passthrough vision I used while wearing the setup.

The results are discussed here: http://rifty-business.blogspot.com/2013/09/wearing-oculus-rift-at-pax-prime-2013.html

Thanks for the links, it's reassuring to know that somebody has already achieved such a setup with success :) Can you comment on what it's like walking around with only a monoscopic webcam feed though? I have only briefly tried moving with my Rift & single PlayStation Eye & noticed quite bad issues with lack of depth perception (trying to grab door handles & completely missing, for example), which is why I assumed I would need to mount both of my Eye cameras (modified with wider lenses) for the project to be usable.

"cjdavies" wrote:
Thanks for the links, it's reassuring to know that somebody has already achieved such a setup with success :) Can you comment on what it's like walking around with only a monoscopic webcam feed though?

I've described it a few times as a 'being slightly drunk' simulator. Walking around requires adopting a fairly deliberate gait because the latency in the display means your visual cues for balance will be delayed.

I was running the system off a Raspberry Pi at the time and didn't have a very good framerate, or great latency, nor was I using the head tracker data in any way. Even though the camera is fixed to the headset, and thus doesn't need the head-tracker, I believe you'd be able to improve the balance issues by taking the input acceleration and rendering the displayed video frames with a slight translation to offset the difference between the actual horizon and where the rendered version will be relative to that. I haven't published anything to do that yet, but when I do it will be on my Github repo and I'll probably discuss it on the blog linked in my sig.

"cjdavies" wrote:
I have only briefly tried moving with my Rift & single PlayStation Eye & noticed quite bad issues with lack of depth perception (trying to grab door handles & completely missing, for example), which is why I assumed I would need to mount both of my Eye cameras (modified with wider lenses) for the project to be usable.

I've heard from the developers at Oculus that their tests with that show lots of potential issues with motion sickness triggered by the difference between the camera motion and the eye motion the brain expects. Cameras that aren't in the exact same position as the eyes will be traversing a larger arc than the eyes, and there's no easy way to counteract that. For widely acceptable software, they recommend avoiding stereoscopic display, i.e. only displaying mono imagery, avoiding a wide field of view, and converting the imagery to black and white. Obviously individual user experience is variable. Personally I have no problem working with the wide FOV color imagery, but I haven't tried stereo images.

One approach to the issue of difference in motion between the camera and the eyes would be to try to shrink the world and positioning the cameras on the axes defined by a line from the center of rotation for most head movements (the base of the neck) and the eye positions. That would mean placing the cameras above and wider than the eyes and would have the result of making the world as a whole seem smaller, and ultimately make it seem like you're too short for your scaled environment (like a giant walking around on his knees).

I'm also planning on experimenting with something like a toon shader to apply to the incoming images to reduce overall immersion and hopefully potential motion sickness.

A lot of interesting points in there, thanks. Are there any publications/blog posts/interview transcripts/etc. of the Oculus developers' recommendations for camera use that you can link to, or are you recounting personal correspondence?

I think I'm going to have to do a number of experiments with different camera setups on myself & some willing volunteers to see what works best for my application. I've just received a pair of 2.5mm M12 lenses but unfortunately the mounts (from a different seller) haven't showed up yet & I won't be able to work on this again until Tuesday.

I've also hit a snag with getting two camera streams into Unity, which I've documented over on the Unity forums. Essentially their WebCamTexture class (which as the name implies lets you render a webcam stream onto a texture) identifies attached cameras by their 'name' instead of by a unique identifier, so connecting 2x cameras of the same model results in one being ignored/overwritten.

"cjdavies" wrote:
A lot of interesting points in there, thanks. Are there any publications/blog posts/interview transcripts/etc. of the Oculus developers' recommendations for camera use that you can link to, or are you recounting personal correspondence?

Mostly personal discussion, plus some stuff from the talk they gave at PAX.

"cjdavies" wrote:
Essentially their WebCamTexture class (which as the name implies lets you render a webcam stream onto a texture) identifies attached cameras by their 'name' instead of by a unique identifier, so connecting 2x cameras of the same model results in one being ignored/overwritten.

That's a bummer. Sounds like you'll likely have to write a C# class to mimic the functionality and do better handling of the webcams. Alternatively, perhaps you can use some OS level utility to 'rename' one of the cameras somehow, possibly in device manager. I used OpenCV for mine, which identifies cameras by a simple integer, but I haven't tried with more than one color stream.

I tried changing the names of the cameras via multiple entries in regedit, such that they each have a unique name in device manager, but alas it seems that Unity gets the 'name' from the driver so as long as the cameras are using the same driver Unity won't be able to use both. The driver is a native EXE so I couldn't disassemble it with ildasm to create two versions with different identifiers.

Anyway, got the lens holders & lenses & installed them without a hitch. I think I'll experiment with both monoscopic & steroscopic outwith of Unity & see whether it is worth it/sensible to spend more time to get stereoscopic working in Unity.

Perhaps you could write a small application which addresses both cameras and produces a single side-by-side image and stream that resulting video via a localhost URL. I haven't spent enough time with Unity to know how much effort that would be, nor have I tried to produce video streams from aggregated content, so it might be more trouble than finding a non-unit solution.