@genetic

Sorry mate, I returned my Z800 a while back because of screen problems. I meant to get another one as a replacement but then nVidia killed the stereo driver

If it works with the iZ3D driver, I do plan to get one again

-- Shahzad.

1) DDC signal works in market mode now?
2) Simple shuter can quratee strictly L-R-L-R output from card? I hope to this in full release, but it looks imposible (for non brutal Hi-end Graphic cards).
3) Iz3D hasn't buffer for each eye only scene rendering is sequential (L/R). This is cause for random L/R output on low end hardware (I mean..)

@Luke
you said VR920 is working. I tried it on my xp 32 8800GTX computer with driver installed. All i have got was the possibilty to change seperation, but it seperated the two displays the same amount, so there was no S3d.

Well said that man!

Hi all,

I just want to add my experience with the new driver :
I'm quite happy with it because it works with shutter glasses in interlaced
mode (with lineblanker). many games that dont work with nvidias driver work great
with iz3d ...very nice ... (3d adventures mostly...)
The iz3d driver is really much better than nvidias one ... !!

For now only with CRT ... in hires ...
It would be great if it would work in real pageflip mode ....

With shutter I have only flickering image ...I wonder if this could be solved
with additional hardware ....as mentioned above.

@chrisjarram .....you said something about stereographics emitter/controller ..
I've found some "stereo enabler" ...could this work with "marked shutter" .. as a controller ??

http://reald-corporate.com/scientific/stereoenabler.asp

" The StereoEnabler is an intelligent pass-through VGA connector for the
monitor and outputs the stereo sync signal to an infrared emitter or
ZScreen controller via a 3-pin mini-DIN plug. The sync signal is
transmitted to the StereoEnabler by coding the bottom raster line of the
video signal (blue-line code) and the intelligent controller generates the
pulse signal from this video signal. Additional power required by the
emitter is achieved by plugging in the PS/2 connector on the
StereoEnabler into the keyboard PS/2 connector on the PC. The emitter or
controller interprets the sync signal to shutter the eyewear or ZScreen to
separate the left and right eye images, giving the user the ability to view
in stereo...."


what do you think ?

regards

steps

Hi everyone!

I read the whole thread and humbly and honestly didn't understand a word of what you are talking about.

I installed the new drivers and tried shutter, S3Dshutter and interlaced options, but none worked for me. It's probably my fault, since I'm new in the forums and my knowledge in really basic. I can't help in anything to the development of the driver though, and as many of the people in the forum I only want to try to selfishly make it work for me. :/

Since there's a lot of people in the same situation as myself, maybe it would be interesting to open a new thread with Laymen terms where we can speak without bothering your awesome help to iz3d. (don't get me wrong, I mean it).

thanks everyone, and keep going!

I thought it just wouldn't run with 64bit... It seems I mixed up some of the stuff here... Well it was realy a lot to read for just half a day or so

In that case it looks not so good, but at shifting the images is a good first step. At least it's not flickering and swapping images like crazy, is it?

I think we'll have to wait for next beta and continue to test. Good job all of you (except me, who hasn't even installed the driever jet ).

@ gozne: I think it will need some work and maybe some (small?) hardware solution to shutter right.
I don't own ED glasses, but in theory they SHOULD work with interlaced driver

@genetic
@RAGEdemon

My Z800 works with the iZ3D driver.
I am impressed!!

No there was no flickering in VR920 mode. Tried all 3 modes left,right an cant remember the 3 option, no S3D only shifted images. Tried it with Life for Speed and if i gave more seperation the cockpit shifted right out of the screen while the background stayed almost there. So there is hope of a fast delivered version 1.09a

Hi,

That does look interesting, though I'm not sure how the compatibility would be with more common products like eDIm - addtional hardware may still be needed. _However_, I think if this can generate the sync signal (as a rise / fall for each eye) according to a blue line signal on the bottom row of (for example) each image and just output that at a DDC code via a standard 3-pin sync cable it may well be a much more ideal solution than the WLC (White Line Code) I have already discussed with iz3d. WLC would only be supported via more expensive Stereographics emitters, but this cheaper solution may allow us to work with many different shutter glasses (which can take this standard 3 pin DDC input).

