Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / A question of Z Buffer precision.

Author
Message
sydbod
16
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 3rd Nov 2008 14:07
Would any one know what the precision setting is that the current Dark GDK is setting within video cards.

32 bit z buffers have been around for a long time (in computer time), but with the massive Z fighting problems I am seeing in some of my programs, I can only assume that this SDK is using 16Bit or 24Bit settings.

I know that the near/far settings are way outside for what is normally recommended on this site, ( I use 0.3 / 300,000 ), but for a Z buffer setup of 32 Bit that should not be of any significance.
With those setting and a 32bit Z buffer at a range of 3,000 units the Z buffer error should be no more than a small poofteenth of a unit. I get the impression I see a much much larger error than that.

Is there a way to force the video card to use 32Bit mode for the Z buffer?
IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 3rd Nov 2008 21:27
It uses the highest precision that your drivers make available. If you are suffering from z-fighting, it's because of your camera range and the closeness of your objects at higher distances.

One possible way to fix this is to replace the standard camera projection matrix with your own. You can do this either using a vertex shader, or by accessing the camera projection matrix - I don't have the GDK installed right now, so take the following code as untried (and possibly completely wrong):


The details of what this does and how it works are here

Attachments

Login to view attachments
sydbod
16
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 4th Nov 2008 00:10 Edited at: 4th Nov 2008 01:19
Thanks IanM,

I will have to make some accurate measurements with intersecting 3D objects to get an exact idea of what the Z Buffer is actually set to on this video card (HD 4850 ... it should be 32 bit).

I will study what you have posted when I get home tonight. Thanks for that.

I was also looking at rewriting my rendering with a BSP approach where all terrains get split into above water level and below water level meshed (can automate that with code), then render the below water level meshes, followed by the transparent water mesh, followed by the remaining meshes. This should solve any Z fighting with the water (the biggest problem).
Do you have any insight into how one may make 3 independent render passes like the above, within Dark GDK?

Maybe even running 2 cameras from the same view point with one set to 0.3 / 300 and the other set to 300 / 300000 . Then to find a way to overlap the images on a view plane.

EDIT: I also came across that article last night (linear depth values using a Z-buffer) but had no idea how I could implement it .... Thanks for the code. This will be the first approach to try.
It may even be interesting to transform the profile into a semi linear profile to get a better balance if the calculation does not add too much overhead.

EDIT2: D3DXMatrixPerspectiveFovLH( D3DXMATRIX *pOut, FLOAT fovy, FLOAT Aspect, FLOAT zn, FLOAT zf )
sydbod
16
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 4th Nov 2008 04:42 Edited at: 4th Nov 2008 09:11
@ IanM,

Just an update

My camera configuration function



The variables used for you code additions


The camera setupfunction call and initialization code



The code at the bottom of the game loop to implement the change



This is the view I should get




This is the view I do get


It looks like the camera center point is also moved to track around a circle from the original camera center point when one rotates the camera, or it may just be the distorted image that makes it look that way.

Somehow the field of view looks screwy as one can see the flight of 31 aircraft beside the camera stretched an the right side of the screen capture, when they should not be visible.

I hope you may be able to assist here as this area is beyond my capabitliies (knowledge).

EDIT: I am using a 4096x4096 texture on the land mass for testing purposes, but that should not be causing problems.
If this feature could be integrated into a Dark GDK release, it would be beneficial to a lot of people on this forum that also have similar z problems.
sydbod
16
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 4th Nov 2008 15:26 Edited at: 4th Nov 2008 15:41
@ IanM,

My apologies for my stupidity, but after looking at the code and doing a bit more research I think I have figured it out to some extent.

Everything is done within the game setup ..... in actual fact in the camera setup file is the best place.



I got caught out also because when running as default camera the FOV command uses Degrees, where as the FOV entry in the additional code has to be in Radians.

Now the image all looks reasonable.

Now it looks like the precision is too coarse ...... but I will have to do more testing.
Time for bed but when I have made some measurements, I will post the results.
sydbod
16
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 4th Nov 2008 16:19 Edited at: 4th Nov 2008 16:22
It kept bugging me so here are some measurements.

With the modified camera code to produce a linear Z Buffer:

If one for argument sake calculates for a 16 Bit Z Buffer, the following results are expected.

float fFar = 300000.0f;
16Bit Z Buffer gives 65535 steps
distance resolution of ~4.6 game units.

Lets look at a screen capture with the new code.


This is a screen grab of a string of aircraft spaced 5 game units apart.

One can notice in the picture that the second closest aircraft has parts of its model breaking through the closest aircraft.(the tail and the propeller)

This suggests that the Z Buffer resolution is around 5 game units.

This suggests that the game has set up the Z buffer to run in 16 Bit mode rather than the 32 Bit mode that we are expecting.

Are we still that confident that the Z Buffer gets set to the highest value that the video card can support.

This video card can support 32Bit Z buffer mode (ATI HD4850 ).

Hopefully I have not made a major blunder somewhere.
Diggsey
18
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 4th Nov 2008 18:36
None of these are Z-fighting issues, they are you putting the objects in the wrong place...

[b]Yuor signutare was aresed by a deslyxic mud...
BOX2D V2 HAS HELP FILES! AND A WIKI!
jezza
16
Years of Service
User Offline
Joined: 8th Mar 2008
Location: Bham, UK
Posted: 4th Nov 2008 18:38
No, that's a z buffer problem, unless you have scaled the first object to smaller I doubt its to do with the resolution though.
IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 4th Nov 2008 19:19
Still suffering with the problem huh? I'll get the GDK installed again tonight and see what I can find out.

