Using the rift with an RCA signal

[gearwolf]

I use 2.4 to fly and 5.8 for fpv. I wasn't really thinking for long distance flights more proximity tree flying so I would probably go for a closer camera separation. Geekmaster about your 2d to 3d converter, do you think other hardware might have better adjustments? I've seen a couple of ones on amazon that might do it but if they all adjust the same then maybe not worth it.

[KritzelKratzel]

Hi,

this is my first posting in this forum, so I will spend some words to introduce myself. I am KritzelKratzel and I have designed and built the 3D-FPV camera (http://www.rcgroups.com/forums/showthread.php?t=1802511), which seems to be under observation here in this thread. I have called it NerdCam3D and currently I am working (in part time) on the small-scale commercialization of this device. As I live inside Europe with all its legislations and directives for market access this is not an easy task, but it is still possible and simply takes more time.

With respect to the running discussion on overlapping or not overlapping pictures and necessary alignments for best compatibility with the Oculus Rift, I would like to point to an alternative lens alignment, which is possible (within mechanical limits) with my camera:

NC3D_Alignment.png

Would this help to ease the use of the 3D-FPV camera together with the Rift? To which degree should I move the lens holders mechanically? Any comments/advices/remarks are welcome.

Best regards,
KK

[geekmaster]

Hi,

this is my first posting in this forum, so I will spend some words to introduce myself. I am KritzelKratzel and I have designed and built the 3D-FPV camera (http://www.rcgroups.com/forums/showthread.php?t=1802511), which seems to be under observation here in this thread. I have called it NerdCam3D and currently I am working (in part time) on the small-scale commercialization of this device. As I live inside Europe with all its legislations and directives for marked access this is not an easy task, but it is still possible and simply takes more time.

With respect to the running discussion on overlapping or not overlapping pictures and necessary alignments for best compatibility with the Oculus Rift, I would like to point to an alternative lens alignment, which is possible (within mechanical limits) with my camera:

NC3D_Alignment.png

Would this help to ease the use of the 3D-FPV camera together with the Rift? To which degree should I move the lens holders mechanically? Any comments/advices/remarks are welcome.

Best regards,
KK

Lens shift was discussed in my "fresnel lens stack" and "custom Rift lens eyecup" threads. It is a viable alternative for shifting the central viewpoint inward as required by the Rift. The problem with doing that at the camera is the same as moving the cameras closer together, which will reduce the 3D parallax. I prefer a WIDER than normal parallax for flying, but for flying near the ground or trees a more "normal" parallax may be preferred to avoid 3D "window violation" errors.

And interesting thing about using an offset (off-center) position on the lenses as you suggest, is that the effective shifted camera viewpoint can be changed in flight by rotating the lenses eccentrically about the camera centers. You could select between inward offset, outward offset, or any offset in between (at the expense of a variable upward or downward offset).

One big complication is that for wide-angle (or especially fisheye) lenses, which would be very desirable for the wide Field-of-View of the Rift, would experience asymmetrical distortion when used in an offset position. This can be a big problem for stereoscopic viewing , depending on how much fisheye pincushion distortion is used and how much lens offset is used. Although offset lenses on the camera may partially compensate for DIY offset lenses in a Rift, such as the 2-inch 5x aspheric acrylic lenses tested in a Rift by myself and others, as mention in the "custom eyecup" thread.

I hope your camera project works out well for you.

[gearwolf]

So geekmaster basically kk's camera would still work but we still need a backend solution to alter the overlap (can be done with custom lenses) and image warping, right? I was hoping altering the source would have fixed it.

[geekmaster]

So geekmaster basically kk's camera would still work but we still need a backend solution to alter the overlap (can be done with custom lenses) and image warping, right? I was hoping altering the source would have fixed it.

It should work with offset lenses, if you do not use lenses with too much fisheye distortion.

Instead of using lens offset, my preference would be to modify the electronic circuit to insert a delay in the horizontal (or composite) sync signal sent to one of the genlocked cameras, shifting its horizontal position electronically. As I mentioned in a previous post, this delay circuit may be as simple as a resistor and capacitor:



Or you can get fancy and add pulse-shaping to your delay circuit, if you do not mind the added complexity and expense:



Using a variable resistor in the above circuit diagrams would allow manually adjusting the horizontal offset between the half-width images from the two cameras.

[KritzelKratzel]

Hmm, I think I still do not get the point. Is there some documentation on the rift requirements for 3D input signals available? Maybe I should read a bit through some PDFs before asking stupid questions here...

[geekmaster]

Hmm, I think I still do not get the point. Is there some documentation on the rift requirements for 3D input signals available? Maybe I should read a bit through some PDFs before asking stupid questions here...

The Rift Dev Kit needs the image centers to match the distance between your eyes (IPD, or 64mm as used in the Rift), even though it displays SBS images on a 7-inch screen (about 6-inches wide, giving about 76mm between its stereoscopic images).

A normal fully-overlapped SBS image pair would be viewable fine on a 3D TV or other fully-overlapped HMDs, but on the Rift Dev Kit, the video needs to be adjusted so that objects on the horizon are only 64mm (IPD) apart on the screen. That means that the images need to be pulled horizontally inward about 12mm, so that the two image halfs do NOT fully overlap (where both images contain extra content on the outer edges).

A simple solution may be to aim the cameras slightly outward so that they do not have full stereoscopic overlap in the center. Or if your electronics is very simple, and just switches cameras in the middle of a scan line, you could shift the video output of one camera with a sync delay as I mentioned previously.

Sending fully-overlapped video means that some kind of post-processing would need to be done on the receiving end, complicating things more than necessary.

I think your lens shift diagram was pulling the images the wrong direction. The Rift needs less overlap, not more...

[KritzelKratzel]

OK, I think I get the point slowly.

What you probably do not know is that the IPD between the lenses on my camera is 70mm exactly. Initially I planned to use 65mm but due to pcb layout constraints I needed to go to 70mm. In view of the required 76mm IPD I think a movement of the lens holders into the opposite (outwards) direction should not be a problem at all.

Currently the lenses are aligned in parallel with a distance of 70mm. Would it help to leave this parallel alignment and to move the lens holders slightly outwards, such that an IPD of 74mm is present at an distance of X mm in front of the camera?

My current mechanical lens calibration procedure is to focus the (fixed-fucus) lenses at about 50cm distance between camera and focal plane and then to align the respective image centres in parallel (as indicated in the drawing if my first post).

[geekmaster]

OK, I think I get the point slowly.

What you probably do not know is that the IPD between the lenses on my camera is 70mm exactly. Initially I planned to use 65mm but due to pcb layout constraints I needed to go to 70mm. In view of the required 76mm IPD I think a movement of the lens holders into the opposite (outwards) direction should not be a problem at all.

Currently the lenses are aligned in parallel with a distance of 70mm. Would it help to leave this parallel alignment and to move the lens holders slightly outwards, such that an IPD of 74mm is present at an distance of X mm in front of the camera?

My current mechanical lens calibration procedure is to focus the (fixed-fucus) lenses at about 50cm distance between camera and focal plane and then to align the respective image centres in parallel (as indicated in the drawing if my first post).

No. The display CENTERS are too far apart in the Rift for fully overlapped SBS images. The IPD (distance between objects on the horizon of the two displayed images) needs to be 64mm.

Like I said, instead of moving the cameras farther apart, perhaps they could just be twisted outward a little (not the perfect solution, but perhaps good enough for FPV). Better stereoscopic alignment if they both face forward though, and their images are adjusted for 64mm IPD (such as with lens offset, or electronically if my suggestion works with your hardware). How do you pack the two images together? Are all camera pixels used, or only half-width from each camera? Or do you compress them horizontally for true SBS-Half (3D TV) format?

[KritzelKratzel]

Both image sensors are genlocked and output ITU BT.656 conforming digital video data at 27MHz. There is a small FPGA on my cam which captures both digital video streams and converts them into a single video stresm (true side-by-side or true field-sequential video) in the digital domain. Finally a video DAC creates the CVBS (NTSC or PAL) out of this converted digital video signal.

Both cameras use the full resolution. There is no way of moving a sensor window around without loosing resolution. Any suggestions?

[geekmaster]

Both image sensors are genlocked and output ITU BT.656 conforming digital video data at 27MHz. There is a small FPGA on my cam which captures both digital video streams and converts them into a single video stresm (true side-by-side or true field-sequential video) in the digital domain. Finally a video DAC creates the CVBS (NTSC or PAL) out of this converted digital video signal.

Both cameras use the full resolution. There is no way of moving a sensor window around without loosing resolution. Any suggestions?

Either add a delay to the genlock sync signal to one camera, or use offset lenses, or perhaps aim the cameras slightly outward. But the best way it probably to adapt your FPGA code could shift one (or both) images inward a little to match the viewer's IPD on the Rift.

The Rift was designed primarily for gaming, so it is uncertain how well it will work for IPV. But it could work well. We will find out eventually...

[geekmaster]

You can also shift the images optically in the Rift, with prisms, such as these cheap DIY fluid-filled prism glasses:
http://www.vrtifacts.com/build-your-own ... c-goggles/



There may be issues with distortion depending on choice of FPV lens fisheye.

[KritzelKratzel]

Geekmaster, thanks for your hints. I really appreciate your help.

Currently I'm thinking about the idea to shift both side-by-side images inwards. Technically and spoken in VHDL - no prob, even with the currently installed FPGA. However when I shift the images inwards, should I remove some video lines at the beginning and the end of the video frame in order to keep the aspect ratio?

Second question: supposed the inward shift solves the IPD requirement of the rift of 64 mm, will the distortion introduced by fish-eye lenses or wide-FoV lenses be compensated by the rift automatically?

[geekmaster]

Geekmaster, thanks for your hints. I really appreciate your help.

Currently I'm thinking about the idea to shift both side-by-side images inwards. Technically and spoken in VHDL - no prob, even with the currently installed FPGA. However when I shift the images inwards, should I remove some video lines at the beginning and the end of the video frame in order to keep the aspect ratio?

Second question: supposed the inward shift solves the IPD requirement of the rift of 64 mm, will the distortion introduced by fish-eye lenses or wide-FoV lenses be compensated by the rift automatically?

The Rift has square pixels on a 16:10 screen. Typical FPV cameras are 4:3 screen AR and pixel AR is NOT square for 360x480 color NTSC encoding (in the USA). When color burst is present (NTSC, not RS-170A), camera Luma is low-pass filtered to remove any high-frequency that could be interpreted as color signal (hence, 360 wide). For monochrome (no color burst) you can use 720p output. Old computer TV-output and video games got their 320x240 by letterboxing the 360-wide with a background frame (and sometimes software-selectable border color).

Because the Rift does not have analog inputs, the video will need to be digitized, and pixel AR will be handled by the digitizer (Composite video to HDMI converter). But you SHOULD compress the video vertically so that it is 16:10 AR, so that round things can stay round in the Rift... But 16:9 may be close enough.

[Grix]

This is getting way too technical and difficult for me, I won't be able to contribute to the discussion much.. But I just wanted to say that your camera looks very cool, kk, and with some modifications it might be a godsend for the purpose of using the rift for FPV. I'm sure you guys will figure out a solution. I don't know if you are able to answer this exactly, but how much do you think it will cost, and when will it be available?

Also, forgive me if this was just answered and I didn't catch it, but why wouldn't simply slightly rotating the cameras away from each other work?



To simulate this guy: http://www.mtbs3d.com/phpBB/viewtopic.p ... 56#p108456

[geekmaster]

This is getting way too technical and difficult for me, I won't be able to contribute to the discussion much.. But I just wanted to say that your camera looks very cool, kk, and with some modifications it might be a godsend for the purpose of using the rift for FPV. I'm sure you guys will figure out a solution. I don't know if you are able to answer this exactly, but how much do you think it will cost, and when will it be available?

Also, forgive me if this was just answered and I didn't catch it, but why wouldn't simply slightly rotating the cameras away from each other work?



To simulate this guy: http://www.mtbs3d.com/phpBB/viewtopic.p ... 56#p108456

I mentioned that as a option. I also mentioned that it causes a little distortion when both camera lenses are NOT pointing the same direction, in the form of the height of some objects not the same in both images, making stereoscopic viewing a little uncomfortable. But even so, such camera rotation is commonly used for many 3D games for stereoscopic rendering, when they do not easily support a pair of side-by-side forward facing virtual cameras. So it can be used despite its shortcomings, as I mentioned in a previous post above. The stereoscopic overlap should be about equal to what the Rift needs to work okay.

The ideal solution is for both cameras to face forward, and combine their signals to put out a Rift-compatible format. With custom FPGA code, it may even be possible to do the Rift pre-warp distortion in the camera unit. But that may not be compatible with future Rift models...

[KritzelKratzel]

Rotation of the imagers and lens holders as a whole is not possible. The imagers sit on the PCB and the pcb is flat and rigid. I can only shift the lens holders a bit around their centre position over the middle of the imager. However as far as I understood this is not sufficient to comply with the 64mm IPD rule of the Rift.

@Geekmaster: vertical compression or stretching is difficult. I guess I would need to capture a half-frame or a full frame before doing the required operation. I'm not sure whether there are enough resources left on the FPGA for such an operation. Horizontal manipulations are much simpler though.

Another point: what would the rift display if we'd input 4:3 aspect ratio digital video into the hdmi port? Would it be stretched to 16:10 or displayed correctly with black bars on the left/right border?

[geekmaster]

Rotation of the imagers and lens holders as a whole is not possible. The imagers sit on the PCB and the pcb is flat and rigid. I can only shift the lens holders a bit around their centre position over the middle of the imager. However as far as I understood this is not sufficient to comply with the 64mm IPD rule of the Rift.

@Geekmaster: vertical compression or stretching is difficult. I guess I would need to capture a half-frame or a full frame before doing the required operation. I'm not sure whether there are enough resources left on the FPGA for such an operation. Horizontal manipulations are much simpler though.

Another point: what would the rift display if we'd input 4:3 aspect ratio digital video into the hdmi port? Would it be stretched to 16:10 or displayed correctly with black bars on the left/right border?

No vertical changes needed. Barrel distortion needed for the Rift is already done by wide-angle lenses.

The Rift only needs a pair of half-width images that are SLICED from the camera images, like this:

Rift-Cameras.jpg

You should be able to do that in the FPGA. You can clip off some of the outer edges of the final image if needed. The Rift cannot see all of the outer pixels in most cases anyway.

And you do not need extreme fisheye in the lenses to match what the Rift needs. Too much or too little with leave either barrel of pincushion distortion in what the Rift sees.

Good luck!

[KritzelKratzel]

Geekmaster, please check whether I have got the point or not. Thanks.

This is the required situation for the Rift. There is the 16:10 display which needs to be filled with "fisheyed" video data.

NC3D_Rift_01a.png

And this would be the situation if I just changed the present lenses on my NerdCam3D with appropriate fisheye or wide-FoV lenses, that would be aligned to the size of my imager. We see, both images from left and right side are compressed horizontally and put together in a conventional 4:3 video frame. The distance from middle of left frame to middle of right frame corresponds to the 70mm IPD of my camera.

NC3D_Rift_01b.png

In order to correct the IPD problem (Rift needs 64mm, NC3D has 70mm) I would need to horizontally shift the video data of both cameras inwards to about 9%. Then we have this arrangement:

NC3D_Rift_01c.png

Finally I would skip the horizontal compression and just crop the all remaining parts of the frames that do not fit into the final 4:3 rift-side-by-side frame:

NC3D_Rift_01d.png

Is this the whole story or is there even more to consider?

In case this is correct, then the final problem would be to have a CBVS-to-HDMI converter, that does not distort the 4:3 aspect ratio of my analog video. For real FPV-usage this converter will be placed between the FM-receiver and the rift itself. A direct digital transmission of the video data to the rift of cause would be favorable but as long as there are no suitable digital video links available (price, latency, etc.) the video transmission will be done using those lousy analog FM-Tx/Rx sets.

[geekmaster]

I have a CBVS-to-HDMI converter, and as I recall, it does stretch the image to fill the screen, although that is not enough to fully compensate for your SBS-Half horizontally compressed images.

I think somewhere in BETWEEN your two images would be the correct amount of horizontal compression (some compression, and some outer edge clipping). That way the CBVS-to-HDMI converter horizontal expansion from 4:3 to 16:10 would end up making round objects look round in the Rift. And clip any excess off the outer edges of the SBS-(not quite half) images...

I suspect there will be more latency in the camera servos and/or aircraft responsiveness than the video, so additional digital video latency may be insignificant compared to mechanical latency.

Although I need to test my CBVS-to-HDMI converter, I think that it did stretch the image, unlike what you said you wanted. That means you need to horizontally compress your images just enough to compensate, but not in half.

[geekmaster]

Here is a screencap of fisheye video that looks great in my Rift (but the FoV is set a little to wide, giving slightly bowed images near the edges):

screencap1.jpg

Click the attachment to see the full 1280x800 image. If you want to try direct wide-eye viewing of the attachment after clicking it, many web browsers, you can change the size of the above preview image with Ctrl-mousewheel. Just shrink the attached image in your browser to bring the image centers close enough for wide-eye free viewing. Try viewing it (look at the image above, but look THROUGH the glass of your screen to see the 3D image beyond that virtual window.

Remember that this image is full 180-degree fisheye warped, and for the correct warp factor for the Rift, you need to zoom into the center of the image a little more (about 110-degrees instead of about 170 degrees as shown here). All but the inner edges are not visible unless I tilt my Rift to look through the lenses at an angle. With different lenses (like my 2-inch lenses in the "eyecup mod" thread), I could see all the way to the edges. Because the Rift already restricts my FoV, this image is actually ALMOST correct (only a SMALL amount of extra FoV).

Please forgive the crude pixellated image -- it is a preliminary Work-In-Progress of simple non-GPU native-mode code designed to work on my Raspberry Pi.

I hope this Rift-compatible fisheye image pair shows what you need to output from your stereoscopic FPV camera (AFTER the CBVS-to-HDMI converter stretches it from 4:3 to 16:9). The converter actually outputs 720p, not 800 that the Rift wants, so there may be a small amount of letterboxing or stretching depending on how the Rift hardware treats 720p. But that difference is minor...

*** Credit goes to mediavr for the original Belmont Park 360-degree panaramic stereoscopic image pair from which the above Rift-compatible screenshot was extracted.

[KritzelKratzel]

I was busy with others things the last days but during a flight back home at the end of a business trip I tried to summarise the situation.

The compensation of the 4:3 AR to 16:10 AR distortion is a bit complicated. The point is that such a scaling with a factor of 1.2 is no longer a scale factor as s power of 2. Reducing a video stream in width to the half is easy, but now it seems I had to introduce a much more complicated video line scaler. I'm not sure if my FPGA is powerful enough for this. OTOH, the difference between 16:10 and 4:3 is not so huge: 1.6 vs. 1.3333. Is it really worth doing this last step?

Other aspect: is a 720p HDMI signal always 16:9 or is there a "switch" to tell the display that the data is in 4:3 such that the display can do the pillar boxing automatically?

Any coments are welcome.

[geekmaster]

FPV people are already accustomed to watching distorted raw video from wide-angle lenses, so a small change in AR is not really needed (especially for video already compressed by the wide-angle lens).

[KritzelKratzel]

Now I think the HDMI 720p is always 16:9 in aspect ratio. So a good way to circumvent the axial ratio distortion problem would be to use a better analog video to HDMI converter. Would this device fit to our needs?

http://www.amazon.com/Ypbpr-V2hd-Video- ... B007G51J02

The product description tells us the following: "... Add black bar to match with 5:4 or and 16:10 panel ...". Is this the property we are finally looking for?

There are several sellers on http://www.aliexpress.com as well.

[geekmaster]

The problem is that LCD monitors with CVSB (RCA-jack) video in, and also the cheap CVSB-to-HDMI converters, seem to stretch the the 4:3 video into 16:9 or 16:10, when they should all pillarbox columns to maintain 4:3 aspect ratio.

It is the kind of problem I think you can ignore in the first iteration, to save on costs and complexity.

[Grix]

Geekmaster, the 3d converter compresses the image to half it's width, right? How weird does that look in the rift?

[geekmaster]

Geekmaster, the 3d converter compresses the image to half it's width, right? How weird does that look in the rift?

Meh, okay... The problem is that I can only keep one eye open at a time. I have successfully viewed SBS-Half in the Rift two different ways. Either shrink the image to bring the image centers closer together so you can stereoscopically merge them, or use two-inch 5x aspheric acrylic lenses (from the DIY Rift thread) in an offset position to optically pull the images closer together.

The "virtual" 3D is meant for a 3D TV (full overlap), but most 3D TVs already have a built in "fake 3D" converter. It should work okay with my HeadPlay HMD though, which can view SBS-Half content, except the HeadPlay LCoS "Rainbow Ghosts" (RGB color cycled after-images burned into your retinas) when you move your head or eyes in a HeadPlay are very annoying to me. The Rift does not have such ghost images, and has a much more expansive FoV, which is why it would be nice to try it for FPV use.

[Grix]

Geekmaster, the 3d converter compresses the image to half it's width, right? How weird does that look in the rift?

Mey, okay... The problem is that I can only keep one eye open at a time. I have successfully viewed SBS-Half in the Rift two different ways. Either shrink the image to bring the image centers closer together so you can stereoscopically merge them, or use two-inch 5x aspheric acrylic lenses (from the DIY Rift thread) in an offset position to optically pull the images closer together.

The "virtual" 3D is meant for a 3D TV (full overlap), but most 3D TVs already have a built in "fake 3D" converter. It should work okay with my HeadPlay HMD though, which can view SBS-Half content, except the HeadPlay LCoS "Rainbow Ghosts" (RGB color cycled after-images burned into your retinas) when you move your head or eyes in a HeadPlay are very annoying to me. The Rift does not have such ghost images, and has a much more expansive FoV, which is why it would be nice to try it for FPV use.

What about the fresnel lens stack you mention here? http://www.mtbs3d.com/phpBB/viewtopic.p ... 70#p117035
You said that it stretched the picture horizontally like 50%, which is perfect because that would correct the 3D converter's compressing, no? I see that you mention them earlier in this thread before you got your rift, did you try it?
Also, how hard is it make mod the eyepieces to make this happen? I don't have a 3d printer or anything, will I be able to make offset lens eyepieces myself with basic tools?

[geekmaster]

I only tried a single Fresnel lens stack in my Rift. I will need to try two sets. They work best placed directly over the holes instead of eyecups, but getting both eyes close enough would be difficult. Alternatively, you can make an eyecup from cereal box cardboard like I did in my "custom lens eyecup" thread. Somebody else posted to that thread where they used fresnel centers (no offset) and it worked for them better than stock lenses. Of course, using offset lenses could stretch the image horizontally AND bring the centers closer together, to work with the 3D converters. There are many options for lenses in the Rift...

[KritzelKratzel]

I'm a little bit confused about which lens to use in oder to generate the required lens images for the Rift. There is for example an overview available at optics online: http://optics-online.com/doc/files/wide ... %20FOV.pdf

My imagers are of 1/4" size (rightmost column in the sheet), the mentioned imager type is nearly the same as in my cam. I thought I just take a lens which generates a lens image circle of a diameter corresponding to the imager height (a.k.a. the "circular fisheye (CF)" configuration in the linked document). But it seems that all lenses, even those with very small focal distances, can not produce the circular fisheye image, because of the size of my imager.

So what to do? Which FOV shall the lenses have? The same as the Rift (AFAIK 90°)? Any ideas?

PS: There are even more optics wizards available at optics online (http://optics-online.com/wizards.asp). Some are available after registration, but a bogus identity will suffice. There is no confirmation/activation action via e-mail requested.

[Grix]

Here is another thread on RCgroups about making the rift work with FPV: http://www.rcgroups.com/forums/showthread.php?t=1871783

Some of those guys are working on an FPGA solution to convert and morph the video signal. This is perfect, if you know anything about FPGA development I encourage you to contact them and help, they say it will most likely be open source.

[KritzelKratzel]

Some of those guys are working on an FPGA solution to convert and morph the video signal. This is perfect, if you know anything about FPGA development I encourage you to contact them and help, they say it will most likely be open source.

Thanks for this hint, I'm already active on RCgroups, but so far not with respect to the rift. Let's see what others are doing in this area.

[DENIS]

Do you know that jet video where they have a moving camera in the cockpit?
It really feels like flying a jet ... a toy jet, but a real jet all the same. If someone creates a ready-to-go solution for a quadcopter that would be of interest to many people!

I think I know which video you talk about, I read this post and the post on RC-group about the Rift wiht great interest. I would love to fly my FPV planes with goggle like the Rift. What it miss in the FPV world, it is a big screen. I fly FPV plane since 12 years now, and the size of the screen as always been too small at my taste. But I understand why it is not possible for now to use the Rift.

Here is my F-16 FPV plane: https://vimeo.com/7122727

[Captain3D]

Hi All

(First post here although I have been lurking for a while)

I have been collaborating with Trevor at EMR Labs (ForceFly, 3D-Cam FPV) on how we could get the Rift and 3D FPV working. Well he is doing all the hard work and has managed to build the first prototype interface that allows for 3D FPV using the Rift. We are calling it Transporter3D. Take a look at the youtube video below showing the worlds first 3D FPV flight through the Rift...

http://www.youtube.com/watch?v=u74rf4ztJTI

If you have a Rift you can see the flight using full screen and high res playback. It plays after our 2D intro.

We would like to make a limited production run at some point, if the interest is there, but first we would like to crowd source the final design to see how people would want to use it. We certainly want to go all out 3D but maybe others would use a single camera duplicated to each eye.

Let us know what you think.

cheers...phil

[Hadtstec]

Looks really good and I am definitely interested in this.
could you give us some more details on how the system works and how much you expect to sell this for?

what bits do I need to add to my existing FPV setup to make this work?

[Captain3D]

Hi Hadtstec

Part of the reason for getting the word out now is to see how people would like it to work so we can design it to suit. So far it is going on this path...

It is a box that sits between your FPV Vtx/s and the Oculus Rift. It allows for all types of control for alignment and scaling of the images. Head-tracking is available. It could work with three camera setups...

1. Two cameras connected through two video transmission systems on different frequencies (eg 1.3 and 900). This what you see in the video.
2. One 3D FPV camera (eg 3D-Cam FPV) using a single VTx
3. A regular 2D FPV setup

The first two would provide a 3D and wide FOV experience in the Rift. Option two would be slightly lower res. Option three is only using the wide FOV.

How would you like it to work? Price is still out there of course depending on design and features.

phil

[Captain3D]

Transporter3D update:

Demo videos of image alignment on the test rig...

http://www.youtube.com/watch?v=M7WZXzhsFgY

http://www.youtube.com/watch?v=xiqIPjAh0JQ

discussed here...
http://www.transporter3d.com/transporte ... 018558e7e2

phil

[Captain3D]

OK people waiting on Transporter3D news better go take a look at...

http://www.indiegogo.com/projects/trans ... /x/5012831

Board pre-orders are official and selling...

exciting...phil