This would solve both the glasses signal generation and the frame ordering problem.

Could a few others please look at this and offer input? What do you think?

Vadim, could you possibly investiage this too? This product is only $89 so is affordable to most if you could support the Blue line code with your driver, and it may be a very good intermediate solution to the problem.

Thanks for your input, steps!

You know, that you still need a high power GPU to run it then with little flickering?
This device would only create the signal, so if the output is 50FPS (2D) then it would be about 25Hz for each eye, since the signal is slower than the actual frame rate. But if you have highend GPU compared to the game then you should be able to get a reasonable refresh rate.
But maybe interlaced with a higher resolution would do the trick , too

summery:
FPS = refesh rate in Hz
before with NV driver: FPS maybe half of refresh rate

This is great news!!

thank you for finding that out.

did you have to uninstall the Nvidia stereo drivers or can you just deactivate 3D in the control panal?

how long have you been in Japan?

Hi, yes, I do know that
Interlaced = imo not an option for projector setups, especially higher end ones, good for testing maybe but I'm not about to ditch my 7900 for a 9800gx2 in interlaced mode. Yes, obviously you'd want a fast machine (not just GPU) for this BLC solution too - this is why I suggested it is only an intermediate option (for those that are lucky enough to have the power), but ultimately we need dual buffer page-flipping, simple as. I think what you are saying though (and the fact this thread has hit 1300 views and shot to the top of the hottest topics in the space of 2 days) is enough to show iz3d just how important (and lucrative from a profit standpoint) fixing this problem is. The BLC is something they can do very easily pending a full h/w pageflipping solution, thats about where we are at the moment.

But yeah, you'd want 85fps minimum to be able to keep things barable on the eyes, not really ideal. Perhaps then it is better to just focus on the HW pageflip right from the start so people dont waste money on hardware they dont need (or doesnt give satisfactory results); again though this raises the rather surprising point that iz3d havent even yet at least been able to guarantee LRLRLRLRLR output with no ordering loss. This was talked about long before the release of this 'beta' software so thats not really a good reason it hasnt been checked yet. Guys, lets fix this and change the world!

I set the resolution to 800*600 in GTR2, turned off all the details, everything on low, set the refresh to 60HZ and it's perfect stereo with shutterglasses in the game. If the fps go under 30 (60Hz/2) it turns to garbage, but over 30 and it is perfect (besides the headache inflicting 30Hz refresh of course).

Thats no surprise, we know if your card can keep up then the stereo can potentially work. 60hz though? yeuch tbh though I didnt really upgrade my graphics card in anticpiation of this new driver to play GTR2 at SVGA resolution with all details on low!

Hi all; i too have tryed with the VR920 but i´m getting a different problem; the image in the left screen is displaying the two perspectives at the same time the left and the right verticalli streched one in the upper half of the screen and the other in the lower half, the right screen displays the correct image for the right.

Also have tried the two shutter modes on the VR920 because there is no reason for shtter to not work in the VR920 like it worked ever with the nvidia driver but when i manually select left or ricght first stereo mode the image on the VR freezes on the same frame for the two screens in the visor but it still changes and continue running on the normal monitor,,
What a mess.. u supose i must report all this "bugs" on the IZ3D forums for they to be revised..

that is with GTX280, right?
I'd expect something better from that card (if it is not your PC slowing it down )

Well I think with these Hardware solution you should be able to get less flicker with quiet scenes and no "garbage" when frames drop...

I think the backbuffer stuff is NV's area and it needs access to the hardware. But I think it was said or at least hinted at before the release...
--> try to ask ATI for their backbuffer support

It is with a 7900GTX, the 280 is gone, too much heath. But yes, as long as the card can keep more than your refresh the stereo works and stays in sync. Just testing, of coure it can't be used at 30 HZ.

Exactly, iz3d need to fix this backbuffer support (on nvidia cards) or imo shutters are pretty much a no-go. I'd have thought it should be a priority tbh when you look at the number of views on this thread (most ever in such a short time on mtbs?)

