Unigine Native 3D Support!

[pixel67]

WOW! Very nice Neil! I think this day will go down as one of the biggest days in consumer 3D! Every gamer should stand up and rejoice as this marks the very first step towards every Stereogamers dream...The elimination of the 3D Driver! No more 1.5 year delays in driver develpments! No more tweaking required to get the perfect 3D image!

I sure hope they expand support to include dual projection, page flipping, DLP3D, and the recently announced Plasma3D!

Congratulations to the Neil, the folks at IZ3D, and the developers at Unigine for being forward thinking S3D Advocates!

Great days lie ahead!!!

PiXeL

[chilledsanity]

Well that's good news obviously, but being one of the biggest days in consumer 3D is pretty optimistic, I mean that would only be true if every new game engine from here on was going to use stereoscopic natively. I don't think the elimination of drivers is every s-3d gamer's dream so much as actually supporting stereo drivers as well as videocards are supported (which Elsa did once upon a time, and Nvidia has simply dropped the ball on).

Also, I'm not sure it's accurate to call this first stereoscopic engine. While I'm sure this is much more in depth, I know the Quake 3 engine had options for rendering in stereoscopic with the console commands "r_stereo" and "cg_stereoseparation".

I'm not trying to downplay their efforts at all, I just don't think hyper-enthusiasm to the point of being unrealistic helps anyone either.

[Xerion]

There have been many game(engine)s with native stereoscopy even way before Quake3...

[zebrastealer]

Neat, but I'd have to agree with the reservations everyone else has here - how many games will be developed with this new engine? How many A-list titles are in the works with this new engine? How long before the first games are released? I'm guessing - Unknown, Few if any (Yet), and not emminent.

Give me a working stereo driver with the hardware we already have in place and I'll be jumping for joy. Everything else is just possibilities and slim hope at this point...

[wuhlei]

There have been many game(engine)s with native stereoscopy even way before Quake3...

lol so true! any one remember lawnmower man?

[ssiu]

I sure hope they expand support to include dual projection, page flipping, DLP3D, and the recently announced Plasma3D!

Exactly ... it is not "something all S-3D solutions will be able to use" (as mentioned in the January teaser news bit) if it doesn't support all S-3D rendering methods. Otherwise, "waiting forever for support of my S-3D display" is not any better than "waiting forever for driver support".

[Neil]

Hi Guys,

I believe the phrasing used was "modern game engine" because it supports DX 9, 10, and OpenGL. The other issue is it's not just a matter of rendering left and right images, it actually works with proprietary S-3D solutions. Anaglyph, iZ3D (which is not simple L/R), and TDVisor is in the works. Doors are opening for other solutions as well.

Yes, we all want good drivers, but drivers are old school. Drivers are band-aid solutions used to compensate for the S-3D compatibility that is lacking in current games. The long term goal should be native game support that works 100% of the time right out of the box. No learning curves, no fiddling with settings, just beautiful S-3D the first time.

Unigine is brand new, they have some exciting projects in the works under NDA, but more importantly, if the other game engines see the ease and benefit of adding this functionality to their engines, this is a very important step for our industry.

Regards,
Neil

[NITRO1250]

If I could afford it, I would buy it for testing purposes only.

I also have a contact in the VR system at my university and I'm going to get him the info and perhaps we can switch over to a nicer VR system with some funding in the future... which if it pans out could land me a future teaching position when I get my ph.d. in a few years.

[pixel67]

