Would downsampling work for the Rift?

[cerulianbaloo]

So I just recently became aware of what downsampling was, mostly in regards to games like Crysis 3, and I'm still a bit confused on how it functions. As I understand it, you're telling a game to render at a higher resolution than what resolution is being displayed, thus giving a resolution set at 1920x1080 the appearance of 2560x1440. So I'm thinking this would be a great solution for the dev kit resolution until we see the consumer model. I'm not sure how much it would conflict with things under the hood between the Rift dev kit and the games. Someone more technically inclined than I might be able to explain if it's feasible.

So the main benefits to me seems to be the appearance of higher res at the 1280x800, and also a more cost effective solution to having to use AA, though I don't know enough about downsampling if that would be feasible at this low a resolution. Any thoughts if something like this could work well with the Rift?

[MaterialDefender]

I can't speak for the true Rift, so take this with a grain of salt, but for DIY-Rifts it works - and it helps, especially in games that don't offer proper antialising. Provided the Rift doesn't require a games resolution set to its native resolution, I can't see any reason why it wouldn't work there too.

The downsampling itself is better done by the GPU anyway. For nVidia cards this can be easily set up in the control panel, for ATI/AMD cards it's little bit more tricky IIRC.

If a game has good AA it's generally better to use this over Downsampling though. Rendering everything at a higher res and then scaling it down is the costliest method of AA thinkable.

[Kirito]

2560x1440 would make the rift very expensive i think but im not sure what oculus is planning ( i wanna know!!!)

[cerulianbaloo]

I can't speak for the true Rift, so take this with a grain of salt, but for DIY-Rifts it works - and it helps, especially in games that don't offer proper antialising. Provided the Rift doesn't require a games resolution set to its native resolution, I can't see any reason why it wouldn't work there too.

The downsampling itself is better done by the GPU anyway. For nVidia cards this can be easily set up in the control panel, for ATI/AMD cards it's little bit more tricky IIRC.

If a game has good AA it's generally better to use this over Downsampling though. Rendering everything at a higher res and then scaling it down is the costliest method of AA thinkable.

So in your experience with the DIY Rift, what resolution(s) are you typically downsampling from? What kind of an impact on performance do you receive? Any graphical glitches or other issues that pop up? Thanks!

[KBK]

A notable amount of my time in the world of high end video projection was spent in dealing with this area of interface and algorithmic transform.

I have an opinion on what to do and what works best, but it might be important to understand that it is generally very device specific.

What device you are coming from and what device you are going to, as a mated pair, this becomes the visual quality noted by the eye/brain.

How well any of it works with the Dev kit will not be how it works with the commercial release or with any subsequent rift or other HMD.

The individual pairings as a set become the overall result. Some might think that I'm stating the obvious, but the point to take away is that there is no strategy until the pair of devices is in hand (GPU, panel and the given software hardware, in situ) and being tested against the human eye's given capacity to understand/decode the image presented.

[PasticheDonkey]

if you've got the power to down sample do it. if i could down sample every game from 8k i would. perfect image quality.

[MaterialDefender]

Just like Pastiche Donkey said, if you can a afford it, do it.

What exactly is possible hugely depends on your graphics card and how demanding a specific game is. So unfortunately no easy answer here. You will have to experiment from case to case.

Usually there aren't any graphical glitches, just the opposite is the case: Many typical glitches of modern games like shimmering shaders etc. are reduced tremendously.

[KBK]

It's kind of an interesting postscript, to me at least, when I look at the point that you can say -with a certain amount of confidence- 'downscaling works terrifically'.

When I was working on getting all of that stuff out there; that any of this had any effect on image quality or image 'intelligence', at all..that I took daily beatings from the denizens of the video forums. For 2-2.5 years straight. It burned me out, for the most part.

That what you understand so casually today, was a fully blown battle for a very long time - And I was the original proponent (thus a target for a seeming thousands) of the position that you now accept so readily. It's a bit more complex than that, but that is the basic side of it.