oh sorry man...
Maybe you have more luck with the next one

If that results above were with gf7, then it's ok. So its easy to get a good FPS with recent hardware and then you have at least a good fram rate when the hardware works

I only hope it CAN be fixed, because they might have no access to the hardware/backbuffer as a 3rd party. When you make the game or the hardware driver it's much more easy!

There's no way it will work at high refresh rates, the 280 was "only" doing about 35-40 fps average on anaglyph at high resolutions, and it won't get much faster at lower ones like 1024*768 because it's really a high resolution card and doesn't improve a lot at low resolutions with cpu limiting and all that stuff. Plus not everybody has the latest stuff. We have to get it fixed somehow.

It will be fixable. There is no legal license restriction allowing nVidia to be the only ones allowed to utilize any particular part of the hardware, so there is no excuse this can't be fixed really - even if nVidia refuse to help iz3d (speaking from a software engineering perspective) should be able to easily trace the execution of nVidias own driver to ascertain how this is being acheived... There are all sorts of tools out there for purposes such as these, which allow them to monitor low-level API calls and therefore replicate them.
There is nothing nVidia can do that iz3d cannot - if the hardware is there it is a case of research and implementation, to be honest we were all thinking they had done this before the beta release hence the point in including the 'simple shutter' mode in the first place. I just hope after the extremely long wait by countless members of the community for this shutter functionality (following all the hype and suggestion this was being introduced) we aren't all going to be sat waiting around for another month for this to be working

Not to sound patronising (again?) but has anyone tried googling "nvidia backbuffer" or "access nvidia backbuffer" - there seems to be a ton of info. Also came across an interesting thread discussing the issue, was going to post link till I realised it was posted by our very own Tril and you guys probably already know about it.

Also came across posts about RivaTuner being able to manipulate the Backbuffer. Perhaps one might try sending them an email asking how they did it?

Just a few suggestions that i thought *might* help

Hmm... and what if iZ3D will cooperate with Ati (..now AMD of course ) S3D is dynamic technology and this choice will be favourable for both. (end of nVidia absurd S3D leading without S3D support)

You don't, mainly because backbuffering is not what we are discussing here - it is pageflipping I saw some things about rivatuner being able to treat older nVidia cards as Quaddros (to utilize openGL quad-buffering for example) but that was Geforce 1-3 series. All backbuffering does is allow you to draw to one buffer while the other is displaying, and swap them out when drawing has finished (to eliminate render flicker). With pageflipping, you need to be able to have 2 of these backbuffers and 2 front buffers (which can be 'page-flipped' between), one for each eye. So, you draw the left and right and when they are both ready move them to the front buffers for the output to flip between at 85hz (or whatever) while the back buffers are again being repopulated.

Are you talking about a thread I started at gamedev? If you are, I'd like to say something about it. I was just doing some experiments to figure out if it was possible to program a shutter glasses mode in DirectX 9. I said it worked in the thread but the truth is that I never got it working completely. I was trying to display at a constant fps (fps that is the same as the refresh rate) even if the scene is rendered at a lower fps than the refresh rate. The solution I tried required Vista because it uses a feature of DirectX 9 that is only available on Vista. What I tried is explained below.

In a rendering thread with a low priority (low CPU priority and low GPU priority), you render to two textures (left and right eyes).
In another thread with high priority (high CPU priority and high GPU priority), you copy the textures from the other thread to the backbuffer and you send to backbuffer to be seen on screen.
The textures are shared across the two threads.
When using DirectX 9 Ex (only available in Vista) you can set the priority of the GPU. This way you can render two frames at the same time and set priorities. The one with the higher priority gets higher fps.

