Community Project to Support Page-Flipping Glasses?

[UndeadD3vi1]

Hi guys, why don't we work together and create a USB Device that we can plug our old Shutters into and use them with iz3D?

I could build a prototype for less than $20 so this would be extreamly cheap for everyone to buy! All we'd need is to work together, cover all the bases and get support from iz3D to send sync signal to the device at the right time.

What do you guys think? Im thinking a Arduino chip will be sufficent for this so the final device would be very cheap.

The device could do much more than simply handling Page Flipping Shutters as well. So ideas are welcome!

[Okta]

Sounds great, where do i place my order

[crim3]

You still may need a signal sent to the USB. That's were iz3d comes into play, no?
iz3d already supports vr920, I think to remember (correct me if I'm wrong, I'm not sure now). Maybe that same signal could be used.
Next thing is knowing exactly which VGA signal (or combination of them) tells the shutters to flip.

[UndeadD3vi1]

Yes we would need iz3D to support this. (I've sent a PM to BlackQ about this, as well as suggesting that maybe they would be best suited for selling the device! i.e. You buy the device and get a iz3D Driver Shutter License with it, etc)

The device wouldn't be using the VGA signal, the glasses would plug directly into the Device (3 Pin DIN) with the device plugged in via USB. (Do any shutters use a different connector? If so those connection types will need to be added as well - We could even add built-in IR and backwards engineer all IR Shutters - Even nVidia 3D Vision Glasses!)
It would be very simple to send the current when needed to each lense, the device would just follow instructions from iz3D to maintain sync. (We'd need to emulate page flipping accuratly though for those glasses with controllers on the lead)

We all know DDC is a pain, I have a machine here that literally can not be used with Page-Flipping with the old nVidia drivers due to interfearence on the DDC. This solution bypasses issues like this as well. (Its generally a bad idea to use DDC for anything other than its intended use anyway)

The VR920 is a Two-Screen device, so I think it uses the same method as the iz3D monitor. However almost every other HMD is Page Fliped!! We could work to support these as well! (Would need to make a custom cable to inject sync signal into the VGA signal though)

I'm hoping we get the response of, "yes we'll work with you to produce this as it will save us a hell of alot of effort" (Accessing DDC at the low-level is one hell of a task and I'm getting the feeling nVidia will block any method iz3D use.)
On top of that, they'd be making money either way if this device is made (As people would be buying the Shutter License) so it is in their best interests to support this.

[crim3]

The device wouldn't be using the VGA signal, the glasses would plug directly into the Device (3 Pin DIN) with the device plugged in via USB. (Do any shutters use a different connector? If so those connection types will need to be added as well - Easy to do)

I was thinking in my shutters, that are connected to the vga port. Anyway, at first sight it seems that generating a signal like that independently of the display would lead to timing problems.

The VR920 is a Two-Screen device, so I think it uses the same method as the iz3D monitor. However almost every other HMD is Page Fliped!! We could work to support these as well! (Would need to make a custom cable to inject sync signal into the VGA signal!)

As far as I know, it's page fliped (flips between displays in this case) but the sync (or a help for correct sync) comes from the USB in some form.

Let's see what BlackQ tells you.

[UndeadD3vi1]

I was thinking in my shutters, that are connected to the vga port. Anyway, at first sight it seems that generating a signal like that independently of the display would lead to timing problems.

Your shutters use a 8 Pin DIN, you would plug this into the device. As for timing issues, iz3D would be in control of the frame outputs and sync signal so I do not see why any issues would occur, and if they did the device could allow users to adjust the sync timing by a couple ms until its perfect? As for DLP's, like 3D Vision we could output the sync signal to the DLP screen as well.

As far as I know, it's page fliped (flips between displays in this case) but the sync (or a help for correct sync) comes from the USB in some form.

And iz3D supports the VR920, which from what you just described works exactly how this device would!

[cybereality]

From the sounds of it, I think it would work sort of like the VR920 works. From what I understand it works on page-flipping but uses the USB to sync the signal. So it gets one frame (right frame lets say) which remains on the screen, then the left frame comes in and replaces only the left display, then the next right frame comes in, etc. So it may be possible to simply use the iz3D's VR920 mode with this hypothetical black-box you are talking about. That would mean the driver end was already done and there would be an existing spec to program for the USB sync. Maybe its more complex then this, I don't know. But it seems like a good place to start.

[bob_shaftenkluger]

What is wrong with the existing iz3d shutter drivers? CarlKenner mentioned in the other thread "iZ3D driver will not work, unless you can keep the game frame rate permanently above the refresh rate. " To me this implies that the driver sends the sync signal with each monitor refresh, rather than with each graphics frame. If this is the case, then surely iz3D must be aware of the problem. If they could correct it to send through usb then surely they could send the sync through the existing interface just as easily?

Or is it a problem with the current glasses controllers? I am not sure exactly what problem you are hoping to solve with this box as I don't yet have any shutter glasses and am not familiar with the technology.

I would like point out that if the makers of the driver are willing to support us, the glasses could probably be controled with the parallel or serial port with no hardware needed apart from an adapter to make the plug fit. People often regard these ports as a dying technology, but the fact is they are perfect for our purpose as this would elminate the complicaton and expense of using a microcontroller. I have not checked myself, but have been told usb to serial convertors are available for people which don't have a real serial port.

Anyway, I am happy to help if I can, but any code I wrote would be for msp430, and nobody seems to use those.


edit---
If what cyberreality said is correct, it would likely be extremely easy to make a box that looks like a vr920 to the computer, then outputs sync to the glasses. Hopefully someone who has worked with usb can give more info. Maybe I will look into that tommorow, it is my bedtime!

[Tril]

The thing is that when the refresh rate is 120 Hz, you need to display a different eye each 8.3 ms. That speed is necessary if you don't want to see flicker. Rendering for one eye can take more than 8.3ms. That means that you can't render one eye and display it for one frame, then render the other eye and display it for the next frame. The rendering is not ready in time.

A solution is to keep one frame of each eye in memory. If a new rendered frame is not ready, you display the previously rendered one. That's what the NVIDIA stereo drivers do. The way DirectX works is that you send commands to the video card to tell it to render and to display. If you could do multi-threading rendering with DirectX (rendering in one thread and displaying in another), you could make the rendering thread low priority and the displaying thread very high priority (so high that it always displays a different eye at each frame). From what I know, DirectX can do some multi-threading and put priorities one different programming task but it does not work good enough for our purposes. You can never get the displaying thread to always display a different eye each 8.3 ms, it just does not have enough priority.

NVIDIA might be bypassing this DirectX limitation by having special rendering code directly in the video card driver.

So, the problem is not that the sync signal is not displayed properly. Having a sync signal that is correct for what the video card outputs would not work because the problem is that the video card is not always displaying different eyes at 120 Hz. Sometimes it shows the same eye for two frames or more. If you had a sync signal for that, you would see flicker because you are running lower than 120 Hz.

The VR920 probably has internal memory for both eyes. It uses a resolution of 640x480, so it has 614,400 pixels to remember. A resolution like 1680x1050 has 3,528,000 pixels. You need 5.7 times the amount of memory for the higher resolution compared to the lower one. Memory is expensive. You would have to make some adapter box that you put between the video card and the glasses. You have two choices, you either make a box that has dual DVI/VGA input and single VGA pageflipping output OR a box that has single DVI/VGA input + a sync signal input and a single VGA output. You put some memory in that box and you need a lot for two 1680x1024 frames. You need some good and fast electronics to read and write the DVI/VGA inputs and outputs. The price of such a box would be expensive, even if we could make one and sell it at the making cost. In the end, it might cost as much or more than NVIDIA 3D Vision so if you plan to use shutter glasses, you might as well get those. Unfortunately, that means that you are forced to use an NVIDIA video card and you can only use their stereo driver.

EDIT : What that box I mentioned does can be done on the video card by storing the two frames (one for each eyes) on the memory of the video card and by the card displaying those two frames in turn at 120 Hz. NVIDIA showed that it's possible. What I'd like is for NVIDIA and ATI to offer some way for the programmer to tell the video card display driver that the next rendered frame needs to be put in memory and for what eye and the card drivers would take care to displays them in turn from memory instead of displaying the last rendered frame. You would have pageflipping support and anyone could make their stereo 3D driver that interfaces with this. That would be something nice for ATI to do to compete with NVIDIA.

[UndeadD3vi1]

iz3D will not be playing any part in this. BlackQ read my PM but didn't even reply (How rude!)

VR920 has its own L/R Framebuffer like Thril says. iz3D tells it when the GPU is rendering a L or R frame. I could write a wrapper to pick this up easily. (IWRSTEREO_SetLR and IWRSTEREO_WaitForAck for example)

Thril, what about taking a step back and thinking in 2D, using Off-screen 3D Rendering. Caching the rendered 3D and displaying it via 2D. 2D would allow us to instantly display the required data from the cache correct? Either way iz3D apparently recently got a Lightbulb and said 2.0 will solve this issue. (Read this on iz3D forums)

And iz3D can not at present send any sync signal to Page Flipping shutters via DDC!, this is the main problem! I do not see where you lot are getting the impression that it suddenly can. PF shutters hijack the non-usable DDC. Interleaved, etc are a different story.

The way I see it is Problems only exist to be solved. People working together can solve any problem! We are just throwing ideas around here, but I'm sure if we keep at it we may find a usable solution.

[Tril]

How do you display via 2D? Currently, in Direct3D, you do 2D by drawing a texture on a square made out of two triangles. There's no more true 2D like in the time of DirectDraw. I'm not entirely sure as that was before I got interested in 3D rendering but I think that DirectDraw was more powerful because you could directly alter memory and swap the buffers yourself when you wanted. I think DirectDraw still exists but you can't call it yourself anymore, it's internal in DirectX.

We'll see about 2.0 when it's out. If they talked about it, that must mean that it's very likely to work because normally, you generate hype when you know you can deliver the goods.

Of course, throw out ideas. It's best to suggest something that does not work than not suggest something that might work.

A VGA cable has red, green, blue, vsync, hsync and DDC pins. Normally, it's only easy to manipulate the red, green and blue. The product StereoEnabler uses blue to tell which eye it's displaying. I think it works using one of the following methods :
-it looks at the first or last line of pixels and it detects if it's black or blue
-it looks at the first or last line of pixels and it detects if its first half or last half is blue.
That is something easy to do program. Support for that is in the iZ3D driver.

This product only works for some expensive glasses so it's not directly interesting for us but it's possible to make one.

A similar product is not a very high speed project so it would be a cheap and easy product to make with a microcontroller and a few other components. You could intercept the blue line and display it black on screen so that the blue line is not visible. This solution still depends on the speed at which the card alternates the left and right frames. You could make this product generate a sync signal on the DDC pin and you would plug it between the video card and the glasses dongle OR you get rid of the glasses dongle and you put a glasses connector on this product (but you need to design it specifically for each brand of glasses because they don't all have the same connector and wired the same). I'm saying it's not too hard because I've got some experience with Atmel 8 bit microcontrollers and it seems possible to use this design with that or any other type of basic microcontroller.

[bob_shaftenkluger]

Here is a link for parallel port software. I managed to use this to write a program to light leds based on cpu usage as the second pc program I ever wrote, so I'm sure you could figure it out if you can make the wrapper.

http://logix4u.net/Legacy_Ports/Paralle ... NT/XP.html" onclick="window.open(this.href);return false;

If the gpu is currently rendering a right frame, then this means it must currently be displaying a left frame? I dont know the specs for the sync signal, but I guess it will be a pulse for each time the eye should change. Could you write a wrapper that, for example, switchs on pin 8 of the parallel port for 2ms each time the gpu changes sides? Unless I have missed some thing, that would be pretty much it for the software.

I guess the refresh rate flicker problems are just something we will have to live with. Even if we could make some sort of framebuffer to solve this, I think a better solution would be a more powerul graphics card that didnt drop frame rate to begin with! The first system mentioned by Tril is very different from what I had in mind.

The nvidia glasses are not an option for me, as I would have to replace my entire system to use this. I would have to be very desperate to buy anything made by nvidia due to there poor driver support. <SNIP-- Big rant about nvidia removed, I used to like them, now not so much. You know the story, I wont make you read it again>

Addition, you posted while I was still typing"----
I think my idea is preferable to your second idea Tril as it wouldn't require a microcontroller. A simple transistor, or maybe nothing at all would be needed.

Edit--- if 2.0 suports the glasses properly, then this is kinda pointless anyway!

[cybereality]

I don't mean to rain on the parade, but is interlaced mode really that bad? I mean, most shutters can support interlaced and that appears to work perfectly right now with the iz3d drivers. Is page-flipping really that much better that we have to go through all this trouble? Serious question here.

[bob_shaftenkluger]

Is interlaced really that bad? I have no idea, I have no glasses! I didnt actually know there was a mode that worked. How on earth can the sync get through for one mode but not another?

[Okta]

Interlaced really sucks on a crt i know that much.

[Tril]

Is interlaced really that bad? I have no idea, I have no glasses! I didnt actually know there was a mode that worked. How on earth can the sync get through for one mode but not another?

It does not use any sync. Both eyes are in all frames. Left eye on odd lines, right eye on even lines (or the other way around). For a frame, it displays black in place of the odd lines and lets the even lines through. Then at the next frame, it displays blacks for the even lines and lets the odd lines through.

I looked inside the Another Eye 2000 dongle to see how it's made inside. The dongle of the glasses contains a small FPGA. The FPGA controls some electronic components that either let the input through to the output or that connect ground to the output, thus displaying black.

Because you see half the lines black in each eye, it's appears darker than pageflipping which, is darker than normal 2D use. I'd say that the worse part, apart from the visible horizontal black lines. Like Okta says. It's too dark on a CRT monitor.

[UndeadD3vi1]

The only way Page Flipping will ever work is if iz3D can control the render output precisely or if we create a Frame Buffer device to sit in between the GPU and Shutters + USB to control it. We'll just have to hope that the following quote does indeed mean what it suggests.

Posted: June 09, 2009, 06:41:48 AM
I'll take your bet Smile We'll be ready in 2.00

and last month we had significant progress with different ways to support shutter - I hope shutter owners will benefit out of this soon

Link to Quote from iz3D Forums

If iz3D have found a solution to controlling the rendering thread, then the original idea for this device would be required. (To get around DDC which is allways going to be a big issue)
Appologies for thinking that DirectDraw would be the solution to the rendering. It used to have all the feature required to pull off what we need, but ah well. Thats Microsoft for you.
Maybe the best thing we can all do is start pestering nVidia + ATi as Thril suggested, but I doubt nVidia will do anything.


Personally i'm going to get some Interleaved glasses for the time being and hope v2.0 does indeed have it solved.

[Okta]

Will the newly released preview catalyst driver help any with this project?

[Tril]

It will eventually work with the iZ3D page-flipping S3D driver and ATI video cards but maybe only with some specific glasses. You probably already read about it in the following thread.

Coming soon iZ3D driver with Bit Cauldron shutter glasses

[Slah]

Try WinSGL. It requires Powerstrip and a parallel port. It will output the Vesa signal on pin 10 (ACK) of the parallel port. Haven't tried it yet. Read this for further information (page is down atm).

[Slah]

Sorry, this information was incorrect. The software syncs the vga frequency to the input signal on pin 10.