[geekmaster]

It's kind of an interesting postscript, to me at least, when I look at the point that you can say -with a certain amount of confidence- 'downscaling works terrifically'.

When I was working on getting all of that stuff out there; that any of this had any effect on image quality or image 'intelligence', at all..that I took daily beatings from the denizens of the video forums. For 2-2.5 years straight. It burned me out, for the most part.

That what you understand so casually today, was a fully blown battle for a very long time - And I was the original proponent (thus a target for a seeming thousands) of the position that you now accept so readily. It's a bit more complex than that, but that is the basic side of it.

You reverted a bit to your old confusing style of prose in that post. Still mostly understandable here though, but I hope we don't return to the old ways.

Now what you guys are calling "downscaling" (or "downsampling") here seems to be equivalent to "subsampling" (i.e. fractional pixels) or "anti-aliasing". That does work pretty well because subsampling effectively anti-aliases everything, and the human eye does a great job of automatically interpreting hidden detail in anti-aliased pixels displayed at enough pixel density (i.e. small pixels).

The term "downscaling" is a poor name for something that is supposed to increase displayed image quality, because downscaling by definition also includes "nearest neighbor" downscaling/downsampling, which does NOT increase quality and would only waste processing power.

There may be more efficient algorithms to compute anti-aliasing than rendering many more pixels and then downscaling them to achieve the same effect. Unless of course it also increases tesselation or has other enhanced rendering side-effects.

In video processing (where I use this term), downscaling/downsampling is used to reduce video bandwidth so it can be sent over a slower communication channel, or to reduce its storage space requirements. In that case, it REDUCES image quality, contrary to the usage of that term being used here.

Is there some special downscaling (or downsampling) side-effect that actually increases image quality in video games when you use it, or is it just an inefficient way to achieve anti-aliasing (causing an increase in PERCEIVED image quality)?

[PasticheDonkey]

video's already downscaled from reality.

[Pyry]

Downsampling (full-screen supersampling) is the brute-force way to do antialiasing, but the benefit is that (if you use an appropriate scaling method*) it has fewer limitations and artifacts than more efficient antialiasing techniques.

* area, or Gaussian blur on the full-size image followed by nearest neighbor scaling

[PalmerTech]

Supersampling is definitely useful in the Rift. We have it enabled in all our current Unreal demos.

[cerulianbaloo]

Supersampling is definitely useful in the Rift. We have it enabled in all our current Unreal demos.

Good to know, thanks for chiming in. I purchased an AMD card recently and it's admirable for now, but I know I'm probably going to want an nvidia card eventually for the Rift, what with the built-in downsampling options available in their driver software. Wish I did a bit more research and saw your Nvidia recommendation first lol. I know there's a few programs out there that purport AMD downsampling integration, I'll have to experiment a bit and see if anything works.

Thanks for all the help guys

[MaterialDefender]

Before you buy a new card, try to find out wether you can use supersampling, that's what Palmer mentioned, with your ATI card. That is similar to the 'trick' that is known as Downsampling. It saves the scaling part though, and instead uses multiple samples for every pixel directly, which, depending on the way it is done, looks even better.

Terminology (and technology) is quite confusing when it comes to AA, the general rule of thumb quality wise is

Supersampling > Downsampling > Multisampling > Shader AA (FXAA et al.)

[geekmaster]

Supersampling is definitely useful in the Rift. We have it enabled in all our current Unreal demos.

The end result is that the final image on the LCD panel is anti-aliased so that the eye can perceive extra detail beyond what pixels alone would provide.
http://en.wikipedia.org/wiki/Supersampling
http://en.wikipedia.org/wiki/Spatial_anti-aliasing

