Questions for Derek Smart

[jb]

Derek,

for your last post you seem to indicate that you might stick around here. Good while we have a developer here could you take a few minutes to share your thoughts with us about:

[edit] Should have said while we have you here..did not mean to single out other developers sorry...did not have morning coffee yet [/edit]



1) Currently there is a big lag in game development vrs hardware. Current video cards have some features that are not used for a "long time" after the care is launched. Take DX8 level of vertex/pixel shadders for example. They have been with us for a 18+ months or so. And yet we have only seen a few game use them so far. We know that developers need the hardware to code for these effects but we also know that this takes time. Do you see any chance to cut down on the time before these new features are used in more of the games at that time or do think there will always be a 18+ month lag between new features and when they are adopted and used in games? And do you think there are any ways to cut that time down (and I would imagine the time it takes is directly related to the said features in question)?


2) Cg. Lot of talk about it lately. What's your take on it?


3) Finally where do you want to see the video hardware go in the future?


Thanks for taking your time with this!

 

[Dave Baumann]

I'd just like to point out - there are infact several developers around here, just not all of them quite as, errr, obvious

Lets hear all their opinions.

 

[jb]

Dave,

yes I knew that as well. But lately...one of them has been...ummm whats the phrase....more vocal...then the others

 

[Derek Smart [3000AD]]

Derek,

1) Currently there is a big lag in game development vrs hardware. Current video cards have some features that are not used for a "long time" after the care is launched. Take DX8 level of vertex/pixel shadders for example. They have been with us for a 18+ months or so. And yet we have only seen a few game use them so far. We know that developers need the hardware to code for these effects but we also know that this takes time. Do you see any chance to cut down on the time before these new features are used in more of the games at that time or do think there will always be a 18+ month lag between new features and when they are adopted and used in games? And do you think there are any ways to cut that time down (and I would imagine the time it takes is directly related to the said features in question)?

IMO, the problem is two fold

1. Hardware vendors don't release their boards according to our dev schedules
   
2. Software developers don't care much for the release schedules of hardware vendors. Especially for games that are (a) already well into development (b) won't benefit from whatever whizzbang the IHVs have come up with.

When you put these two into perspective, you can easily see why this happens. You will also see that it, quite simply, cannot be fixed.

Picture this: can you imagine any developer - especially those married to a large publisher - slowing down and/or halting their development because of something cool that the upcoming card is going to support?

Heck, how long has hardware TnL been out? What, something like 4+ years or so? How many games ended up using it? I think I can count them on my hands.

The same will be true for pixel/vertex shaders. You will only find these cropping up as time goes on and new games which benefit from it, are developed. Some specialist type showcase games (see Aquanox) took these features to the edge and back. Then failed at retail. Nothing to do with the tech of course, but more about the game itself and the finicky nature of gamers.

Matrox hyped dual-head to the hilt and hardly anyone came to that party. Then ATI, nVidia etc jumped on the bandwagon. And before you knew it, dual-mon support can now be found on all next-gen cards. Though they are only used for a different reason, 99% of which have nothing to do with games.

The next Matrox fad, Surround Gaming, is going to suffer the same spectacular fate.

So see, its all about the demand for what we need/want. A lot of uses of pixel/vertex shaders (apart from cool look water fx) will only start to show up in the 2003-2004 time frame, when new games in development or those that starte late in 2001 (e.g. my BCG title), start adopting these shaders for achieving cool looking effects and other needed features.

So, no, I don't see this trend changing at all. And there's nothing that I can personally think of, that would make it any better. After all, very few of us at the calibre of JC, Tim Sweeney et al. As such, we're not bloody likely to get advanced info on any hardware. And without it, can't plan ahead.

2) Cg. Lot of talk about it lately. What's your take on it?

It works. The problem I see goes back to the whole Glide vs DX debate. As far as I can see, Cg is not standardized. In fact, some of the effects which should work on an ATI board, do not. In fact, some flat out crash it.

As such, I have my doubts as to whether any dev is going to waste their time using Cg to put in effects which only work on nVidia boards. Its bad enough that we (well, me personally) have exclusion code specifically geared toward making things work on ATI boards. Why would I want to add another layer of complexity to my code base.

For that, I'm probably not going to touch Cg for anything - other than prototyping. Its cool for that.

3) Finally where do you want to see the video hardware go in the future?

Exactly where it is now

1. nVidia will contine to lead - unless someone comes up with a new method of doing a collosal fuck up of something that works. Think 3Dfx
   
2. ATI engineers will continue to work their asses off in order to bring the best competing and kick-ass part to the market.
   
