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 / Z Fighting / Flimmering / Z Buffer help

Author
Message
Yellow Billy Cat
18
Years of Service
User Offline
Joined: 4th Apr 2006
Location:
Posted: 4th Apr 2006 20:19
I seem to find myself between a rock and a near camera range.

I have an application that requires a slightly insane camera range. It consists of a gimbaled, controllable camera attached to the outside of an air vehicle. I need to be able to view the vehicle (distance from camera approx. 0.15 units) as well as distant objects (distance from camera approx 15,000 - 20,000 units). The camera has a FOV of 2.75 degrees. The camera range is set to a rivet popping 0.1 - 30000.0.

The problem is that the z-buffer is not accurate enough at that span and distance to separate the ground targets from the ground. Classic background popping through the foreground object issue.

A clear case of z-buffer abuse, I'm sure, but I'm looking for some guidance on being able to correctly view distant objects while allowing near objects to remain visible (to obstruct the camera when in the correct airframe / camera orientation, for example).

Is the SDK z-buffer 32 bit?
Does the SDK support the w-buffer?

Video hardware is ATI X850 XT PE.

Any help is appreciated.
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 5th Apr 2006 00:50
The z-buffer is the best supported by your video card, which is 32 bits for you. I don't believe that the SDK uses a w-buffer.

You may be able to play some tricks ...

Initially, halve your camera range.

Then for each frame:
Clear your display
Check every object. If it is within the camera range, hide it. Otherwise, move the object to half the distance, and halve its scale.
Sync to render all far objects.
Move these objects back to their original position and hide them. Unhide all of the other objects.
Sync to render all near objects over the top.
Unhide your objects
Repeat.

If half isn't enough, then divide everything by 3 or 4 instead for your distances/scales.

I don't know how well this will work, but it sounds good at least

For free Plug-ins and source code http://www.matrix1.demon.co.uk
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 5th Apr 2006 01:03
Another idea occurred to me.

You can set up two cameras. If you set the camera range of the default camera with a rance of 15000 to 30000, and create a new camera with a range of 0.1 to 15000 and have backdrop disabled on the new camera at least, then things seem to draw Ok too ... at least in DBPro they do.

If you don't mind converting to C++, here's the code I used to test the idea.


The price you pay is that there are two renders taking place. Not ideal, but all I can think of right now.

For free Plug-ins and source code http://www.matrix1.demon.co.uk
Morcilla
21
Years of Service
User Offline
Joined: 1st Dec 2002
Location: Spain
Yellow Billy Cat
18
Years of Service
User Offline
Joined: 4th Apr 2006
Location:
Posted: 5th Apr 2006 14:41
Morcilla,

The link in that thread is a great explanation of the behavior of the z-buffer and why I have the z-fighting issues. Unfortunately, my application requires a visual span that doesn't allow me to reduce the near or far settings.

IanM,

Thanks for the ideas. I'm going to run with the two camera suggestion. It's clever and simple, ususally a good sign. Two renders shouldn't be an issue as I have other SDK apps that have 3 camera views in a single window with good frame rates.

Again, thanks.
IanM
Retired Moderator
21
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 5th Apr 2006 15:28
I'm amazed that I managed to come up with that idea at that time of night (23:00 for me).

I've just checked again for objects that are placed at the border of the camera ranges, and it looks OK. If it works the same in the SDK, then it looks like you have a solution.

For free Plug-ins and source code http://www.matrix1.demon.co.uk
Yellow Billy Cat
18
Years of Service
User Offline
Joined: 4th Apr 2006
Location:
Posted: 5th Apr 2006 15:39
OK, this is clearly the Clever Solution of the Day!

Works great and it was painless to implement.

I did tweak the camera ranges a bit to
Near Camera: 0.1 to 100.0
Far Camera: 99.0 to 30000.0

No undesireable visual effects out to "10km" when the objects are just points anyway.

10 points for IanM!

Login to post a reply

Server time is: 2024-05-27 05:11:17
Your offset time is: 2024-05-27 05:11:17