Super sampling anti-aliasing (SSAA), also called full-scene anti-aliasing (FSAA), is used to avoid aliasing (or "jaggies") on full-screen images. SSAA was the first type of anti-aliasing available with early video cards. But due to its tremendous computational cost and the advent of multisample anti-aliasing (MSAA) support on GPUs, it is no longer widely used in real time applications. MSAA provides somewhat lower graphic quality, but also tremendous savings in computational power.

Computational efficiency is more important in battery-powered applications, such as when using a portable "backtop" PC.

Supersampling > Downsampling > Multisampling > Shader AA (FXAA et al.)

Regarding Anti-Aliasing methods, Fast Approximation (FXAA) sounds a lot better in many ways than SuperSampling (SSAA) or MultiSampling (MSAA):
http://www.codinghorror.com/blog/2011/1 ... -fxaa.html

FXAA stands for Fast Approximate Anti-Aliasing, and it's an even more clever hack than MSAA, because it ignores polygons and line edges, and simply analyzes the pixels on the screen. It is a pixel shader program documented in this PDF that runs every frame in a scant millisecond or two. Where it sees pixels that create an artificial edge, it smooths them. It is, in the words of the author, "the simplest and easiest thing to integrate and use". ... FXAA smooths edges in all pixels on the screen, including those inside alpha-blended textures and those resulting from pixel shader effects, which were previously immune to the effects of MSAA without oddball workarounds. ... It's fast. Very, very fast. Version 3 of the FXAA algorithm takes about 1.3 milliseconds per frame on a $100 video card. Earlier versions were found to be double the speed of 4x MSAA, so you're looking at a modest 12 or 13 percent cost in framerate to enable FXAA -- and in return you get a considerable reduction in aliasing. ... I'm not sure if it's fair to call this a downside, but FXAA can't directly be applied to older games; games have to be specifically coded to call the FXAA pixel shader before they draw the game's user interface, otherwise it will happily smooth the edges of on-screen HUD elements, too. ... The FXAA method is so good, in fact, it makes all other forms of full-screen anti-aliasing pretty much obsolete overnight. If you have an FXAA option in your game, you should enable it immediately and ignore any other AA options.

4x MSAA sample:


FXAA sample:


Not seeing "jaggies" (as in the second image above) would help reduce perception of the screendoor effect that some people find annoying, without needing to add a diffusion layer over the LCD panel.

[MaterialDefender]

FXAA works great for still images but not so well in motion. The guy behind the original FXAA-algorithm, Timothy Lottes, did come up with something new, that works better in motion. But unfortunately that can't be applied to every game, specific support from the game engine is mandatory. This is known as TXAA and can be found in newer nVidia cards.

Also none of shader based approaches (there are even more) has the detail enhancing effect of SSAA, which is the most interesting part for a relatively low res device like the Rift.

[geekmaster]

The "Coding Horror" FXAA link I supplied mentioned that FXAA also requires support by the games. By comparison (as shown in the images I posted), MSAA does not begin to compare to FXAA, but it may have broader support, especially for older games.

Of course, if you have the CPU support, full SuperSampling (SSAA) is always an option. But lesser hardware may not support it at a 60 FPS.

For those whose budget forces a choice between a Rift and a new video card, SuperSampling might not be an option.

The sad thing is that to achieve a LITTLE more realism, you must throw a LOT more horsepower at it. This is not only from a technology price-point perspective, but we also have that pesky little "uncanny valley" effect to contend with.

I prefer to stay away from realism for now so it is easier to achieve a suspension of disbelief. I want to create interesting VR experiences that do not require expensive hardware. I even want to see Rift support on the Raspberry Pi. That would be a fun environment to support, just for the "Wow!" factor.

[MaterialDefender]

Performance is always a consideration when it comes to AA, very true.

FXAA is applicable to everything though, you can trust me on that. Even to photos shot a hundred years ago. Although that doesn't make much sense, of course. For gaming purposes there are numerous so called FXAA injectors that you can drop in any DX9+ games directory. It will work with most of them. And where it does not work it's a injector problem.

[geekmaster]

Performance is always a consideration when it comes to AA, very true.

