Fritz, your comments are pretty insightful, but not totally on the money. Quake engines are optimized for some things, like culling and sorting of polygons for indoor environment. And flight sims can make certain optimizations, like knowing you can't go faster than X and all the data is on your hard disk (as opposed to downloaded in realtime). If you were to see a version of earthviewer (which I have) that was running off a full local cache of data, you'd see that it's way beyond current flight sims and Quake in performance and visual quality. And given the limitations of serving terrabytes of content over the internet, the consumer version still holds up pretty well, IMO. There are certain things you can do in the consumer version that _will_ show this off, such as increasing the texture size and using anisotropic filtering.
BTW, I do not speak for the company. My comments are all my own.
Yeah. The advantage of passive (polarized) is cheaper/light/more-comfortable glasses, less (or no) flicker. Circular polarization is probably best, since standard linear polarization breaks down when you tilt your head. But the screens are almost non-existent for read projection passive. (This job calls for transparent aluminum:)
Even good active (LCD shutter) systems also have flicker and extinction problems (cross-talk between the eyes because the LCD can never go 100% dark or change at 100% of the speed you need) which kind of ruins the stereo effect for me personally. These projectors are also more expensive--to get 60HZ for each eye, you need 120HZ total, right? Two standard 60HZ projectors might actually be cheaper and brighter in the long run. Both methods have the pitfall that they're losing half or more of the projector's power.
I don't know about the CAVE you were in. But on the ones I've built and/or been in, the trackers weren't necessarily the driving cost. Here are some of the big costs in the past:
1. 4-6 high-end stereo-capable video channels (typically big iron SGI or smaller but heavily synchronized computers) doing 120hz rendering of large datasets
2. Infrastructure -- custom-built cube, often raised off the floor for bottom to work, requiring risers, stairs, and quality construction for insurance purposes
3. 4-6 x 8'-10' fixed panel rear-projection screens (that preserve polizaration, not an easy trick)
We were able to reduce #2 with wood construction, omitting the raised floor. We also found that for entertainment apps, head tracking wasn't the most important thing, so for #1, somewhat cheaper computers and no tracking is an option. For #3, cheaper acryllic screens are fine if you don't need passive stereo (which you don't if your virtual objects are greater than say 12 feet from the viewer or you use active stereo).
Bottom line: we built a cheap-ass CAVE in 1993 for under $30k not counting the computers (which were over $300k back then). With new PCs, new projectors, and some clever predictive synchronization over simple ethernet, we could be talking $6k per wall without stereo, $10k with. Add decent tracking, and you add maybe another $10k overall. Add labor costs, markup, and an insurable level of steel infrastructure and that gets you near the $120k for current CAVE systems. But cheaper is always an option. For example, in my home, I use non-stero and an 8' screen made of stretching a 300 thread king-sized bed-sheet over a custom wood frame (it's as good or better than many screens I've used).
Some of this was adressed in another post, but I guarantee if I had faster readback we'd use it my projects. I've had cases where the best theoretical solution to a graphics problem (like occlusion culling) was hampered solely by slow readbacks.
For example, NVidia is currently advising developers to go render the entire frame once up front quickly (no light, no texture) to lay down the z-buffer so hidden pixels don't get rendered during later passes. If we could do that first render with tags (color-ids) that would tell us which objects are actually visible, we could avoid sending more detailed geometry and texture passes (which can actually lower AGP demands) and avoid a heck of a lot of wasted pixel processing too.
Even if latency were an issue, sampling this visibility information at a lower frequency would give us a better idea about turning off whole portions of a scene. We might even be able to avoid frustum culling entirely. So, yes, this is an issue today and maybe even with the games you care about.
That's the design, but it doesn't really work that way in practice AFAICT. If I have some geometry in AGP memory, the fastest way seems to be to render it to part of the main framebuffer before the final main rendering. Keeps the context switches low. I haven't yet found a way to preserve VAR settings across context switches, which gets in the way of asynchronous rendering.
Pbuffers are better suited for when you want to render data that isn't in the same config as the main framebuffer, or want to render and buffer up at other than the main framerate. Besides, there's still a readback required.
I've been doing real-time 3D graphics for 10 years and read-back speeds have been the biggest problem for doing many advanced algorithms. We have asked the companies to improve this many times. The problem as I see it: Quake and other benchmark apps don't rely on readback.
Here are a few other important but non-Quake techniques that are driven by readback speeds. I'll go into more detail on the first for illustration purposes.
High-quality real-time occlusion culling -- many techniques render the scene quickly by using a unique color tag per object or polygon and then read back the framebuffer to figure out everything that was visible (and how many pixels for each) for a final high-quality pass. If HW drivers would even just implement the standard glHistogram functions (which essentially compress the framebuffer before readback), this would become practical. NVidia adds their NVOcclusion extension, but it's limited in how many objects at a time you can test, it's very asynchronous, and it requires depth sorting on the CPU to make it most useful. The render-color technique does not. Yet HW makers are spending lots of money adding custom HW to do z-occlusion when a simple driver-based software technique may be easier.
Dynamic Reflection Maps -- for simple, reflective surfaces -- Requires background rendering from multiple POVs (generally six 90 degree views) and caching these. Even if you can cache a small set of maps in AGP memory, you want fast async readback if you have a large fairly static scene and you're roaming around.
Real-time radiosity -- similar to above, but needs more CPU processing of the returned images and possibly depth maps (reading back the depth buffer is often even more expensive than the color).
Real-time ray tracing -- the better quality approaches need fast readback to store intermediate results (due to recursion, etc..). With floating point framebuffers and good vertex/pixel shaders, ray-tracing becomes possible, but not yet practical. I believe./ may even have run a link to one of these techniques a while back.
So there's a lot more to this issue than just making movies of your games. Faster, better graphics would be possible. So why isn't this a priority?
------------
cyranose@realityprime.com
Slashdot Mirror
Fritz, your comments are pretty insightful, but not totally on the money. Quake engines are optimized for some things, like culling and sorting of polygons for indoor environment. And flight sims can make certain optimizations, like knowing you can't go faster than X and all the data is on your hard disk (as opposed to downloaded in realtime). If you were to see a version of earthviewer (which I have) that was running off a full local cache of data, you'd see that it's way beyond current flight sims and Quake in performance and visual quality. And given the limitations of serving terrabytes of content over the internet, the consumer version still holds up pretty well, IMO. There are certain things you can do in the consumer version that _will_ show this off, such as increasing the texture size and using anisotropic filtering.
BTW, I do not speak for the company. My comments are all my own.
Yeah. The advantage of passive (polarized) is cheaper/light/more-comfortable glasses, less (or no) flicker. Circular polarization is probably best, since standard linear polarization breaks down when you tilt your head. But the screens are almost non-existent for read projection passive. (This job calls for transparent aluminum :)
Even good active (LCD shutter) systems also have flicker and extinction problems (cross-talk between the eyes because the LCD can never go 100% dark or change at 100% of the speed you need) which kind of ruins the stereo effect for me personally. These projectors are also more expensive--to get 60HZ for each eye, you need 120HZ total, right? Two standard 60HZ projectors might actually be cheaper and brighter in the long run. Both methods have the pitfall that they're losing half or more of the projector's power.
I don't know about the CAVE you were in. But on the ones I've built and/or been in, the trackers weren't necessarily the driving cost. Here are some of the big costs in the past:
1. 4-6 high-end stereo-capable video channels (typically big iron SGI or smaller but heavily synchronized computers) doing 120hz rendering of large datasets
2. Infrastructure -- custom-built cube, often raised off the floor for bottom to work, requiring risers, stairs, and quality construction for insurance purposes
3. 4-6 x 8'-10' fixed panel rear-projection screens (that preserve polizaration, not an easy trick)
We were able to reduce #2 with wood construction, omitting the raised floor. We also found that for entertainment apps, head tracking wasn't the most important thing, so for #1, somewhat cheaper computers and no tracking is an option. For #3, cheaper acryllic screens are fine if you don't need passive stereo (which you don't if your virtual objects are greater than say 12 feet from the viewer or you use active stereo).
Bottom line: we built a cheap-ass CAVE in 1993 for under $30k not counting the computers (which were over $300k back then). With new PCs, new projectors, and some clever predictive synchronization over simple ethernet, we could be talking $6k per wall without stereo, $10k with. Add decent tracking, and you add maybe another $10k overall. Add labor costs, markup, and an insurable level of steel infrastructure and that gets you near the $120k for current CAVE systems. But cheaper is always an option. For example, in my home, I use non-stero and an 8' screen made of stretching a 300 thread king-sized bed-sheet over a custom wood frame (it's as good or better than many screens I've used).
4. Pretend expired domains are not expired by filling in false owner information.
5. Profit more.
Some of this was adressed in another post, but I guarantee if I had faster readback we'd use it my projects. I've had cases where the best theoretical solution to a graphics problem (like occlusion culling) was hampered solely by slow readbacks. For example, NVidia is currently advising developers to go render the entire frame once up front quickly (no light, no texture) to lay down the z-buffer so hidden pixels don't get rendered during later passes. If we could do that first render with tags (color-ids) that would tell us which objects are actually visible, we could avoid sending more detailed geometry and texture passes (which can actually lower AGP demands) and avoid a heck of a lot of wasted pixel processing too. Even if latency were an issue, sampling this visibility information at a lower frequency would give us a better idea about turning off whole portions of a scene. We might even be able to avoid frustum culling entirely. So, yes, this is an issue today and maybe even with the games you care about.
That's the design, but it doesn't really work that way in practice AFAICT. If I have some geometry in AGP memory, the fastest way seems to be to render it to part of the main framebuffer before the final main rendering. Keeps the context switches low. I haven't yet found a way to preserve VAR settings across context switches, which gets in the way of asynchronous rendering.
Pbuffers are better suited for when you want to render data that isn't in the same config as the main framebuffer, or want to render and buffer up at other than the main framerate. Besides, there's still a readback required.
I've been doing real-time 3D graphics for 10 years and read-back speeds have been the biggest problem for doing many advanced algorithms. We have asked the companies to improve this many times. The problem as I see it: Quake and other benchmark apps don't rely on readback. ./ may even have run a link to one of these techniques a while back.
Here are a few other important but non-Quake techniques that are driven by readback speeds. I'll go into more detail on the first for illustration purposes.
High-quality real-time occlusion culling -- many techniques render the scene quickly by using a unique color tag per object or polygon and then read back the framebuffer to figure out everything that was visible (and how many pixels for each) for a final high-quality pass. If HW drivers would even just implement the standard glHistogram functions (which essentially compress the framebuffer before readback), this would become practical. NVidia adds their NVOcclusion extension, but it's limited in how many objects at a time you can test, it's very asynchronous, and it requires depth sorting on the CPU to make it most useful. The render-color technique does not. Yet HW makers are spending lots of money adding custom HW to do z-occlusion when a simple driver-based software technique may be easier.
Dynamic Reflection Maps -- for simple, reflective surfaces -- Requires background rendering from multiple POVs (generally six 90 degree views) and caching these. Even if you can cache a small set of maps in AGP memory, you want fast async readback if you have a large fairly static scene and you're roaming around.
Real-time radiosity -- similar to above, but needs more CPU processing of the returned images and possibly depth maps (reading back the depth buffer is often even more expensive than the color).
Real-time ray tracing -- the better quality approaches need fast readback to store intermediate results (due to recursion, etc..). With floating point framebuffers and good vertex/pixel shaders, ray-tracing becomes possible, but not yet practical. I believe
So there's a lot more to this issue than just making movies of your games. Faster, better graphics would be possible. So why isn't this a priority?
------------ cyranose@realityprime.com