Discussion:
[Algorithms] Dynamic near/far clipping planes
De Boer
2003-07-16 06:18:01 UTC
Permalink
Is it possible to keep changing the near/far clipping plane to keep z buffer
precision where you currently need it. For example say you have a large
terrain and a bit of water with z fighting problems at the edges. Is it
possible to draw the bit of terrain in the distance with distant near/far
clipping planes and then draw the close section with water with closer
near/far clipping planes? Does this technique have a name which may help me
find papers etc on this technique?

-Ryan De Boer
Igor Kravtchenko
2003-07-16 06:58:07 UTC
Permalink
In other words, you would want to change dynamically your znear/zfar to adjust z precision ?
In such case, the answer is no. The problem is that only revelant to the API you are using, so
some people could think it's already off-topic. Indeed such API like D3D "scales" the precision
of the ZBuffer depending of the range of your znear/zfar and the 3D card capability (old voodoo
cards used for instance an internal float16 for their WBuffer and a 32 bits integer where only
hiword was stored for their ZBuffer).

To be short : you cannot rely on modifying dynamically znear/zfar while rendering to solve
z-fighting problem.

Igor.


----- Original Message -----
From: De Boer
To: gdalgorithms-***@lists.sourceforge.net
Sent: Wednesday, July 16, 2003 10:17 AM
Subject: [Algorithms] Dynamic near/far clipping planes


Is it possible to keep changing the near/far clipping plane to keep z buffer
precision where you currently need it. For example say you have a large
terrain and a bit of water with z fighting problems at the edges. Is it
possible to draw the bit of terrain in the distance with distant near/far
clipping planes and then draw the close section with water with closer
near/far clipping planes? Does this technique have a name which may help me
find papers etc on this technique?

-Ryan De Boer



-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
_______________________________________________
GDAlgorithms-list mailing list
GDAlgorithms-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=6188
Paul Firth
2003-07-16 07:20:18 UTC
Permalink
Could you change the near / far planes over time as you (ie. not within a frame) so that when you were looking at the water the near plane could move out, thus improving precision?

Cheers, Paul.
----- Original Message -----
From: Igor Kravtchenko
To: gdalgorithms-***@lists.sourceforge.net
Sent: Wednesday, July 16, 2003 9:57 AM
Subject: Re: [Algorithms] Dynamic near/far clipping planes



In other words, you would want to change dynamically your znear/zfar to adjust z precision ?
In such case, the answer is no. The problem is that only revelant to the API you are using, so
some people could think it's already off-topic. Indeed such API like D3D "scales" the precision
of the ZBuffer depending of the range of your znear/zfar and the 3D card capability (old voodoo
cards used for instance an internal float16 for their WBuffer and a 32 bits integer where only
hiword was stored for their ZBuffer).

To be short : you cannot rely on modifying dynamically znear/zfar while rendering to solve
z-fighting problem.

Igor.


----- Original Message -----
From: De Boer
To: gdalgorithms-***@lists.sourceforge.net
Sent: Wednesday, July 16, 2003 10:17 AM
Subject: [Algorithms] Dynamic near/far clipping planes


Is it possible to keep changing the near/far clipping plane to keep z buffer
precision where you currently need it. For example say you have a large
terrain and a bit of water with z fighting problems at the edges. Is it
possible to draw the bit of terrain in the distance with distant near/far
clipping planes and then draw the close section with water with closer
near/far clipping planes? Does this technique have a name which may help me
find papers etc on this technique?

-Ryan De Boer



-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
_______________________________________________
GDAlgorithms-list mailing list
GDAlgorithms-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=6188

intY has scanned this email for all known viruses (www.inty.com)
Brano Kemen
2003-07-16 07:53:01 UTC
Permalink
Is it reasonable to render one part of terrain, say from 10km to 50km,
then clear the depth buffer and render another part with farplane at
10km? The second part would be always in front of the first one.
I can have visibility more than 50km, and I'm having z-fighting
problems, as can be seen on the screenshots (that z-island in the water
plane)

Loading Image...
Loading Image...
Loading Image...

Can anyone suggest what can be done about it, without significantly
loosing performance?

