programmable clipping

humus im not sure what you mean by that any game that had huge draw distances would also let you see things right next to you

ps: since your here would it be difficult to write an app (remembering dxoveride) that exports the cap "NONPOW2CONDITIONAL" to a game
 
humus im not sure what you mean by that any game that had huge draw distances would also let you see things right next to you
The depth buffer isn't fixed between a range of values - it's set by the application (using the near and far z planes). However, with a 32-bit depth buffer, you only have ~4 billion different values, with an exponential falloff in precision the further away you get from the camera.

An application could arbitrarily say that it measured distances in lightyears, and set their far z plane 10^30 units away. Then the application would have a draw distance of 10^30 lightyears - but good luck representing day-to-day distances (metres) at any sort of precision with those settings.

The point is that actual numbers of distance don't matter - it's the ratios.
 
The depth buffer isn't fixed between a range of values - it's set by the application (using the near and far z planes). However, with a 32-bit depth buffer, you only have ~4 billion different values, with an exponential falloff in precision the further away you get from the camera.

An application could arbitrarily say that it measured distances in lightyears, and set their far z plane 10^30 units away. Then the application would have a draw distance of 10^30 lightyears - but good luck representing day-to-day distances (metres) at any sort of precision with those settings.

The point is that actual numbers of distance don't matter - it's the ratios.
Agreed.

That's exactly the problem I see with the z-buffer.

Doesn't matter how many bits of precision with the z-buffer, you still won't get good precision far away from the camera.

Sure the distance may be long as hell, but they don't appear long as hell due to the nature of the z-buffer.

Besides, how many games with the z-buffer give you good precision far above and far below? Practically none.

Bloodrayne 2 does but it had z-fighting errors so that's probably why you don't see many recent games that look like that.
 
Doesn't matter how many bits of precision with the z-buffer, you still won't get good precision far away from the camera.
With a float Z buffer shader precision is more of an issue than Z buffer precision.

Making claims about "the nature of the z-buffer" without even knowing what it's used for is not a good basis for discussion.
 
Just Cause 2 - pic?

Nope. That's the first pic that showed up on a google image search on "Just Cause".

since your here would it be difficult to write an app (remembering dxoveride) that exports the cap "NONPOW2CONDITIONAL" to a game

Just modifying the caps bit shouldn't be too hard I guess.

Doesn't matter how many bits of precision with the z-buffer, you still won't get good precision far away from the camera.

With a floating point z-buffer and a reversed projection matrix (far plane = 0, near = 1) you get a pretty even precision distribution across the whole range.
 
Just modifying the caps bit shouldn't be too hard I guess.

Oh Mighty Humus, be aware that I am currently in the process of assembling an international team of crimson skies fans we are going to fly to sweden kidnap you, tie you to a chair and poke you with a pointy stick untill you promise to fix the game.

here's the official explaination from nvidia it may help.

"The reason for the corruption is because the game doesn't check correctly for the support of Nonpower of two textures. The Forceware driver now have an unlimited support for Nonpow2 textures. That means we don't export the caps NONPOW2CONDITIONAL anymore. However the game misinterprets this as we don't support Pow2 and/or nonpow2 textures."

Do not take this lightly we do have a Rubber Chicken and are not afraid to use it...........
 
/Goes out to buy a second rubber chicken

is it called directx tweaker i found beta 3 but when i run it it says expired :(
 
Last edited by a moderator:
2 questions:

what are all the differences between the w-buffer and an 32 bit fp inverted z-buffer?

I know one is that the w-buffer is more linear in distribution, but I don't know much more than that.

even though a 32 bit fp inverted z-buffer isn't a perfect replacement can it do everything a w-buffer can do and just as well?

I just wish they'd do away with the depth buffer altogether and just have have HW programmable clipping.
 
I don't understand. How can you ask a question like this:

2 questions:

what are all the differences between the w-buffer and an 32 bit fp inverted z-buffer?

I know one is that the w-buffer is more linear in distribution, but I don't know much more than that.

even though a 32 bit fp inverted z-buffer isn't a perfect replacement can it do everything a w-buffer can do and just as well?

and make a statement like this

I just wish they'd do away with the depth buffer altogether and just have have HW programmable clipping.
in the same post at a place like this with a straight face?
 
what are all the differences between the w-buffer and an 32 bit fp inverted z-buffer?

I know one is that the w-buffer is more linear in distribution, but I don't know much more than that.

Both are linear, but in different ways. The W-buffer is linear in scene depth, but it's non-linear pixel-to-pixel in screen space. A Z-buffer is linear pixel-to-pixel in screen space, but non-linear in scene depth. Intuitively the W-buffer sounds like the better choice, unless you're the one designing the hardware. The linearity in screen-space of Z-buffer means you can create much simpler hardware for interpolating Z, it also means that the resulting Z values are highly compressible which makes techniques like Z-compression possible. The disadvantage is that precision is distributed in a non-linear fashion. However, if you're working with floating point numbers, which are non-linear in themselves, you can make the non-linearities sort of cancel each other out. That's what the inverted projection is all about. If you map the far plane to 0 and near to 1, you get a depth distribution that's not quite linear, but good enough, while maintaining the advantages of a Z-buffer.
 
Ok, let's recap:

"Awesome! Great draw distance!"
shadow_screen002.jpg


"Boo! Z-buffer artifacts!"
giants002_640w.jpg



Seems a bit weird to me, but let's try another set of pictures, I think I start to understand what you're trying to say.

Now IQ, which of these pictures would you say is more w-buffered?
This one:
notweaks-big.jpg


Or this one:
noaa-3lodnoaniso-big.jpg
 
ps: the "Boo! Z-buffer artifacts!" picture
doesnt have any Z-buffer artifacts its alaising
not enough pixels to draw the trees properly


ps: regarding the jedi outcast/academy pics
looks like the 2nd pic has af applied
 
Ok, let's recap:

"Awesome! Great draw distance!"
shadow_screen002.jpg


"Boo! Z-buffer artifacts!"
giants002_640w.jpg



Seems a bit weird to me, but let's try another set of pictures, I think I start to understand what you're trying to say.

Now IQ, which of these pictures would you say is more w-buffered?
This one:
notweaks-big.jpg


Or this one:
noaa-3lodnoaniso-big.jpg
That's JK 2 which uses the z-buffer due to the fact that opengl didn't use the w-buffer. Looks like it uses the w-buffer tho, but it don't.
 
Back
Top