FXAA is applicable to everything though, you can trust me on that. Even to photos shot a hundred years ago. Although that doesn't make much sense, of course. For gaming purposes there are numerous so called FXAA injectors that you can drop in any DX9+ games directory. It will work with most of them. And where it does not work it's a injector problem.

Thanks for the info. I do not play games much. Just work (and browse this forum). I plan to use my Rift primarily for work applications (data visualization), but even there, FXAA may make the relatively low resolution (for VR) of the Rift look better even with business VR apps.

I found this FXAA injector:
http://www.dsogaming.com/news/fxaa-inje ... s-goodies/

Is there a better one to use?

[cybereality]

If you are working on a Rift-enabled game you can do this yourself in the engine and get nicer quality. Basically you render the scene to a render-target (instead of the back-buffer) but at a higher resolution than the screen. As the last step you feed it though a pixel shader that does the warping/distortion. So you end up outputting a native resolution image but it looks a lot better than if you were working with the screen res the whole time.

That said, these kinds of software "tricks" only go so far. No matter what, you aren't going to get it looking like a 1080P picture. But I guess any little bit counts.

[2EyeGuy]

The way the Rift does warping really requires rendering at significantly above 640x800 if you want to make use of the Rift's full resolution. The PC can't actually render at higher resolution in the middle and lower at the edges, so you'd have to render the whole thing to match the highest resolution part. Whether it's worth the frame-rate cost depends on the game though.

[AdaAugmented]

The way the Rift does warping really requires rendering at significantly above 640x800 if you want to make use of the Rift's full resolution. The PC can't actually render at higher resolution in the middle and lower at the edges, so you'd have to render the whole thing to match the highest resolution part. Whether it's worth the frame-rate cost depends on the game though.

My own experiments with Quake 1 have lead me to the same conclusion. Without rendering to a larger texture at a proportionaly higher resolution you lose a whole lot of detail when you apply a sufficient warp to counter the distortion from the 5x aspheric lenses I'm using.

[geekmaster]

As I mentioned elsewhere, I think that rendering a larger FoV than gets displayed could be useful when the rendering FPS slows down, so that head-tracked PTZ (pan/tilt/zoom) could be used on the previous image to "simulate" a higher FPS to help prevent motion sickness. Allowing fast low-latency head-tracked PTZ using the last-known image could work well for other slowdowns such as while loading assets, or during network congestion. Although it may exist, I have seen no prior art on this idea. It came to me after reading John Carmack's blog about latency issues.

It seems especially useful for my "fresnel lens stack Fov2Go clone for 7-inch tablets" that I am developing, where the simple "last received image" PTZ function could be offloaded to the tablet. As mentioned above, it would help to have some extra unused image content in the peripheral margins, in which to pan during head movement. But even without it, just panning the central area should help a lot.

So while downsampling/supersampling/anti-aliasing, we could render a little extra FoV for PTZ "backup" latency compensation. Just an idea. But worth trying.

[AdaAugmented]

As I mentioned elsewhere, I think that rendering a larger FoV than gets displayed could be useful when the rendering FPS slows down, so that head-tracked PTZ (pan/tilt/zoom) could be used on the previous image to "simulate" a higher FPS to help prevent motion sickness. Allowing fast low-latency head-tracked PTZ using the last-known image could work well for other slowdowns such as while loading assets, or during network congestion. Although it may exist, I have seen no prior art on this idea. It came to me after reading John Carmack's blog about latency issues.

It seems especially useful for my "fresnel lens stack Fov2Go clone for 7-inch tablets" that I am developing, where the simple "last received image" PTZ function could be offloaded to the tablet. As mentioned above, it would help to have some extra unused image content in the peripheral margins, in which to pan during head movement. But even without it, just panning the central area should help a lot.

So while downsampling/supersampling/anti-aliasing, we could render a little extra FoV for PTZ "backup" latency compensation. Just an idea. But worth trying.