In the meantime, can you check that your video settings are not forcing the z-buffer to 16 bits? Also, do you get different results when you force to 32 bits?

sydbod
16
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 4th Nov 2008 23:01 Edited at: 4th Nov 2008 23:03
Quote: "check that your video settings are not forcing the z-buffer to 16 bits? Also, do you get different results when you force to 32 bits?"


That is my problem .... I am just a noob with programing.
How does one get access to the Z buffer setup.

Any suggestions anybody about code fragments to read or write to the setup of the Z buffer?
IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 4th Nov 2008 23:14
You can set it up via your display settings. For example, I have an Intel graphics chip on this system I'm using right now - it has a button labelled 3D settings where I can set all sorts of stuff, including the Z-Buffer depth. It's usual to set it to 'default' or 'set by program' or similar, but you can force a depth setting too.

Both NVidia and ATI have equivalent settings hidden away somewhere in their display settings applications.

sydbod
16
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 5th Nov 2008 05:58
First observation, CCC does not have a means to select and lock the Z buffer mode.

I installed ATI Tray Tools as it has the selections under "3D" of
"Force Z buffer depth" ->
"Disable"
"Force 16 bit"
"Force 24 bit"

It makes no difference what I select here the Z jitter is the same under all settings.

When I use the default video mode, all the Z buffer selections produce the exact same Z fighting.

When I use the linear Z buffer code, all the selections produce the exact same visual responses again, one to the next.

It is looking like I have no way to externally get access to locking the Z buffer with these later video cards, so I have no way of confirming exactly what Z mode the card is running in.

All I know is that the Z fighting is a disaster when using the library, but when using another premade game, with similar near far settings, there is virtually no visiable Z fighting.
IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 5th Nov 2008 14:17
That's steering me even more towards blaming your camera ranges. The ratio of near to far is very high - so high that I'd pretty much expect you to have issues no matter what the depth of your z-buffer is.

You may need to switch to rendering things using multiple cameras - I'll put together a simple demo to show you how it can be done. It will be slower though as you'll be rendering twice to get the one scene.

sydbod
16
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 5th Nov 2008 15:12
I am not certain that the video card is actually being controlled properly with the BETA version of the ATI Tray Tools ..... I will try to resurrect an older Nvidia based machine on the weekend and also try the testing on that with the linear Z version.

This whole area of research is becoming very interesting.

If it is possible to concatenate 2 camera images, then that would be a very useful bit of code ..... and who knows it may be possible to multithread it and make some use of all those 2 core and 4 core machines out there.

Again, many thanks for your valuable assistance.
IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 5th Nov 2008 18:16
Here's the example:


Things to remember:
- The cameras are rendered in sequence, so you need to arrange your camera ranges from far to near.
- If you need the backdrop, make sure it's enabled only for the first camera rendered.

You can't multithread this in its current state - it requires the cameras to be rendered sequentially, finishing one before starting another.

It might be possible to multithread rendering in general as long as you render each camera range to its own texture and then combine the textures into a final render at the end. Not sure how you'd go about that in the GDK though.

sydbod
16
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 6th Nov 2008 03:44
Thanks IanM.

It works like a charm.

It would be great if you were to post your code sample in the Code Fragments thread so others can also find it easily.

I don't know the inner workings of how the game SDK gets created, but it would be very good if thought was given having the camera creation code modified within the SDK so that as soon as a near/far selection is being used that is becoming unsuitable, then the camera functions automatically assign a second camera with maybe a negative ID number to the first camera, and uses this procedure.

The small processing slowdown would only come into affect when the large dynamic distance ranges are selected, and this operation would be transparent to the programmer.
IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 6th Nov 2008 14:19
What is 'unsuitable'?

If you get obvious z-fighting, then it's a problem, but if you move your objects a little further apart, the problem disappears. So when will be the correct time to create this extra camera? What happens if you still get z-fighting? Create a third camera? With what ID?

How will the near/far ranges be broken down when the new camera is created? 50:50 isn't the right way and equality of the ratios near:far may not be either - you might allow a little z-fighting at further distances simply because it's harder to notice.

I'm of the belief that what we have is good enough, and it's flexible enough to solve these issues - change the camera ranges, suffer the z-fighting, or suffer the cost of extra renders - I don't believe that there's an automatic method that will fit everyone, but that the current system *is* flexible enough to fit.

sydbod
16
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 6th Nov 2008 15:24
Quote: "What is 'unsuitable'?"


I agree ... it is a very hard thing to quantify.

I have noticed lately that there have been some posts dealing with Z-fighting problems.

It appears that a significant number of newer people come across it and the usual advice is to decrease the near:far ratio.

With this 2 camera approach, and splitting the near/far ratio to 2 equal ratio groups near: medium and medium:far each of the same ratio, I could no fault the results I have now obtained.(yes I am tickled pink)

I suspect that this z-fighting problem will be a continuing problem for the continuous inflow of new members, and I felt there may be merit in trying to integrate this approach transparently within the code.

Mind you, I am just a noob with a very blinkered view of this whole topic so obviously the people with a more global overview will be the ones who will make the proper decision.

Once again, thanks for the great and freely given assistance. It is this sort of help that makes this forum a pleasure for many of us to be members of.

Login to post a reply

Server time is: 2024-11-25 05:53:56
Your offset time is: 2024-11-25 05:53:56