Brano Kemen
Post by Igor Kravtchenko
In other words, you would want to change dynamically your znear/zfar to
adjust z precision ?
In such case, the answer is no. The problem is that only revelant to the
API you are using, so
some people could think it's already off-topic. Indeed such API like D3D
"scales" the precision
of the ZBuffer depending of the range of your znear/zfar and the 3D card
capability (old voodoo
cards used for instance an internal float16 for their WBuffer and a 32
bits integer where only
hiword was stored for their ZBuffer).
To be short : you cannot rely on modifying dynamically znear/zfar while rendering to solve
z-fighting problem.
Igor.
----- Original Message -----
*Sent:* Wednesday, July 16, 2003 10:17 AM
*Subject:* [Algorithms] Dynamic near/far clipping planes
Is it possible to keep changing the near/far clipping plane to keep z buffer
precision where you currently need it. For example say you have a large
terrain and a bit of water with z fighting problems at the edges. Is it
possible to draw the bit of terrain in the distance with distant near/far
clipping planes and then draw the close section with water with closer
near/far clipping planes? Does this technique have a name which may help me
find papers etc on this technique?
-Ryan De Boer
Igor Kravtchenko
2003-07-16 09:09:07 UTC
Permalink
Yes absolutely.
As Nicholas suggested you can do several passes by clearing and re-adjusting each time your depth buffer.

It just only works if you can indeed "cut" your world into distincts layers that can be superposed to produce
the final image. Otherwhise Z values would mismatch between layers and result would be bugged.

Igor.


----- Original Message -----
From: Brano Kemen
To: gdalgorithms-***@lists.sourceforge.net
Sent: Wednesday, July 16, 2003 11:49 AM
Subject: Re: [Algorithms] Dynamic near/far clipping planes


Is it reasonable to render one part of terrain, say from 10km to 50km,
then clear the depth buffer and render another part with farplane at
10km? The second part would be always in front of the first one.
I can have visibility more than 50km, and I'm having z-fighting
problems, as can be seen on the screenshots (that z-island in the water
plane)

http://manabove.org/terrain/images/v2/47-8m.jpg
http://manabove.org/terrain/images/v2/46-2.jpg
http://manabove.org/terrain/images/v2/46-1.jpg

Can anyone suggest what can be done about it, without significantly
loosing performance?

Brano Kemen
Post by Igor Kravtchenko
In other words, you would want to change dynamically your znear/zfar to
adjust z precision ?
In such case, the answer is no. The problem is that only revelant to the
API you are using, so
some people could think it's already off-topic. Indeed such API like D3D
"scales" the precision
of the ZBuffer depending of the range of your znear/zfar and the 3D card
capability (old voodoo
cards used for instance an internal float16 for their WBuffer and a 32
bits integer where only
hiword was stored for their ZBuffer).
To be short : you cannot rely on modifying dynamically znear/zfar while rendering to solve
z-fighting problem.
Igor.
----- Original Message -----
*Sent:* Wednesday, July 16, 2003 10:17 AM
*Subject:* [Algorithms] Dynamic near/far clipping planes
Is it possible to keep changing the near/far clipping plane to keep z buffer
precision where you currently need it. For example say you have a large
terrain and a bit of water with z fighting problems at the edges. Is it
possible to draw the bit of terrain in the distance with distant near/far
clipping planes and then draw the close section with water with closer
near/far clipping planes? Does this technique have a name which may help me
find papers etc on this technique?
-Ryan De Boer
-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
_______________________________________________
GDAlgorithms-list mailing list
GDAlgorithms-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=6188
Lucas Ackerman
2003-07-16 16:44:02 UTC
Permalink
Here's a silly question: could you just make the water deeper instead of
playing Z games?

-Lucas
Post by Brano Kemen
Is it reasonable to render one part of terrain, say from 10km to 50km,
then clear the depth buffer and render another part with farplane at
10km? The second part would be always in front of the first one.
I can have visibility more than 50km, and I'm having z-fighting
problems, as can be seen on the screenshots (that z-island in the
water plane)
http://manabove.org/terrain/images/v2/47-8m.jpg
http://manabove.org/terrain/images/v2/46-2.jpg
http://manabove.org/terrain/images/v2/46-1.jpg
Can anyone suggest what can be done about it, without significantly
loosing performance?
Brano Kemen
Post by Igor Kravtchenko
In other words, you would want to change dynamically your znear/zfar
to adjust z precision ?
In such case, the answer is no. The problem is that only revelant to
the API you are using, so
some people could think it's already off-topic. Indeed such API like
D3D "scales" the precision
of the ZBuffer depending of the range of your znear/zfar and the 3D
card capability (old voodoo
cards used for instance an internal float16 for their WBuffer and a
32 bits integer where only
hiword was stored for their ZBuffer).
To be short : you cannot rely on modifying dynamically znear/zfar
while rendering to solve
z-fighting problem.
Igor.
----- Original Message -----
*Sent:* Wednesday, July 16, 2003 10:17 AM
*Subject:* [Algorithms] Dynamic near/far clipping planes
Is it possible to keep changing the near/far clipping plane to keep z buffer
precision where you currently need it. For example say you have a large
terrain and a bit of water with z fighting problems at the edges. Is it
possible to draw the bit of terrain in the distance with distant near/far
clipping planes and then draw the close section with water with closer
near/far clipping planes? Does this technique have a name which may help me
find papers etc on this technique?
-Ryan De Boer
Brano Kemen
2003-07-17 04:44:27 UTC
Permalink
no :)
there're always things near enough, that the z-buffer cannot segregate
at that depth
even if it did not flicker during motion, the rendered geometry would be
too coarse