I would anticipate problems doing this with 6DOF head tracking since parallex won't change as the image pans and rotates. It could be rather jarring if there are any foreground objects in the FOV and you end up with perspective latency that doesn't match the head tracking latency. It would be interesting to play with though, maybe it wouldn't be such a big deal.

[Paladia]

Downsampling is the same as SSAA. It is just a (very good) antialiasing technique. It won't make it look like you are running at higher resolution however.

[geekmaster]

Downsampling is the same as SSAA. It is just a (very good) antialiasing technique. It won't make it look like you are running at higher resolution however.

I agree that the end results are the same, but the process pipelines are different. Downsampling requires an image buffer for the larger image, while SSAA is a pipelined method that works on smaller localized blocks of pixels. Depending on where you store that large image buffer for downsampling, you may incur speed penalties by accessing image data in RAM instead of cache.

At least, that is how I understand it. My experience from years ago (before cache concerns were so important) is with the downsampling method, and not SSAA/MSAA/FXAA. I still have a lot to learn, so I may have it all wrong...

[geekmaster]

I would anticipate problems doing this with 6DOF head tracking since parallex won't change as the image pans and rotates. It could be rather jarring if there are any foreground objects in the FOV and you end up with perspective latency that doesn't match the head tracking latency. It would be interesting to play with though, maybe it wouldn't be such a big deal.

I am concerned primarily with all those little head shakes and twitches that contribute so much to VR immersion when the VR display content moves accordingly with low latency.

It is your peripheral vision that is most sensitive to motion (and probably the source of motion sickness) and that is much less sensitive to parallax (and does not even have stereoscopic overlap for the most part).

It may be noticed by the user if PTZ (pan/tilt/zoom) is substituted for rendered frames for too long of a dropout period, but I suspect that will just be perceived as an environmental curiosity rather than potential poisoning from bad 'shrooms (or whatever)...

The whole point of even doing this PTZ substitution is to provide a backup method for when rendered frames are not available, such as dropouts, or to interpolate missing "tween" frames when using a low-power video card that can only provide less than optimal framerates (such as a tablet PC or a Raspberry Pi). I am making an educated guess that for "tourism" type VR apps, we may be able to go as low as 10 FPS rendering with PTZ interpolation. But for FPS games, prepare to get fragged.


Surely, head tracked PTZ will be drastically superior to just being stuck with a frozen image frame, while waiting for the image next frame from the rendering pipeline or communications channel. Right?


BTW, if anybody incorporates head-tracked PTZ into their VR software, please give me a little recognition in your credits (and maybe a free copy of your game). Thanks!

[KBK]

Encode/decode qualities in an FPS becomes the quality of target recognition and acquisition. Both with respect to time, in static or motion situations that are relevant only to the in-situ optics, panel, and then encode/decode, all as a set. This is 60hz HMD as a loop, this means that there is potential that one method vs another may average out to one player being one frame ahead or back of another, another who is using a less (or more) 'human vision centric' method. 16-20ms difference in reaction potential.

[sth]

Supersampling > Downsampling > Multisampling > Shader AA (FXAA et al.)

Regarding Anti-Aliasing methods, Fast Approximation (FXAA) sounds a lot better in many ways than SuperSampling (SSAA) or MultiSampling (MSAA):

It's not better than supersampling because it effectively reduces detail (as it only operates on the final image and has no additional data to work with).
They both smooth the entire image (not just the geometry edges like MSAA does), which is good, but SSAA/downsampling works better in motion. If you have "flickering" pixels (because of aliasing) while moving, these get smoothed out by supersampling, whereas in shader-based anti-aliasing, these can still be problematic. TXAA counters this by using the previous frame as a reference, but it requires game engine integration to work and it will also reduce detail just like FXAA does.

SSAA/downsampling is still the best method, but of course, at a massive performance cost.
Shader-based anti-aliasing is the cheapest in terms of performance, but at the cost of detail.
However, there might me another option in-between the two, at least on nVidia cards:
Multisampling in combination with transparency-supersampling.