3. ATI driver development will keep their index finger, firmly planted....ok, lets not go there, cuz I promised to behave....ATI driver development will probably improve somewhat but that whole ATI drivers suck!! rep is going to take a miracle to shake. In this regard, its going to take new adopters and nVidia deserters to come on board and boost the confidence. Why? Well because the entrenched ATI adopters (a) aren't going anywhere (b) are doing a very bad job of convincing anyone that ATI is the way to go. Not their fault though (see: driver development)
   
4. Matrox will keep, as it always has, its supporters and continue to stick to what they know and hopefully will refrain from pitiful attempts at taking on nVidia and ATI, knowing fully well they don't stand a snowball's hell in chance.....unless of course they buy nVidia or ATI or convince their engineers to jump ship.
   
5. The nvidiots and the ATI campers are going to continue deploying weapons of mass destruction at the borders, remain firmly entrenched in said camps and sit it out. Hoping that the other side caves in

At the end of the day, regardless of who is on top or out of the game, gamers win.

 

[no_way]

How bad is loss of W-buffer in DX9 ? After all, 24-bit means you have ~16M possible Z-buf values.. even if you waste 98% of those values on close range ( 2% of max depth displayed) , you still have 300K possible values left for remaining range. I cant imagine a situation when this precision isnt sufficient ( assuming of course, that some kind of geometry LOD system is used )
Doesnt use of w-buffer negate effects of early-Z optimisations/z-compression ?

heres what DX8 SDK has to say on the subject

However ubiquitous, z-buffers do have their drawbacks. Due to the mathematics involved, the generated z values in a z-buffer tend not to be distributed evenly across the z-buffer range (typically 0.0 to 1.0, inclusive). Specifically, the ratio between the far and near clipping planes strongly affects how unevenly z values are distributed. Using a far-plane distance to near-plane distance ratio of 100, 90% of the depth buffer range is spent on the first 10% of the scene depth range. Typical applications for entertainment or visual simulations with exterior scenes often require far plane/near plane ratios of anywhere between 1000 to 10000. At a ratio of 1000, 98% of the range is spent on the 1st 2% of the depth range, and the distribution gets worse with higher ratios. This can cause hidden surface artifacts in distant objects, especially when using 16-bit depth buffers (the most commonly supported bit-depth).
A w-based depth buffer, on the other hand, is often more evenly distributed between the near and far clip planes than z-buffer. The key benefit is that the ratio of distances for the far and near clipping planes is no longer an issue. This allows applications to support large maximum ranges, while still getting relatively accurate depth buffering close to the eye point. A w-based depth buffer isn't perfect, and can sometimes exhibit hidden surface artifacts for near objects.

[/quote]

 

[SuperCow]

If you're using the standard D3D functions to create a projection matrix almost 100% of your depth buffer accuracy depends on your front clipping plane value. For instance going from 0.1 to 10 for your front clip plane will give you 100x as much depth accuracy.
Of course if you set it too high then you'll get missing triangles when the camera is very close to an object but it shouldn't happen that often in a game.
Derek I suppose you've already been playing with this value to get your accuracy back? Out of interest what front clip plane distance does your game use?

 

[Reverend]

Derek, I think question 3 refers to what technology that you'd like to see (that doesn't exist in any current hardware, real or paper).

 

[antlers]

After all, 24-bit means you have ~16M possible Z-buf values.. even if you waste 98% of those values on close range ( 2% of max depth displayed) , you still have 300K possible values left for remaining range. I cant imagine a situation when this precision isnt sufficient ( assuming of course, that some kind of geometry LOD system is used )

Because of the hyperbolic distribution Z buffer values across the range of depths, even a 24 bit Z buffer is inadequate in certain situations. Assume you draw objects out to 10,000 times the depth of the close clipping plane. With a 24 bit hyperbolic Z buffer, Z buffer errors at that range can be 2 or 3 x the depth of the close clipping plane.

Say you have a FP shooter on a very large map with terrain. For a FPS, the close clipping plane kind of has to be reasonably close to the POV, maybe 20 centimeters. Say you are a soldier looking for a tank. You can see it easily at 2 km (10,000x clipping plane distance) if it is in front of a tree. If it is behind a tree, you can't see it. The Z buffer error could be enough so that it isn't rendered properly in-front of or behind the tree. LOD isn't applicable in this situation; even if the tank is rendered in low detail, whether it is rendered in front or behind complex terrain has gameplay considerations. The same problem will crop up in any game that requires a large dynamic range of depths and sizes of objects (such as Derek's).

