This forum is monitored by iZ3D Support Staff and Stereoscopic Veterans.
However, please keep in mind that for iZ3D to find a solution, we need as much information about the issue as possible.
You may also fill out an iZ3D Support Ticket here.
Joined: 07 Oct 2005 Posts: 3573 Location: Airplane
Posted: September 08, 2008, 11:12:41 AM Post subject: 1.09 BETA SHUTTER and MARKING
Hi, everybody!
Let me first say a bit more about shutter. Using V-sunc we can guarantee LRLRLRLR from GPU with frequency defined by game. Then shutter device is coming to read this LRLRLRLR. If reading frequency is higher then sooner or later shutter device will either skip on frame or will show two R or two L - I assume this is the reason why some people got results, some did not.
We can not send any voltage signal from VGA / DVI - we have not access to this level, unfortunately. We can work with shutter device API as in case of VR9200 - it works.
Now about marking: you are free to change it. XML file we published has set of mark inside. If we have, for example, four mark as now it means that first frame will be marked by first mark, second by second etc etc and then by cycle. Each mark is just a line of defined color with number of pixel defined by lenght of line in mark description. If you want White Line af ter each frame you need to left only on mark and make it FFFFF 1680 times to make 1680 pixel. So, you are free to generate any specific signal you want.
We are still thinking how to make shutter more compatible - so, any ideas are very welcome here.
Posted: September 08, 2008, 11:45:14 AM Post subject:
Thank you BlackQ for the explanation of how to modify the making specs. I tried and it worked.
The file is in the folder :
XP: "\Documents and Settings\All users\iZ3D Driver\"
Vista: "\ProgramData\iZ3D Driver\"
There's a small bug if the marking specs file is incorrectly modified. If the "NumberOfMarks" is bigger than the number of marks, it crashes when the game starts.
"NumberOfMarkedLines" is the number of lines that have the marking, by starting to count at the top. Would it be possible to add an option to choose if we want the markings at the beginning or at the end of the frame. I think some glasses use markings on the last line.
What happens if the length of the line in the specs file is longer than the number of horizontal pixel? Let's say I make a file with lines of length 1600 but play a game at 1024x768 (so I only have 1024 pixels per line).
Last edited by Tril on September 08, 2008, 07:07:29 PM; edited 1 time in total
Posted: September 08, 2008, 02:07:21 PM Post subject:
Do I understand right, that it is possible to make little squares in white and black as mark? Then it should work with phototransistor and some tinkering - like said at MTBS3D.
There seems to be a problem with reading the backbuffers: the order is not LRLR... for everyone. Maybe contact AMD to get it done for their cards (if it isn't better there) or try to address the backbuffer output different. There seem to be a lot of applications which can do it.
I think this is a short summery of the MTBS thread(s).
Posted: September 09, 2008, 04:11:09 AM Post subject: Dont waste time on solutions that won't yield satis. results
Hi BlackQ
"Using V-sunc we can guarantee LRLRLRLR from GPU with frequency defined by game"
Thats not the issue, the issue is you need to be able to gurantee that at a fixed frequency from the output, not the game. To guarantee this from the game is obviously very easy.
"We can not send any voltage signal from VGA / DVI - we have not access to this level, unfortunately."
This is what you need to find out
"Now about marking: you are free to change it."
It has been established marking will not be sufficient, as it could result in significant flicker with shutter glasses if the frame rate drops below 85hz (which freqently it will).
The only solution here is to use the same pageflipping method nvidia are, anything else tbh is a bit of a waste of time
You need to apply for the NVAPI NDA version, I think this may hold the functionality you require.
Joined: 07 Oct 2005 Posts: 3573 Location: Airplane
Posted: September 09, 2008, 07:47:31 AM Post subject:
ah! I'd like to share your optimism, but we are nV registered developers and nothing we found in NVAPI ..... we read it already carefully - no access to such deep level - may be we missed something important ... but ...
Posted: September 09, 2008, 09:11:26 AM Post subject:
So then you need to have one of your engineers do some sniffing on the low level device calls used by nvidias driver in page flipping mode. This must be possible - shame its not going to be as easy as using NVAPI but thats life.
Posted: September 13, 2008, 06:57:39 AM Post subject:
BlackQ wrote:
we may try at the end of the week - we have one good guy who can help us here...
you know, I'm physicist, but theoretical physicist, not experimental
Hi BlackQ,
Please, please tell us you guys have made some progress with this now We've hit around 4000 views on this topic on mtbs now, it seems the whole world wants this fixed!
Joined: 07 Oct 2005 Posts: 3573 Location: Airplane
Posted: September 14, 2008, 09:22:47 AM Post subject:
Hi, chrisjarram!
Nothing I can say to them unfortunately- they are jumping over their head trying to find solution for this. Good news is that we know a lot of people now who can play if game fps is higher that refresh rate - looks like it is only solution atm. What glasses did you use? May be manufacturer of this glasses can help by releasing small API - you can not imagine how small is VR920 API, but it helped so much... This is just a function:
1. give me left
2, give me right
nothing else !!!
Posted: September 15, 2008, 01:10:03 AM Post subject:
BlackQ wrote:
Hi, chrisjarram!
Nothing I can say to them unfortunately- they are jumping over their head trying to find solution for this. Good news is that we know a lot of people now who can play if game fps is higher that refresh rate - looks like it is only solution atm. What glasses did you use? May be manufacturer of this glasses can help by releasing small API - you can not imagine how small is VR920 API, but it helped so much... This is just a function:
1. give me left
2, give me right
nothing else !!!
BlackQ, this is disappointing Game FPS can _never_ be guaranteed to be higher than the refreshrate so this is a complete non-solution. One frame dropped and the eyes swap, rendering it useless.
It is not the sync signal that is the issue, it is access to the page-flipping buffers. Sync can be generated via a simple square wave converted from the V-sync output of any card - there are extrenal modules out there which convert a vertical sync output to the standard 3-pin DDC signal required by a lot of shutter glasses.
You need to access the page-flipping capability of the graphics card to guarantee a LRLRLR output - thats your side of things. This is certainly a bug as it renders the feature useless without it.
Personally I've had an 8800 working on a CRT with 8800 Ultra running PRAY, with no problems whatsoever, so I know for a fact eDimensional have page-flipping working with their own driver. Certaintly if they can do it, iz3d can.
Joined: 07 Oct 2005 Posts: 3573 Location: Airplane
Posted: September 15, 2008, 06:49:07 AM Post subject:
ED used interlaced as far as I know, not page flipping. Render is one thread process we can not interrupt - saying "sync" I mean glogal sync - not just output sync - to do it you need to have regular insertion of sync function into render process - impossible atm and we don;t know person with expertise to help here atm
Again we are not giving up, but it does not mean that solution will come tomorrow...
Posted: September 15, 2008, 12:44:29 PM Post subject:
BlackQ wrote:
ED used interlaced as far as I know, not page flipping. Render is one thread process we can not interrupt - saying "sync" I mean glogal sync - not just output sync - to do it you need to have regular insertion of sync function into render process - impossible atm and we don;t know person with expertise to help here atm
Again we are not giving up, but it does not mean that solution will come tomorrow...
BlackQ, In hindsight I spoke a little too soon about the marked shutter mode ability to acheive satisfactory results. I've done some testing today with a new GTX 280 and in the vast majority of modern games frame rates in excess of 100fps are acheivable in 1024x768+ - i.e. the res all DLP projector users will be running at. I've done framerate checks with the simple shutter mode and all almost can keep up with the 85hz shutter rate reliably.
Pending a proper solution for the page-flipping buffers here could you possibly please put out a release with slightly better defined marking specs? I'd suggest something along the lines of the following format to be able to do _anything_ we want to support frame-marked devices:-
(if runlength exceeds linelength simply just crop for that line)
This way, the marker xml file can contain exact markings (any pixel, any color on any line) for any screen resolution and any set of pixels per frame. If we at least had this it may be something to work with in the meantime.
Think you could at least get this out reasonably quickly to keep the wolves from the door? For those people with a single projector and shutters (and a dongle like the stereographics Stereo Enabler), upgrading to a GTX 280 would comfortably run most of todays games in excess of 85fps so flicker should not be an issue. Occassionally if the framerate drops a little flicker might be experienced, but for example I am running one of these cards on a TH2G and Call of Duty 4, and the framerate rarely drops below 100fps (and the shutter mode gives typically 50). Slightly older games fly (like rFactor, where I get 250fps at full detail with TH2G) and newer ones can be scaled to work.
Personally I'd be happy to pay for the marked shutter output at this time if it can be scaled to support the above format, on the provision that if a synced shutter mode becomes available the upgrade would be free.
What do you think? If you can do this part, I am happy to purchase the StereoEnabler dongle (which will work with a number of existing SG solutions) the minute this is available, encode the XML file and test, then publish my findings (and the encoded XML) on mtbs. People should then be able to use the marked shutter mode with no sync issues with solutions such as eDim and elsa revalator - though ideally they would need to be purchasing a higher-end gcard for newer games.