nVidia introduced a driver option a while back, which enables supersampling for transparent textures only. That combined with MSAA (which only affects geometry) should give good overall image quality at a lower performance cost than pure SSAA.

Supersampling is definitely useful in the Rift. We have it enabled in all our current Unreal demos.

Are you using a single GTX680 or a SLI setup?

[Zerofool]

It appears that there's a huge misconception about what the term "downsampling" actually means.
Most of you got its purpose right, but not how it really works. In the beginning, there wasn't any post-processing (pp) AA methods (MLAA/FXAA/SMAA), and downsampling was a good way to partially fight aliasing in games that don't support traditional AA (I'll get to that in a bit). So, downsampling works this way: the game is rendered in higher resolution, then the image is scaled by the GPU, down to the native rez of the monitor, and then sent to it. There are guides on how to do it with Nvidia and AMD cards. It works with virtually all games.
There's also software that does that for DX10/11 games - ToMMTi-Systems SSAA-Tool, it probably does what Cybereality described, and I guess that's what John Carmack calls "oversampling" in some of the interviews for D3 BFG.
In theory, all this should work with the Rift.

Downsampling is the same as SSAA.

As geekmaster said, the result is virtually the same, but the way it's done is different. Downsampling is actually much closer to the definition of FSAA (full screen/full scene AA).

And now to get back on AA in games - lately, many games use engines which, in pursuit of more effects, bells and whistles and so on, use deferred rendering techniques, which are not compatible with MSAA, SSAA and their derivatives (except for the cases in which the devs have made the effort to find a workaround, sacrificing speed), so the only way to reduce aliasing is through downsampling, or pp AA, or both.
All SSAA modes available in the driver options should be faster than rendering at higher resolution (which consumes more VRAM), but there are some reports that some games run faster with downsampling than with regular MSAA (it appears that all these games use deferred rendering, and they use these tricks to support MSAA, which slow things down).

Now, I'd like to rate different modes in terms of quality from my experience, and all the information around the net.
The ultimate Anti-Aliasing technique in terms of both spatial and temporal AA is TXAA+SGSSAA (nvidia). Unfortunately, TXAA is not something you can force in a game through the driver, the game has to be written with support for it (as MaterialDefender said), and currently only a handful of games support it (as of now, less then 10, I think). The spatial-only AA methods are:

SGSSAA (nvidia) ~ SSAA (amd) >> OGSSAA (nv) ~ downsampling* > CSAA+TrAA (nv) ~ EQAA+AAA (amd) > MSAA+TrAA (nv) ~ AAA (amd) > CSAA (nv) ~ EQAA (amd) > MSAA > pp AA (SMAA>FXAA>MLAA).

The first two being in a class of their own IMHO, but they have the according hit on performance. Still, at 640x800, I think the performance with them will be tolerable in most cases... or you can always go out and buy a GTX Titan (or four) .

* Downsampling is virtually the same as OGSSAA, as long as the number of pixels/samples is the same, i.e. 4xOGSSAA = 2*hor.rez. X 2*vert.rez. downsampling, etc.

P.S. sth addressed some of the issues I discussed, while I was still writing my post .

[geekmaster]

It appears that there's a huge misconception about what the term "downsampling" actually means.
Most of you got its purpose right, but not how it really works.
...
Now, I'd like to rate different modes in terms of quality from my experience, and all the information around the net.
The ultimate Anti-Aliasing technique in terms of both spatial and temporal AA is TXAA+SGSSAA (nvidia). Unfortunately, TXAA is not something you can force in a game through the driver, the game has to be written with support for it (as MaterialDefender said), and currently only a handful of games support it (as of now, less then 10, I think). The spatial-only AA methods are:

SGSSAA (nvidia) ~ SSAA (amd) >> OGSSAA (nv) ~ downsampling* > CSAA+TrAA (nv) ~ EQAA+AAA (amd) > MSAA+TrAA (nv) ~ AAA (amd) > CSAA (nv) ~ EQAA (amd) > MSAA > pp AA (SMAA>FXAA>MLAA).

The first two being in a class of their own IMHO, but they have the according hit on performance. Still, at 640x800, I think the performance with them will be tolerable in most cases... or you can always go out and buy a GTX Titan (or four) . ...

@Zerofool: Excellent and informative post. Thanks!

[zacherynuk]

/TLDR
I think one of the vitals for immersion is consistency, so in a few years when we have power for full on super or downsampling with zero noticeable affect, then yay. Better still; I want Caustic style ray trace or Vector Codec driven displays.

/TLDR

It's a very very tough call and depends alot on the game and, indeed, the user as to what is deemed a quality image.

I play most of my games on 3 X Samsung 24" monitors driven by 2 GTX 690 graphics cards in SLI Surround, 16GB ram and an i7 930 running at 950 - so probably the top 1% of gaming rigs.

Some games just don't like to be AAed - and anybody who remembers the early 90's when we had a choice between 16 colour VGA(640x400/480) or 256 colour MCGA(320x200/240) will recall that the latter was a far nicer experience.

In the low res of DIY rift, I have found that I can drive games like L4D/2 at full whack and they look very clean; but far cry, skyrim and similar vast expanse games I would rather have jaggies inside than a blur outside.

In the real world, I generally play Far cry 3 & bf3 without ANY aa at all, but did have it pumped up for skyrim - though ambient occlusion was the best for making things 'nice'.

In my experience, if you are moving, jaggies have little effect at high resolutions and at low resolutions, AA can cause a shimmering effect. The fact that I understand what is causing the anomalies, means that I prefer the raw feel of jaggies at lower resolutions. I prefer original flaws to post-rendered flaws! Give me a flawlessly moving jaggy over a jerky shimmering blur any day!

That being said, the new 7" screen may well go along way itself to improve the perception of a smooth environment with it's lower dot pitch and faster refresh. The DIY has a massive difference in appearance when tracking slowly to quickly; so naturally, when moving slowly or stopped to focus on objects things are (perceptibly) worse.

[Zerofool]

@Zerofool: Excellent and informative post. Thanks!

You are welcome! If some of you haven't heard about some of the abbreviations, google them, there's plenty of info. It would take ages for someone to explain each and every one of them, that's why I didn't get into too much detail.

Supersampling is definitely useful in the Rift. We have it enabled in all our current Unreal demos.

Are you using a single GTX680 or a SLI setup?

I personally play all games (yes, mainly older ones, and mainly made by Valve ) in S-3D with 4xSSAA (at 1280x960 on CRT) on my aging PC, and the framerate is around 60fps most of the time. The Epic Citadel demo doesn't look so heavy (yet, it's quite beautiful from what I've seen), so I guess a single 680 is more than enough for that, even 650Ti should do the job at 640x800 with 4xSSAA.

Of course, if you have the CPU support, full SuperSampling (SSAA) is always an option.

Actually, the CPU has very little effect on the performance of different AA methods, the GPU is most important here. For higher resolutions with higher quality AA, the amount of VRAM also plays role (we're talking beyond 1080p; for up to 1080p, 3GB is plenty).

[geekmaster]

Of course, if you have the CPU support, full SuperSampling (SSAA) is always an option.

Actually, the CPU has very little effect on the performance of different AA methods, the GPU is most important here. For higher resolutions with higher quality AA, the amount of VRAM also plays role (we're talking beyond 1080p; for up to 1080p, 3GB is plenty).

That is what I meant to say (s/CPU/GPU/). As I get older, my fingers misbehave and type different words from what I was thinking, far too often. Sadly, they are usually valid words, but just the WRONG words, so spell checkers do not help much. Proofreading does not help either, because it takes time (hours or days) before I can even SEE some of my typos. That is why you can see so many edits on my posts. I do not like to leave lingering errors, unless they have been quoted by somebody else... At least I TRY to make valuable contributions to the technical discussions here and elsewhere...

How long until we can trade in our old worn-out bodies on new models, just like we do with our old cars? At least VR will let us PRETEND that we are young again, if only for awhile. Other than my failing mind and body, I still feel like a teenager inside, while the years fly past faster than ever...

[Zerofool]

That is what I meant to say (s/CPU/GPU/). As I get older, my fingers misbehave and type different words from what I was thinking, far too often. Sadly, they are usually valid words, but just the WRONG words, so spell checkers do not help much. Proofreading does not help either, because it takes time (hours or days) before I can even SEE some of my typos. That is why you can see so many edits on my posts. I do not like to leave lingering errors, unless they have been quoted by somebody else... At least I TRY to make valuable contributions to the technical discussions here and elsewhere...

How long until we can trade in our old worn-out bodies on new models, just like we do with our old cars? At least VR will let us PRETEND that we are young again, if only for awhile. Other than my failing mind and body, I still feel like a teenager inside, while the years fly past faster than ever...

I totally get you, I've been in the same situation many times, many edits on my posts as well . But I started using TTS software to read my own posts during preview, to "see" if something sounds wrong .

16GB ram and an i7 930 running at 950

You probably mean 12GB? LGA 1366 systems have triple-channel memory controller, so... Unless you have 4+4+8GB or 8+8GB - that way your system would run in single-channel or dual-channel mode respectively, which wouldn't be optimal.
But we're getting a bit off-topic...

[sth]

Supersampling is definitely useful in the Rift. We have it enabled in all our current Unreal demos.

Are you using a single GTX680 or a SLI setup?

I personally play all games (yes, mainly older ones, and mainly made by Valve ) in S-3D with 4xSSAA (at 1280x960 on CRT) on my aging PC, and the framerate is around 60fps most of the time. The Epic Citadel demo doesn't look so heavy (yet, it's quite beautiful from what I've seen), so I guess a single 680 is more than enough for that, even 650Ti should do the job at 640x800 with 4xSSAA.

Both Source engine and Unreal Engine 3 games should run fine on most hardware.
I just wanted to know what Oculus is using in their demo rigs. I remember a GTX680 being mentioned a while back, but I don't know if it was one or two of them.

BTW: What are you using for enabling SSAA? nVidia Inspector? nVidia's SSAA tool?

[TheHolyChicken]

I'm pretty sure they said they were using "just" the one 680.

[sth]

I'm pretty sure they said they were using "just" the one 680.

Thanks! I guess they'll be upgrading to "just" one GeForce Titan soon.

[Zerofool]

I'm pretty sure they said they were using "just" the one 680.

That's correct. Here's the pic they posted on twitter some time ago:


They explained there that their demo rig is a "PC that's built into the suitcase. "

P.S.: If someone is wondering, the CPU cooler they're using appears to be Noctua NH-C14 with a single fan underneath the heatsink fins. And obviously, the PSU is Seasonic Gold series (a.k.a. X series), can't say which model exactly, but its between 560W and 850W, not higher (the more powerful ones are physically bigger).

BTW: What are you using for enabling SSAA? nVidia Inspector? nVidia's SSAA tool?

I have an AMD card (HD5870), and I use the control center to set SSAA as the preferred method - it works with both DDD Tridef and iZ3D drivers. If I had an nvidia card, I'd use Nvidia Inspector as it offers much more options, but I have no idea if it would work together with 3D Vision/3DTV Play.

[MSat]

I'm thinking that downscaling would have to be performed by the application rather than being forced via the GPU's control panel, as the scene needs to be rendered above the Rift's native resolution to prevent a loss of quality from warp compensation anyway. Since any application has to support the Rift natively (for which the resolution is known), I doubt that you would actually be able to select a different resolution anyway - only the type and amount of AA you want to apply.