Hi again Guys.
I have to say that I really thought I would see more positive comments regarding the announcements today. My enthusiasm regarding the CES2008 announcements (plural), has more to do with industry advancement as a whole than the single accomplishment of coding IZ3D support into a game engine (I don't own an IZ3D monitor and don't use anaglyph). What it DOES mean is that the influence of MTBS is being felt in the marketplace! Helping these three companies work together towards a common goal is what we are here for, and the industry benefits from this in the long run. A lot has changed since the Elsa and Wicked3D days. The reason S3D didn't catch on years ago is simply because there wasn't a decent and affordable display solution available. The preferred desktop solution was a high refresh CRT while the living room gamer had passive projection. There were always trade-offs (ghosting and color issues with anaglyph, ghosting and flicker on page flipped CRT's, headaches and eyestrain if you spent more than an hour in S3D, etc...). Not really the promised land when the average gamer can't see past the side effects, eh? Then comes widespread proliferation of the LCD monitor that nearly wipes out S3D capability on the PC entirely. It's no wonder Nvidia's support for 3D has been lackluster as the display market was pressuring them, pushing high resolution gaming and not S3D. Hence the birth of SLI. SLI wouldn't be needed much if we were still gaming at 1024x768 or even 1280x1024. Essentially, the display industry is in the drivers seat announcing products before they are even supported by the underlying hardware and software.

Now, within the last 12-18 months alone, there have been at least 10 CONSUMER Stereo3D display solutions announced (IZ3D, Samsung DLP3D, Mitsubishi DLP3D, TDVision VGA and HD HMD's, VR920, Samsung Plasma3D to name a few). The release of these display solutions means the tides are turning again. Just as the introduction of high res LCD monitors have practically killed CRT's, the introduction of multiple consumer 3D solutions for the desktop and living room represent the end of simple 2D displays. No, it won't happen overnight and will take MANY, MANY years but it will happen as the previously mentioned side effects of S3D are eliminated and S3D becomes a required feature, even if you still only have 2D over cable and satellite. THIS is what I am excited about! As I mentioned before, I don't own an IZ3D display but do hope they sell like hotcakes along with every other new S3D display solution as this creates "the need". The solution for "the need" is defined next.

Who's job it is to develop 2D to 3D drivers for all of these display solutions... We have seen considerable advancement in this as well over the last 12-18 months with IZ3D and TriDef producing drivers for some of the newer displays, but not all of them. Game compatibility is real challenge for them! The industry just can't seem to standardize this critical piece of the puzzle for several reasons, the biggest being that the vast majority of todays game engines weren't designed from the ground up to support S3D and this needs to happen first before the rest of the pieces of the S3D puzzle will fall into place. In my eyes, every game engine should be designed to render a stereo pair natively without intervention from any third party. This means native anaglyph, field sequential, and dual channel all rendered perfectly with every last supported feature of the engine enabled. So what does IZ3D, Samsung, Mitsubishi, and other provide? Simple. They format the already rendered stereo pair so that it works with their particular display, and no more. No need for yet another third party to hack a perfectly good game to extract and reformat data which today varies wildly from game to game. The game developer knows that by rendering a perfect stereo pair that they are providing the lowest common denominator required to support all 3D display solutions. Every last one. And the display manufacturers can be confident that they always have a gold standard stereo pair to work with that will insure fast adoption of their display. Having native support for IZ3D and Anaglyph in Unigine is a good step in that direction as they are providing the stereo pair, but they also need to provide it in a manner that the rest of the industry can use. We really can't expect them to natively support every last 3D monitor in the world, especially if the display industry continues their march for S3D perfection. But they can take charge of the lowest common demoninator, and Unigine has done just that. Now, EPIC, IDSoftware, Crytek etc should take note of this advancement, recognize the current movement in the display market, and follow suit so that we all can enjoy perfect stereo out of the box on all games using their engines without waiting on a middleman (Nvidia, AMD, TriDef) to make the hacks work correctly. That first step just happened today...

Cheers!

PixeL

[DmitryKo]

I don't think incorporating native support for every proprietary stereosopic 3D format into game engines is the best solution in the long run. It's like returning to the good old days of 3D-accelerated DOS games, when every game developer had to support software rendering PLUS a bunch of proprietary APIs from different hardware vendors. Only by 1999, when every single vendor came with DirectX 6/7 and OpenGL 1.1 parts, game developers could switch to hardware-accelerated rendering paths. A unified set of APIs is what really made the 3D gaming breakthrough possible.

The situation with stereoscopic 3D is pretty much the same. Today, game developers are largely ignoring S-3D compatibility, and S-3D hardware vendors are simply hacking things in a way that is non-optimal from the performance point of view. The ultimate solution would be hardware-accelerated rendering of stereo buffers, that is without the need to re-render the whole scene twice in a row - something like Quad-buffered stereo on the Quadro line. All in all, modern D3D10-class hardware already supports multiple rendering targets, so hardware stereo rendering buffers would probably require only minor modifications to existing hardware, but will provide substantial performance benefits. I suppose it could be part of the reasoning why the newest S-3D driver from NVIDIA only supports 8800-class cards.

If future versions of major 3D APIs, specifically DXGI/Direct3D 1x and OpenGL 3.x, provided API support and hardware specs for native stereoscopic rendering, as well as an extension mechanism for S-3D monitor vendors to define their proprietary display formats, THAT would really be a breakthrough solution. It would make any game automatically support S-3D, provided the developers followed S-3D compatibility guidelines. But of course there's the same chicken-egg problem: until there are significant number of S-3D displays, major 3D APIs are not going to support S-3D natively, but until there is support from major 3D APIs, there will be no substantial market share of 3D displays, and game developers would have little incentive to design S-3D compatible titles.


I'm personally looking forward to getting a Zalman ZM-M220W 22-inch monitor based on 1680x1050 TN+F panel with line-interleaved polarization fiters. It provides decent stereo image quality at a marginal increase in price, and it's fully supported by NVIDIA 3D stereo drivers. Hopefully, I will be able to get it for it's projected MSRP of $700. Since the vertical resoluton is halved in stereoscopic mode, I would prefer something like a 26" 1960x1200 TN+f or maybe 30" 2560x1600 PVA/IPS; hopefully other display makers will follow suit with higher-resolution panels. This could be the kind of simple S-3D solution that would make the mass-market breakthrough and open the way for broader S-3D support.

[Nil Einne]

I agree, there needs to be a spec in the consumer APIs. That spec is already in the professional API (supported by both Nvidia and ATI) we just need something similar for the consumer ones. Adding support to engines is all well and good but it's not going to last in the long run since a solution which requires developers to manually maintain code for each device is simply a bad idea. I'm not sure but I don't know if this necessarily has to come as directly part of DX or OpenGL. It may be the best way to do things but I think the stereo 3D vendors could probably come up with something of their own if they have the will. Think about it this way. The engine that's been mentioned is using DX fine. It has manual support for a bunch of hardware configs. What would be good would be if the engine could just rely on a stereo API. Each hardware developer just needs to make drivers which support this stereo API. Sure it would be better if it's actually part of DX and OpenGL but it isn't actually necessary.

In terms of this game engine, as others have said it isn't really a major engine. I suspect the reason why it's there is either because one of the devs is interested in stereo 3D or the developers are hoping stereo 3D will be the next big thing (and they may well be right) and so by having an engine that supports it they will be well ahead of the big players once that becomes more obvious.

[pixel67]

I agree, there needs to be a spec in the consumer APIs. That spec is already in the professional API (supported by both Nvidia and ATI) we just need something similar for the consumer ones.

Exactly. There needs to be an API that each party develops for, the game developer creates the game that renders the stereo pair which interfaces to the API that S3D Display manufacturers reformat to fit their solution. The line needs to be drawn there. Native support for proprietary solutions is great, but at some point standards need to be developed that everyone can utilize.

PiXeL

[sharky]

great post pixel.. i absolutely agree on every single word...
bye

igor

[DmitryKo]

the stereo 3D vendors could probably come up with something of their own if they have the will. ... Each hardware developer just needs to make drivers which support this stereo API. Sure it would be better if it's actually part of DX and OpenGL but it isn't actually necessary.

I don't expect harware vendors to come with (and game developers to write to) some new 3D API that is different from Direct3D and OpenGL. There is no real need for a separate Stereo API, because everything that is necessary for correct stereoscopic 3D rendering is already present in Direct3D and OpenGL pipeline - that is, vertex data with their associated depth information.


The point is, life would be MUCH easier if S-3D support was coded into major 3D APIs, since 3D hardware and 3D display vendors would be relieved from hacking S-3D support into 3-rd party APIs. Graphics hardware would be responsible for accelerated simulteneous stereoscopic rendering, that is producing two (L/R) images per active frame buffer in one single pass. Stereoscopic frame buffer would be supported right at the resource management and rendering level in the API (DXGI compronent in Windows Vista), and all the heavy work on format conversion would be done by the API, not by 3rd parties. It would also make possible optimisations right at the API level (things like switching to mono mode for far objects, etc.) and unified API extensions for S-3D specific settings like separation, convergence etc. which are currently handled at the driver level.


But of course, the market share of 3D displays should become substantially higher for this to happen.

[Nil Einne]

the stereo 3D vendors could probably come up with something of their own if they have the will. ... Each hardware developer just needs to make drivers which support this stereo API. Sure it would be better if it's actually part of DX and OpenGL but it isn't actually necessary.

I don't expect harware vendors to come with (and game developers to write to) some new 3D API that is different from Direct3D and OpenGL. There is no real need for a separate Stereo API, because everything that is necessary for correct stereoscopic 3D rendering is already present in Direct3D and OpenGL pipeline - that is, vertex data with their associated depth information.


The point is, life would be MUCH easier if S-3D support was coded into major 3D APIs, since 3D hardware and 3D display vendors would be relieved from hacking S-3D support into 3-rd party APIs. Graphics hardware would be responsible for accelerated simulteneous stereoscopic rendering, that is producing two (L/R) images per active frame buffer in one single pass. Stereoscopic frame buffer would be supported right at the resource management and rendering level in the API (DXGI compronent in Windows Vista), and all the heavy work on format conversion would be done by the API, not by 3rd parties. It would also make possible optimisations right at the API level (things like switching to mono mode for far objects, etc.) and unified API extensions for S-3D specific settings like separation, convergence etc. which are currently handled at the driver level.


But of course, the market share of 3D displays should become substantially higher for this to happen.

I think you're missing my point. I'm not talking about a competitor to D3D/OpenGL. All they need is an API to enable stereo support. As I said, look at the Unigine engine as an example. It used D3D or OpenGL. In addition, it also support stereo3D. But to support stereo3D the developers need to code support for each device into their engine which is not ideal. However what I would expect is possible is someone could make a stereo API. Again, this is not a competitor to DX or OpenGL. With the stereo API hardware developers make drivers for the hardware to support the API. Game/engine developers use the API for stereo support. For all the rendering, postprocessing etc they use D3D or OpenGL. If stereo mode is activated then the engine knows it needs to render for stereo and it uses the API to do the stereo bit (i.e. communicate with the stereo hardware) and devices with drivers for the API have stereo. Obviously you need to do a bit more since the game needs to know to generate stereo but this is the easy part. As I said, having the API more integrated is good but although I admit I don't know that much about coding, it seems to me as if this is a perfectly resonable path. I repeat, I'm not talking about a competitor stereo API to D3D or OpenGL. Think of the way the OpenAL API or (failed) PhysX API are used. You can use the PhysX API for phsyics or OpenAL API for sound. It doesn't stop you using Direct3D or OpenGL for the 3D graphics. Obviously as I said it's more ideal if the stereo API portion is integrated directly into D3D or OGL but unless I'm missing something I don't see why this is necessary in the short term. What you really need is an API so developers can simply code for the API rather then having to code for each hardware.

P.S. In any case IIRC and supported by the wikipedia article OpenGL (as compared to D3D) is a fairly open API. Vendors are free to make extensions. It would surely be possible for hardware vendors of stereo 3D displays to make extensions. They don't have to rely on nVidia or ATI to do it. If their extensions are well designed and well supported among vendors then it seems likely game developers and nVidia and ATI will use them. This surely means the ARB will support them. This is another example of what I'm getting at. I simply don't see a reason why it's necessary to rely on nVidia or ATI to do this. It's not that there's a hardware limitation simply that no one has bothered to make the API parts. The best thing surely for the hardware developers to do is to pool their resources to develop something which game developers and GPU makers will adopt rather then lobbying game developers and/or GPU makers to individually support their hardware.

[Nil Einne]

Anyone know if Unigine have any plans to include LC shutter glasses, specifically page flip mode support?

[DmitryKo]

If stereo mode is activated then the engine knows it needs to render for stereo and it uses the API to do the stereo bit (i.e. communicate with the stereo hardware) and devices with drivers for the API have stereo. Obviously you need to do a bit more since the game needs to know to generate stereo but this is the easy part.

IMHO game engine has little need to communicate with the stereo driver. The renderer just needs to follow S-3D compatibility guidelines, as outlined in Nvidia GPU programming guide, Chapter 9. (FYI, it basically recommends that rendering to screen-aligned triangles/quads - effects like motion blur, glow, bloom etc. - should either be avoided completely or double-checked for visual anomalies; and 2D overlays - labels, icons, crosshairs, billboards, etc - should either be placed at the depth of the actual object or replaced with actual geometry.)

Of course such communication has some uses, like remembering individual S-3D settings in-game or turning off incompatible effects when S-3D mode activates (and NVIDIA provides such an API with their 3D stereo driver). But it's not as critical as starting to actually develop games with S-3D compatibility in mind.

Obviously as I said it's more ideal if the stereo API portion is integrated directly into D3D or OGL but unless I'm missing something I don't see why this is necessary in the short term. What you really need is an API so developers can simply code for the API rather then having to code for each hardware.

I'll try to explain. Currently, the burden of S-3D support lies on a particular harwdare vendor, and they have to hack non-standard features into existing DirectX libraries (like iZ3D does) or hack their own drivers with technology developed a decade ago (like NVIDIA does with their driver acquired from ELSA). They are reinventing the wheel over again and the end result is just a mess. iZ3D drivers do not support OpenGL (and probably never will), nVidia S-3D drivers either do not support Vista or Windows XP, or anything lower than GF8800 series, and ATI have no S-3D drivers at all. I was not following other vendor's solutions closely, but I'm sure there are horror stories as well.

Proprietary S-3D drivers have to employ tricks like forcing two rendering passes to build the two stereoscopic images, but obviously this is not an optimal way. What we need is:

1) from 3D hardware vendors - hardware-accelerated stereoscopic rendering to frame buffers, with additional render targets and more pixel processing power;
2) from Microsoft - S-3D support added to both Windows Display Driver Model (WDDM) and DXGI kernel, OS component that performs low-level resource management for the entire graphic subsystem;
3) from 3D display vendors - 'drivers' for their proprietary S-3D encoding schemes (L/R flipping, interleaved, iZ3D, you name it).