besides, that's a 4000km x 4000km procedural world, and I don't feel
like running around and modifying zillion locations :)
and end up not having islands ..

Brano Kemen
Post by Lucas Ackerman
Here's a silly question: could you just make the water deeper instead of
playing Z games?
-Lucas
Post by Brano Kemen
Is it reasonable to render one part of terrain, say from 10km to 50km,
then clear the depth buffer and render another part with farplane at
10km? The second part would be always in front of the first one.
I can have visibility more than 50km, and I'm having z-fighting
problems, as can be seen on the screenshots (that z-island in the
water plane)
http://manabove.org/terrain/images/v2/47-8m.jpg
http://manabove.org/terrain/images/v2/46-2.jpg
http://manabove.org/terrain/images/v2/46-1.jpg
Can anyone suggest what can be done about it, without significantly
loosing performance?
Brano Kemen
Nicholas Francis
2003-07-16 07:23:06 UTC
Permalink
I'm forced to disagree here...

Although its correct that you can't scale zNear/far in an arbitrary
way, what the first poster proposed should definately work. eg.:

set zNear/zFar to span from 1 km to 20 km
clear depth buffer
draw distant landscape (further away than 1 km)
set zNear/zFar to span from 10cm to 1.5 km
Clear depth buffer
draw nearby landscape & water.

This is especially good for deep-space games where partitioning the
universe into different depth ranges is quite easy.

Cheers,
Nicholas

On onsdag, jul 16, 2003, at 10:57 Europe/Copenhagen, Igor Kravtchenko
Post by Igor Kravtchenko
 
In other words, you would want to change dynamically your znear/zfar
to adjust z precision ?
In such case, the answer is no. The problem is that only revelant to
the API you are using, so
some people could think it's already off-topic. Indeed such API like
D3D "scales" the precision
of the ZBuffer depending of the range of your znear/zfar and the 3D
card capability (old voodoo
cards used for instance an internal float16 for their WBuffer and a 32
bits integer where only
hiword was stored for their ZBuffer).
 
To be short : you cannot rely on modifying dynamically znear/zfar
while rendering to solve
z-fighting problem.
 
Igor.
 
 
----- Original Message -----
From: De Boer
Sent: Wednesday, July 16, 2003 10:17 AM
Subject: [Algorithms] Dynamic near/far clipping planes
Is it possible to keep changing the near/far clipping plane to keep z
buffer
precision where you currently need it. For example say you have a large
terrain and a bit of water with z fighting problems at the edges. Is it
possible to draw the bit of terrain in the distance with distant
near/far
clipping planes and then draw the close section with water with closer
near/far clipping planes? Does this technique have a name which may
help me
find papers etc on this technique?
-Ryan De Boer
-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
_______________________________________________
GDAlgorithms-list mailing list
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
http://sourceforge.net/mailarchive/forum.php?forum_id=6188
Jon Watte
2003-07-16 15:03:13 UTC
Permalink
Post by Paul Firth
Could you change the near / far planes over time as you (ie. not within a frame)
so that when you were looking at the water the near plane could move out, thus
improving precision?
Absolutely! In fact, you can do it within a frame, if you multi-pass; render the
really far away stuff first with a near plane of 500, then render the near stuff
with a near plane of 0.5 and a far plane of 1000 (just as an example).

The only rule is that you can't expect to test a Z value generated by one zrange
or projection matrix, against a z value generated by another range/projection, and
expect the comparision to be meaningful.

There are also some rules about when Z optimizations get disabled; if you clear
the Z buffer when you change your zrange or start the next pass, you'll be fine.

Note that the "far" value doesn't matter all that much -- you can actually make it
"infinite" and still have finite Z precision in the visible range (great trick for
stencil shadows, heavily promoted by NVIDIA sample code, btw). The "near" value is
what causes the aliasing.

Cheers,

/ h+
Continue reading on narkive:
Loading...