In the same situation, you could use a W buffer to have 1 mm of depth precision throughout. In DX9, it seems as though it will be possible to work around the absence of a hardware W buffer with a pixel shader--but of course there is a fill rate hit, and you can't take advantage of Z-check bandwidth saving measures.

You could also try and solve the problem by throwing in enough fog so you can't see out to 10,000x the clipping plane distance, but isn't that the sort of thing we are trying to avoid with hardware and API advances?

The Z-buffer error is approximately proportional to the square of the ratio of the depth of the object to the depth of the near clipping plane, while W buffer error is constant at all depths.

 

[Derek Smart [3000AD]]

Derek I suppose you've already been playing with this value to get your accuracy back? Out of interest what front clip plane distance does your game use?

Nope. I haven't touched it yet because its going to take some tweaking. On the 9xxx series, its currently falling back to Z buffer (24bit in this case) if CAPS reports no W buffer and with some visible artifacts in some cases.

My clip planes are not not fixed. They are dynamic because (as I mentioned in that ATI thread), the engine uses a method of partitioning and dynamically scaling the buffer - in realtime - depending on the circumstances. However, the default seeding values for near/far is 0.001f/20000.0f and this gets adjusted in real-time depending on the space partioning and adherence with DX suggested ratio for these values.

Here is a cut 'n paste jobbie from that other thread

I am not in the mood to give anyone programming lessons on the merits and benefits of using a W buffer. Go buy a good 3D book or search the net. My BC series of games, so far, have the largest game world in the history of the gaming industry. A single space area alone, which measures something like 2,121,306 km in 3 dimensions, can contain a scene with the following models.

station         // very large @ approx 12424.27M (H) x 27882.35M (W) x 27880.98M (L) 
carrier ship    // large @ approx 486 (H) x 975 (W) x 2268 (L)
person  // small @ 1.75m (H) x 0.64m (W) x 0.43m (L)

In this scene, you can have the ship, station and person (a space marine as seen in these BCG shots I released yesterday) in the same frame and proximity. Take a wild guess what happens in this instance.

In fact, the my rendering engine has technology I call space partitioning which does just that: partitions the W/Z buffer in order to reduce the effects of low precision/range.

So yes, the lack of a W buffer will produce a bunch of artifacts on these boards. But hey, in a world where gamers are used to seeing artifacts such as clipping, tearing, shearing, pixelation etc, I guess this is OK, right?

Derek, I think question 3 refers to what technology that you'd like to see (that doesn't exist in any current hardware, real or paper).

uhm, hmm. Thats not how I understood it.

At any rate, I can't think of any bleeding edge technology that I'd like to see in the future. What I would like to see are faster boards and widespread support for 128 bit color and more stable drivers.

In the same situation, you could use a W buffer to have 1 mm of depth precision throughout. In DX9, it seems as though it will be possible to work around the absence of a hardware W buffer with a pixel shader--but of course there is a fill rate hit, and you can't take advantage of Z-check bandwidth saving measures.

You could also try and solve the problem by throwing in enough fog so you can't see out to 10,000x the clipping plane distance, but isn't that the sort of thing we are trying to avoid with hardware and API advances?

The Z-buffer error is approximately proportional to the square of the ratio of the depth of the object to the depth of the near clipping plane, while W buffer error is constant at all depths.

Exactly. Even with a W buffer, you still run into some problems (thats 100% due to the size of my universe) and thats where buffer space partitioning comes into play.

Yes, its all my fault. I don't think they [IHVs] had any idea that anyone would wake up one morning and decide to create a game in which the regions are so mind bogglingly large.

....but thats because devs are used to developing certain types of games that are always in this closed and restricted area. When I designed my BC games, it was with the idea that I had to capture the feel of the large expanse of space and thats exactly what I did. To this day, it seems as if the hardware and api technologies still haven't caught up yet. They're still playing tag and I'm left to come up with solutions as problems creep up. The story of my life.

I had really hoped for, at a minimum, a 32 bit Z buffer in all next gen cards (Pahrelia, 9xxx, NV30). So far, I see no reason why this can't be done, but it seems as if nobody thinks its worth the effort. What I didn't expect was for ATI to flat out remove W buffer support from the hardware, just because MS hinted at it being unsupported in DX9. Oh well.

 

[Rodéric]

The nvidiots and the ATI campers are going to continue deploying weapons of mass destruction at the borders, remain firmly entrenched in said camps and sit it out. Hoping that the other side caves in

LOL
And that's so true.
It can be applied to the consoles too.

(see the FanBoyLand forum... err Console forum in here)

 

[jb]

Derek,