This would add automatic S-3D support to every Direct3D or OpenGL application in Windows Vista (I'm talking Vista because S-3D support can only appear by Direct3D 11, which is 2010-2011 maybe even later, and XP will be long unpsupported by then). DXGI would use the hardware-accelerated stereoscopic rendering when available, and could revert to multiple scene rendering like current software-only hacks do. No reinventing the wheel in multiple proprietary S-3D drivers or game engines, everything is handled at the OS level. Game developers and 3D hardware vendors are relieved from the burden of supporting proprietary S-3D display devices.

To better comprehend the graphics subsystem in Vista, here's a slide taken from WINHEC 2005 session TWPR05007, Windows Graphics Overview


(courtesy http://www.activewin.com/winvista/thestateofvista.shtml)

to support stereo3D the developers need to code support for each device into their engine which is not ideal

Exactly the point. Applications should only need to observe the S-3D compatibility guidelines.

OpenGL (as compared to D3D) is a fairly open API. Vendors are free to make extensions. It would surely be possible for hardware vendors of stereo 3D displays to make extensions. They don't have to rely on nVidia or ATI to do it. If their extensions are well designed and well supported among vendors then it seems likely game developers and nVidia and ATI will use them. This surely means the ARB will support them. This is another example of what I'm getting at. I simply don't see a reason why it's necessary to rely on nVidia or ATI to do this.

While 3D display vendors are free to offer extensions (or more realistically, license their S-3D code to 3D hardware vendors, since no S-3D vendor is present at OpenGL ARB), this code must be adopted/licensed by respective video hardware vendors AND included in their OpenGL driver. You can not extend an OpenGL ICD (installable client driver) with 3rd party code, at least not without some heavy hacking. This is where you have to rely on NVIDIA and ATI.

But again, this leaves Direct3D out of question, so a better solution is to implement S-3D support right at the OS level.

The best analogy would be full scene antialiasing. 3D hardware vendors are offering it nearly for a decade, but up until year 2005 it was just a driver hack that would made the scene render at 4x the pixel resolution with a similar performance drop. Most game developers ignored it and never bothered to optimize for it. Only when DX9.0c and D3D10 featured support for maskable MSAA, only then hardware vendors and game developers started to pay attention.

[chilledsanity]

There have been many game(engine)s with native stereoscopy even way before Quake3...

Yeah, wouldn't surprise me, I only mentioned Q3 since I knew it supported it natively as opposed to needing a patch.

A lot has changed since the Elsa and Wicked3D days. The reason S3D didn't catch on years ago is simply because there wasn't a decent and affordable display solution available.

I think that's a little shortsighted, there were a lot of reasons. The shutterglasses were about $50 then, worked on Nvidia cards and a CRT monitor (which were both by far the dominant equipment used in gaming systems). The reasons is didn't catch on are primarily a lack of marketing muscle (hence many people weren't even aware it existed and still aren't), many people don't like ghosting or the flicker, some find it too disorienting. I don't know of any solution that solves all those problems and is "affordable" for the average consumer. I'm taking affordable meaning under $200.

Hence the birth of SLI. SLI wouldn't be needed much if we were still gaming at 1024x768 or even 1280x1024.

Well first off SLI goes back to the voodoo 2 back in 1998, gamers have always wanted more speed. Also I think stats from places like Steam show those actually are the kinds of resolutions most gamers are using. While you do get some slowdown, methods like pageflipping don't mean you need to render twice as much.

Just as the introduction of high res LCD monitors have practically killed CRT's, the introduction of multiple consumer 3D solutions for the desktop and living room represent the end of simple 2D displays.

I think you're being way too optimistic here. CRT's are in many ways still the superior technology, but are dying off primarily due to the market wanting a more compact display. Saying that new 3d displays signify the end of 2d displays is like saying the release of 3D headphones signify the end of stereo ones. Stereoscopy is still a niche market and a struggling one. While everyone here hopes it gets bigger, I don't think you're thinking realistically.

the biggest being that the vast majority of todays game engines weren't designed from the ground up to support S3D and this needs to happen first before the rest of the pieces of the S3D puzzle will fall into place

Yes, but I'd say the majority of games have correct 3D data so that proper drivers can bring it to life. This was the case before the advent of post-processing anyway. Games today have a hard enough time getting ANTIALIASING to work on all systems. I think focus on games isn't the best route as there are already thousands of games out already that people would want to play in stereo.

That first step just happened today...

Well again, while this is obviously a much more advanced engine, I'm not sure how different it is in concept from previous game engines that have supported sterescopy. Personally I think the biggest step for stereoscopic gaming was the introduction of consumer level shutter glasses as it made it possible for a wide audience even if it's been struggling since then.

[pixel67]

Dude, you are the quote master eh? I think you set a record, but not for long! On Quake3, there was nothing on the box that I recall stating "S3D compatible", we just knew it was there through the internet. That marketing message is what we are trying to create. I remember several of the non advertised engines as well, but most were anaglyph only.

A lot has changed since the Elsa and Wicked3D days. The reason S3D didn't catch on years ago is simply because there wasn't a decent and affordable display solution available.

I think that's a little shortsighted, there were a lot of reasons. The shutterglasses were about $50 then, worked on Nvidia cards and a CRT monitor (which were both by far the dominant equipment used in gaming systems). The reasons is didn't catch on are primarily a lack of marketing muscle (hence many people weren't even aware it existed and still aren't), many people don't like ghosting or the flicker, some find it too disorienting. I don't know of any solution that solves all those problems and is "affordable" for the average consumer. I'm taking affordable meaning under $200.

Good points. Marketing was including a set of LCD glasses with the purchase of a video card, and a sticker on the outside of the "GRAPHICS CARD" box. What our objective is here is to get the "MTBS3D Certified" logo on the GAME BOX itself. The user sees it, comes to this website to see what we are all about, and makes an informed decision on whether S3D is interesting enough to make a purchasing change. This is what Neil has accomplished and represents a huge change for the visibility of S3D gaming. Many of those that tried S3D back then, including myself, ditched it because of variances in CRT quality from OEM to OEM. I had to put mine on a shelf for a year until I could afford a good CRT with a much higher refresh rate (eyestrain for me was horrible). Most of the newer solutions nearly, if not completely, eliminate ghosting and flicker, but affordability is still an issue as you pointed out. Vuzix goggles are $400 with resolution being the trade off. IZ3D is twice as expense but doesn't rely on Nvidia, which is turning out to be a good thing these days. But prices will come down as IZ3D, Samsung, Zalman, etc get their solutions to the niche users and introduce the successors to the current line of displays. As Samsung starts to push it's Plasma3d HDTV's, their 1st generation DLP3D sets will go on sale. That's the way it has always worked and is why we have $200 LCD's now.

Hence the birth of SLI. SLI wouldn't be needed much if we were still gaming at 1024x768 or even 1280x1024.

Well first off SLI goes back to the voodoo 2 back in 1998, gamers have always wanted more speed. Also I think stats from places like Steam show those actually are the kinds of resolutions most gamers are using. While you do get some slowdown, methods like pageflipping don't mean you need to render twice as much.

I know, i had a voodoo2 sli back in the day. I remember the tag line being 800x600 with one card, but 1024 x 768 with two and that is why i bought it as well. Same holds true today with Crysis and SLI... FPS is king and high res is queen. Real life performance hits are a real interesting topic. As I mentioned before in another post, it would be interesting to see a graph of this hit at different resolutions with all the 3D drivers that are out there now.

Just as the introduction of high res LCD monitors have practically killed CRT's, the introduction of multiple consumer 3D solutions for the desktop and living room represent the end of simple 2D displays.

I think you're being way too optimistic here. CRT's are in many ways still the superior technology, but are dying off primarily due to the market wanting a more compact display. Saying that new 3d displays signify the end of 2d displays is like saying the release of 3D headphones signify the end of stereo ones. Stereoscopy is still a niche market and a struggling one. While everyone here hopes it gets bigger, I don't think you're thinking realistically.

I will agree that I being very optimistic, but not overly so. CRT IS great technology, but the user base wanted something different. The same way this user base is saying we need something different. In the Voodoo2 days of stereo a CRT was all we had. There simply weren't any other "affordable" options out there. At least not that i remember (getting old you know). Now we have BIG companies (Samsung, Mitsubishi) putting out S3D products. I do think 2D/3D switchable displays will eventually take over the market. It won't be a marketing take-over, meaning you won't wake up one morning and see a full page banner on yahoo stating these displays are taking over just like S3D isn't the first spec you see listed on their displays, but i do think you will start seeing these capabilities creeping into products because it is a checkbox on the spec sheet making it more competitive in a "me too" market. Price not withstanding, if you were comparing two otherwise identical monitors and one stated S3D compatible, which one would you buy? That day is here in the HDTV market now. That day will also come in the desktop market as 2nd and 3rd generation displays hit the market and the price delta is reduced.

the biggest being that the vast majority of todays game engines weren't designed from the ground up to support S3D and this needs to happen first before the rest of the pieces of the S3D puzzle will fall into place

Yes, but I'd say the majority of games have correct 3D data so that proper drivers can bring it to life. This was the case before the advent of post-processing anyway. Games today have a hard enough time getting ANTIALIASING to work on all systems. I think focus on games isn't the best route as there are already thousands of games out already that people would want to play in stereo.

Converting existing games is a completely different topic than future games. I have Bioshock and Crysis and honestly haven't spent more than an hour on each of them due to the lack of stereo, so i feel your pain. Really... I have played Q4 and NFS to death because they work in S3D. Think of this though for a moment. How many game developers have actually played their own game in S3D? Very few I bet, so why should they optimize their game for it? Now, what if the capability was built into the engine they purchased. Now it is a different story... They need to know how WE, the stereogamer, see their games. Getting it into the engine is one of way of doing that and making it a no-brainer to turn it on.

That first step just happened today...

Well again, while this is obviously a much more advanced engine, I'm not sure how different it is in concept from previous game engines that have supported sterescopy. Personally I think the biggest step for stereoscopic gaming was the introduction of consumer level shutter glasses as it made it possible for a wide audience even if it's been struggling since then.

I can agree with LCD glasses being a landmark event. If they weren't invented, I wouldn't be typing this message today. I can also agree that we don't know what the future holds for this game engine. It may die in a year. Or it may be the defacto engine of choice. Or it may just be an influencer, a feature checkbox if you will, that others developers notice. But you know what? In a year or two from now when I am at EB Games looking at the latest PC games and I run across a software title that has the MTBS3D logo on the outside of the box, I will take pride in asking the cashier, "What does this mean"? (And smile all the way home knowing where it came from, likely with a new game lying in the passenger seat).

Cheers!

PiXeL

[wuhlei]

cool ill try it out on linux with my geforce8

[jackeberg]

I have applied for the development kit try out and look forward to start developing on multiple engines.
The game will be released in episodes and the 3d version will most likely be freeware, commercial quality. So far the graphics quality is similar to Oblivion, but with an industrial setting, steampunk. As I have understod freeware will cost nothing. Good choice by unengine. First release planned for next christmas. Ramping up the pace with more people this spring.

The commercial price is way high and they will have to compete with unreal egnine and crysis. No one will pay for 3dfunctions in the engine.

[binstream]

Let me add my 5c.

It would be ideal if S-3D support required no additional efforts on software developer's side. It would be good if there was a single S-3D API. It would be good also if there were robust stereo drivers from all GPU vendors for all platforms in time. But we have none of this in the real world.

So, we are trying to deliver S-3D to the end users in a way, which is more effective for us.

PS: if you have something to ask about S-3D in Unigine - you are welcome: http://www.mtbs3d.com/phpBB/viewforum.php?f=45