It worked partially. I did some tests at 85 Hz. I was able to display at close to 85 Hz when the rendering fps was lower than 85 Hz. However, there was still some dips below 85 Hz many times per second so it was unusable with shutter glasses. Maybe it's something that I did wrong or maybe it's just impossible to do in DirectX 9 with a slow video card. From what I read, in DirectX 9 Ex, you can stop the rendering between each shader (to give priority to another rendering process or application) but not in the middle of the shader (Source : Greg Schechter's Blog - The role of the Windows Display Driver Model in the DWM). Maybe this is why it's hard to achieve what I tried to do in a recent game with shaders that are big and complex and that take a lot of time to render. Or maybe it's something else. Based on the link I posted, the method might work better in DirectX 10.

In my test, if I forced the rendering to be unnaturally slow (by adding a wait time of one second between each rendering loop, thus rendering at 1 fps), it did work at displaying at the refresh rate of the monitor. Maybe you could get it working by manually slowing the game rendering a bit (not as much as I tried) to be sure that the display fps is constant. It's just a wild guess but I'm thinking that the problem could be caused by a synchronisation problem between the CPU and GPU. The GPU can calculate up to 3 frames in advance. When it has three frames in memory, it stalls and waits for the CPU to catch up. When it's waiting, it probably stops executing commands sent to it. It would be fine if it just stopped the rendering but if it also stops the displaying, it can't keep the fps exactly the same as the refresh rate.

I'm not sure this method can be used in a S-3D driver like the one from iZ3D (even if it could, it might not work). To use the method, you need to render and display in two separates threads. It's easy to do if you have the source code of a game and design it that way but I'm not sure that you can do it and get stable results if you do it in code that modifies the game code on the fly. The difficulty is that DirectX is not too multithreading friendly. If you do render in two threads (like this method needs) but do it incorrectly, DirectX gets unstable and you get random crashes or slowdowns.

Sorry for the long post.

I see. Very interesting indeed. I think this is the first time the goings on in the graphics card are being discussed in so much detail.

I'm a hardware guy... don't know much about the software side (hated having to do anything but low level programming back in education), so like for most people here, this thread is a great education too.

There is a utility that neil made us aware of a while back called D3D overrider which comes in the rivatuner bundle. It creates a third buffer so you can do triple buffering in D3D. the person who created it must know quite a bit about buffers and how to manipulate them. Perhaps asking him for some help might yield some results? Even if you can't get access to the backbuffer, with his help, maybe you can create other buffers which can act like the back buffer which you can have complete control over?

What about purging the D3D queue so the command that isn't getting there in time has a quicker path?

Just grasping at straws now

Don't quite know how it works in software... Maybe I'm just thinking of the buffers as literal memory registers on the card which they aren't?

The software threading method won't work as it is, it was something I'd considered but ruled out in my mind immediately for the same reasons Tril has given. In terms of the hardware access afaik iz3d need to investigate the low level routines themselves - I'd be pretty astonished if their programmers didnt know all this already being graphics driver engineers! It is more important time is not spent going down roads with dead-ends; the wheel has already been invented - all they need to do is copy it

From http://www.orthostereo.com/geometryopengl.html:



What iZ3d had to do for software based page flipping is to realize quad buffering for DirectX. In opposite to the dual output methods (native iZ3d, planar, mirrored etc.) this would require driver level manipulation.
Of course nVidia is in advantage here, because they can control the behaviour of their driver and implement this stuff easily.

But iZ3d would have to analyse how the driver for different video card vendors (namely nVidia and AMD) work and try to intercept and manipulate its functionality regarding the left/right front/back buffer swapping in perfect synchronisation with Vsync.

This of course could be done, because there exist tools to examine program flow on driver level and also injection tools to manipulate 3rd party drivers, but that would cost tremendous engeneering time and effort.
I do not think that iz3D is willing to do that, as they will not sell any monitor more with this.

Also it has to be seen how many people are really willing to pay $50 to $100 for proper shutter support , so iZ3d may not have a proper return of investment regarding this.

So it looks as iZ3D has to leave this field to nVidia. The iZ3d solution will rely on some external hardware which is able to interpret the L/R markers to generate a stable sync signal for the shutter glasses.

If on the other hand the announced big OEM parter would be AMD, maybe we see finally proper software based IZ3D driver shutter support for ATI cards...

@Tril:

You really seem to know what you are talking about mate. The thread I was referring to was indeed on gamedev:

http://www.gamedev.net/community/forums ... _id=479002

You seem to have a huge amount of knowledge regarding the issues. I'm sure others will find your insight extremely helpful

@chrisjarram

Hehe, quite so. I think one of the issues might be that shutter glasses support was never iZ3D's main focus point so no-one really invested too much time into it for the beta... I guess they didn't think it would invoke so much interest. As you say, Judging from the response this thread has got, I think maybe the good people at iZ3D are reconsidering that stance.

@Nobsi:

I understand what you mean mate. I guess a lot of people won't be able to pay $100 for the driver. On the other hand, I personally would pay a lot more for a proper driver if it meant the use of my projector and a z800 again

-- Shahzad.

hey all,
Not sure if this is relevant at all but Nvidia just released there NVAPI to the public... (or developers...not sure exactly)

http://developer.nvidia.com/object/nvapi.html

thought it might be good for sumthing...... or not

all the best fellas

Interesting. It might be worth checking for iZ3D.

Read this :
and this :


Do they mean DirectX when they say DX? If so, I would be curious to see the documentation of the version under NDA to know what they mean by "ability to control DX rendering not available in DX runtime".

That is very interesting. Maybe this is the ticket to proper shutter support for nVidia cards.

I did a quick check of the API documentation of the public version, but there is nothing regarding frame buffer timing control.

Indeed the NDA version has a lot more to offer and the features Tril has highlighted may be exactly what iZ3D would need.

So the question is, will they take the ball and invest in research here, after all this is a nVidia API and it would not work on AMD cards.

@Tril and shonofear:
Have you put this information in the iZ3D forum so this important info is not lost in this giant thread?

Edit: Ok, I added a link to this posts at the iZ3D forum 1.09 beta section

thanks for letting the iz3d forums know about it,
hope they or sum 1 can make sumting of it though

cheers

"Please note that it may take a few weeks to receive a decision on your application, due to the large number of applicants."..

NOOOOoooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo!

Yes.

... it came in my mind that we could need a kind of black box with two inputs
... set the iz3d driver to
dual output and inside this ..ehm ... magical box the signal is alternately
given to one output including a sync signal ...



..but i dont know if this is even technical possible ...

Looks like the NVAPI solution is a dead end. BlackQ said that they are a registered NVIDIA programmer, that they already read the NDA version of NVAPI and they found nothing useful for their need.

I already thought about it. The two outputs of the video card are not in sync as far as I know. The easy way to know is that if you connect two VGA monitors in clone mode and try to make the shutter glassses work, they will only be synced to one monitor. That means the signals from the two video card outputs are not in sync.

What this means is that we would need a box that has memory. It would need to be able to retain the two last frames of each eye in memory. When you get to high resolutions, the frames take a lot of memory.

24 bit/pixel.
1600x1200 = 1920000 pixels
1920000 pixels x 24 bit/pixel = 46,080,000 bit = 43.9 MB/eye
43.9 MB/eye * 2 eyes = 87.8 MB

Such a device is possible to make but making a device with that much memory is a bit out of the reach of diy community (too costly and too hard to make). It would probably need an FPGA with some RAM and some high speed analog-to-digital converters on the input and some digital-to-analog converters on the output. The nice thing about such a device would be that you could make it output any frequency and you could also make it support DVI as input.

I think calculation is off by a factor of 8. 24 bit/pixel = 3 bytes/pixel. So it should be around 11 MB (megabytes) instead of 88 MB.

=====

Why can't IZ3D driver render into quad buffers (front and back buffer for each eye) and then brute-force copy the correct screen to the "real display buffer" at the right time? For example, 1920x1080 = ~6MB per buffer. If we run at 120Hz, we will be copying 120 times per second, which is about 720MB/sec. Modern graphic cards has memory bandwidth like 50GB/sec or more, so <1GB/sec copying should be doable.

didn't you mix up bit and byte here? 46Mbit /8 = roughly 6MB. But it is still too much for a good DIY project...

I'd go more to the interlaced image with 2times the resolution. That way you had perfect sync and if you wouldn't write these 'black' lines you would get full resolution, too.
Would that need memory? I think not, but might be mistaken