thanks for your time. Most of us figured on #1 but its nice to get confirmation. And on #3 I was hoping to get and idea of new hardware features you might want to see for future...

Thanks again!

 

[MDolenc]

]I had really hoped for, at a minimum, a 32 bit Z buffer in all next gen cards (Pahrelia, 9xxx, NV30). So far, I see no reason why this can't be done, but it seems as if nobody thinks its worth the effort. What I didn't expect was for ATI to flat out remove W buffer support from the hardware, just because MS hinted at it being unsupported in DX9. Oh well.

Hm... Wasn't there a driver from NVidia once that exposed 32 bit z-buffer? Meybe if you bug them (a lot) ... Also doesn't Matrox support 32 bit z-buffer (I think I saw somewhere a pice of code with D3DFMT_D32 and connection to Matrox, but I'm not really sure)?
It seams however that most stuff is going to be "do it yourself if you want it" in next gen ...

 

[no_way]

..Say you are a soldier looking for a tank. You can see it easily at 2 km (10,000x clipping plane distance) if it is in front of a tree. If it is behind a tree, you can't see it. The Z buffer error could be enough so that it isn't rendered properly in-front of or behind the tree...

Thats kind of a LOD issue, not an object-scale LOD but scene-scale LOD.
At 2 km, with bare eyes, how big would a rendered tree be at reasonable resolution ? 8x2 pixels perhaps ? ( just a ballpark figure ).
In such situation, simple software occlusion culling should take over, so the tank shouldnt be rendered at all.
At reasonable distance, semi-transparent objects are usually treated as solid, so they actually become occluders.
If you get visible rendering artifacts due to lack of rendering precision on current generation of graphics cards, its time to reconsider your rendering pipeline architecture ( as mr. Smart has obviously done already, with his partitioning approach )
I still cant think of a situation where even 16-bit z-buffer isnt sufficient. w-buffer doesnt buy you much in terms of additional accuracy. All it does, it distributes the precision range around differently.

 

[antlers]

..Say you are a soldier looking for a tank. You can see it easily at 2 km (10,000x clipping plane distance) if it is in front of a tree. If it is behind a tree, you can't see it. The Z buffer error could be enough so that it isn't rendered properly in-front of or behind the tree...

Thats kind of a LOD issue, not an object-scale LOD but scene-scale LOD.
At 2 km, with bare eyes, how big would a rendered tree be at reasonable resolution ? 8x2 pixels perhaps ? ( just a ballpark figure ).
In such situation, simple software occlusion culling should take over, so the tank shouldnt be rendered at all.

I don't think software occlusion culling is that simple if you have 20 tanks that may occlude each other and maybe 2000 trees and are doing hardware transforms. The size of the objects is also kind of irrelevant; Mr. Smart's game is working with much larger objects than tanks or trees.

If you get visible rendering artifacts due to lack of rendering precision on current generation of graphics cards, its time to reconsider your rendering pipeline architecture ( as mr. Smart has obviously done already, with his partitioning approach )

Yes, if you have no choice, you can reconsider your rendering pipeline. I think the complaint was that you would expect a new generation of cards to make things easier for technically demanding games, not to break currently working implementation methods.

I still cant think of a situation where even 16-bit z-buffer isnt sufficient. w-buffer doesnt buy you much in terms of additional accuracy. All it does, it distributes the precision range around differently.

A one meter Z buffer error versus a 1 mm W buffer error does seem like the W buffer is buying you something. Yes, with a W buffer, you are more likely to get small artifacts with close objects. But you are less likely to get large, gameplay significant artifacts on distant objects if your game design demands scenes that include both small nearby objects and large distant objects.

 

[Simon F]

A one meter Z buffer error versus a 1 mm W buffer error does seem like the W buffer is buying you something. Yes, with a W buffer, you are more likely to get small artifacts with close objects. But you are less likely to get large, gameplay significant artifacts on distant objects if your game design demands scenes that include both small nearby objects and large distant objects.

An even better system is to use a floating point 1/W (or equivalently W) buffer. This provides a constant relative precision, approx 1 part in 2^mantissa size.

Up close, where you might be looking at small objects, you can place them very accurately. In the far distance (where you can't see small objects) large objects, eg mountains, can be positioned with the same relative accuracy.

 

[KimB]

Hm... Wasn't there a driver from NVidia once that exposed 32 bit z-buffer?

I'm not sure it really did support a 32-bit z-buffer. I really think that the CAPS reported that support incorrectly, and a 24-bit z was used.

At the very least, it was almost certainly not a 32-bit z-buffer with an additional alpha buffer (which is really what's needed).