From fatcity!root@news.cts.com  Wed Oct  6 19:10:12 1999
X-VM-Summary-Format: "%n %*%a %-17.17F %-3.3m %2d %4l/%-5c %I\"%s\"\n"
X-VM-Labels: nil
X-VM-VHeader: ("Resent-" "From:" "Sender:" "To:" "Apparently-To:" "Cc:" "Subject:" "Date:") nil
X-VM-Last-Modified: (14350 6000 509440)
X-VM-IMAP-Retrieved: nil
X-VM-POP-Retrieved: nil
X-VM-Bookmark: 2
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["3449" "Wed" "6" "October" "1999" "16:56:40" "-0800" "akin@pobox.com" "akin@pobox.com" nil "76" "Re: The return of PolygonOffset " "^From:" nil nil "10" nil nil nil nil nil]
	nil)
Received: from usagi.cts.com (usagi.cts.com [209.68.192.66])
	by mail.me.umn.edu (8.9.3/8.9.3) with ESMTP id TAA99721
	for <curt@me.umn.edu>; Wed, 6 Oct 1999 19:10:12 -0500 (CDT)
	(envelope-from fatcity!root@news.cts.com)
Received: from king.cts.com (root@king.cts.com [198.68.168.21])
	by usagi.cts.com (8.9.3/8.9.3) with ESMTP id RAA18353;
	Wed, 6 Oct 1999 17:09:21 -0700 (PDT)
Received: from donews.cts.com (donews.cts.com [192.188.72.21])
	by king.cts.com (8.8.7/8.8.7) with SMTP id RAA01848;
	Wed, 6 Oct 1999 17:09:19 -0700 (PDT)
Received: from fatcity by donews.cts.com with uucp
	(Smail3.1.29.1 #5) id m11Z17S-000084a; Wed, 6 Oct 99 17:09 PDT
Received: by fatcity.com (21-May-1998/v1.0f-b66/bab) via UUCP id 000B2E6B; Wed, 06 Oct 1999 16:56:40 -0800
Message-ID: <F001.000B2E6B.19991006165640@fatcity.com>
X-Comment: OpenGL Game Developers Mailing List
X-Sender: akin@pobox.com
Reply-To: OPENGL-GAMEDEV-L@fatcity.com
Errors-To: ML-ERRORS@fatcity.com
Organization: Fat City Network Services, San Diego, California
X-ListServer: v1.0f, build 66; ListGuru (c) 1996-1999 Bruce A. Bergman
Precedence: bulk
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
From: akin@pobox.com
Sender: root@fatcity.com
To: Multiple recipients of list OPENGL-GAMEDEV-L <OPENGL-GAMEDEV-L@fatcity.com>
Subject: Re: The return of PolygonOffset 
Date: Wed, 06 Oct 1999 16:56:40 -0800


| The numbers passed to this function have completely different effects on
| different cards. ...

That figures.  Even Michael Gold tells me that it isn't obvious how to
implement polygon offset.

|               ...The way I read the documentation, the parameters should be
| a factor of -1 and units of -1 per pass (i.e. -1 for 2nd pass, -2 for third
| pass). Also, if the previous pass doesn't write to the z-buffer then you
| don't have to up the units value.

Depends on exactly what you're doing.  Here's a brief summary I posted
long ago; it's sort of terse, but easier to understand if you draw
pictures on graph paper:


	The ``factor'' argument for glPolygonOffset() controls Z
	separation between objects with different Z slopes, and its
	value is related to the X and Y sizes of the objects involved. 
	For example, when drawing an edge line of width 1 on top of a
	polygon, the pixels sampled for the line may be (almost) as
	far as one pixel width away from the true edge of the polygon. 
	Thus, to guarantee that the line and the polygon never
	intersect, you need to offset the line from the polygon by at
	least 1*max(abs(dz/dx),abs(dz/dy)).  If you were drawing a
	wider line, then the ``1'' factor would need to be larger. 
	(The minimum possible value depends on the rasterization
	algorithm; I usually just use the line width, but something
	like ceil(width/2.0) would probaby work on most systems.)

	The ``bias'' argument controls Z separation between objects
	with the same Z slope, and its value is related to the number
	of layers of such objects.  (Note:  The units of the bias
	argument differ between the OpenGL 1.0 extension and OpenGL
	1.1; I'll just talk about OpenGL 1.1.) Again, suppose you're
	drawing edge lines on polygons.  If the polygon has the same Z
	everywhere, then 1*max(abs(dz/dx),abs(dz/dy)) is zero; you
	don't get any separation between the lines and the polygon,
	and so depth-buffering artifacts may occur.  By using a bias
	of 1.0, you guarantee that there's enough distance between the
	lines and the polygon to avoid artifacts.  As another
	application, if you want to draw a bunch of polygons stacked
	one on top of the other, then you might use a bias of 0.0 for
	the base polygon, 1.0 for the first one in the stack, 2.0 for
	the next one, and so on.  (Note that they can be drawn in any
	order, since the polygon offset ensures that they will be
	properly separated in Z.)
 
	That's why the common case of drawing 1-pixel-wide edge lines
	on polygons uses a factor of 1.0 (to account for Z slope
	differences between the line and the polygon) and a bias of
	1.0 (to cover the case in which the polygon has Z slope of
	zero). 

Somewhere I've seen a better explanation, but it escapes me at the
moment.

Allen
----- 
FAQ and OpenGL Resources at:
  http://www.geocities.com/SiliconValley/Hills/9956/OpenGL

-- 
Author: 
  INET: akin@pobox.com

Fat City Network Services    -- (619) 538-5051  FAX: (619) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

From fatcity!root@news.cts.com  Thu Oct  7 08:30:05 1999
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["4104" "Thu" "7" "October" "1999" "06:17:31" "-0800" "Stephen J Baker" "sjbaker@hti.com" nil "89" "Re: The return of PolygonOffset" "^From:" nil nil "10" nil nil nil nil nil]
	nil)
Received: from usagi.cts.com (usagi.cts.com [209.68.192.66])
	by mail.me.umn.edu (8.9.3/8.9.3) with ESMTP id IAA28629
	for <curt@me.umn.edu>; Thu, 7 Oct 1999 08:30:04 -0500 (CDT)
	(envelope-from fatcity!root@news.cts.com)
Received: from king.cts.com (root@king.cts.com [198.68.168.21])
	by usagi.cts.com (8.9.3/8.9.3) with ESMTP id GAA00975;
	Thu, 7 Oct 1999 06:25:28 -0700 (PDT)
Received: from donews.cts.com (donews.cts.com [192.188.72.21])
	by king.cts.com (8.8.7/8.8.7) with SMTP id GAA19410;
	Thu, 7 Oct 1999 06:25:26 -0700 (PDT)
Received: from fatcity by donews.cts.com with uucp
	(Smail3.1.29.1 #5) id m11ZDXu-00000Ca; Thu, 7 Oct 99 06:25 PDT
Received: by fatcity.com (21-May-1998/v1.0f-b66/bab) via UUCP id 000B3175; Thu, 07 Oct 1999 06:17:31 -0800
Message-ID: <F001.000B3175.19991007061731@fatcity.com>
X-Comment: OpenGL Game Developers Mailing List
X-Sender: "Stephen J Baker" <sjbaker@hti.com>
Reply-To: OPENGL-GAMEDEV-L@fatcity.com
Errors-To: ML-ERRORS@fatcity.com
Organization: Fat City Network Services, San Diego, California
X-ListServer: v1.0f, build 66; ListGuru (c) 1996-1999 Bruce A. Bergman
Precedence: bulk
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Transfer-Encoding: 7bit
From: "Stephen J Baker" <sjbaker@hti.com>
Sender: root@fatcity.com
To: Multiple recipients of list OPENGL-GAMEDEV-L <OPENGL-GAMEDEV-L@fatcity.com>
Subject: Re: The return of PolygonOffset
Date: Thu, 07 Oct 1999 06:17:31 -0800

On Wed, 6 Oct 1999, Neal Tringham wrote:

> <JScott@ravensoft.com> writes
> >The numbers passed to this function have completely different effects on
> >different cards. The way I read the documentation, the parameters should be
> >a factor of -1 and units of -1 per pass (i.e. -1 for 2nd pass, -2 for third
> >pass). Also, if the previous pass doesn't write to the z-buffer then you
> >don't have to up the units value.
> >
> >However, this doesn't seem to work. I deduce from this that I am talking
> >complete bollocks :) If anyone can educate me on this, I would be very
> >appreciative.
> 
> I went to the Mesa source for glPolygonOffset and based my code on my
> reading of that, to be honest:-)  Although even then, the Mesa code
> (which I believe is based on the published spec) seems to behave
> somewhat differently to some card driver implementations.  I would also
> be interested in any comments people might have on this issue:-)

I have found that glPolygonOffset is very patchily implemented. Some
card/drivers silently do nothing - and even on those for which it does
work, the amount of offset has to be determined experimentally.

As a way of layering geometry, it sucks anyway since the amount of
actual Z offset has to depend on the slope of the polygon - that
means that as a polygon goes edge-on, the amount of Z offset
gets very large. Far distant objects with an offset start to poke
through nearer objects.

Uck!

IMHO, OpenGL should have been designed with a more robust scheme such
as one I used on an ancient image generator where you can tell the
rasterizer to use the plane equation of one polygon to compute the Z
values of another.  This approach is used by setting the "current
plane equation" to be that of the 'base' polygon and then rendering
the 'base' and 'daughter' polygons in "painter's algorithm" order.
This ensures absolutely that the Z of the parent and daughter polygons
will match *exactly* at every screen pixel - and a pass-if-equal Z test
can be used to render the layers using painters algorithm. (In the system
I designed, we reserved a few bits at the low end of the Z buffer as
'layer number' so that you could render the base and layer polygons in
any order if you tagged them with a later number parameter - but that's
not essential to making this work).

SGI have an extension for doing this kind of thing on their high end
machines.

The problem is now that many cards will be unable to implement
this because their hardware simply doesn't work that way.

The present implementation of glPolygonOffset is reasonably
good when you are doing multipass rendering because you are
sending the same geometry down the pipe twice in a row and
most reasonable implementations are going to generate exact
Z values anyway. But if the 'daughter' polygons don't have
the same vertices as the 'base', the whole thing becomes
something of a lottery.

This is one area where the OpenGL spec has been flawed from
day one. glPolygonOffset is just a band-aid applied in
OGL 1.1.

There are some other devious ways to do reasonable coplanar
rendering using stencil planes - but since those are not
well supported on the PC either, that isn't much comfort.

Steve Baker                (817)619-2657 (Vox/Vox-Mail)
Raytheon Systems Inc.      (817)619-2466 (Fax)
Work: sjbaker@hti.com      http://www.hti.com
Home: sjbaker1@airmail.net http://web2.airmail.net/sjbaker1

----- 
FAQ and OpenGL Resources at:
  http://www.geocities.com/SiliconValley/Hills/9956/OpenGL

-- 
Author: Stephen J Baker
  INET: sjbaker@hti.com

Fat City Network Services    -- (619) 538-5051  FAX: (619) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

From fatcity!root@news.cts.com  Thu Oct  7 12:27:26 1999
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["2693" "Thu" "7" "October" "1999" "10:12:29" "-0800" "Stephen J Baker" "sjbaker@hti.com" nil "63" "Re: The return of PolygonOffset" "^From:" nil nil "10" nil nil nil nil nil]
	nil)
Received: from usagi.cts.com (usagi.cts.com [209.68.192.66])
	by mail.me.umn.edu (8.9.3/8.9.3) with ESMTP id MAA39958
	for <curt@me.umn.edu>; Thu, 7 Oct 1999 12:27:26 -0500 (CDT)
	(envelope-from fatcity!root@news.cts.com)
Received: from king.cts.com (root@king.cts.com [198.68.168.21])
	by usagi.cts.com (8.9.3/8.9.3) with ESMTP id KAA15931;
	Thu, 7 Oct 1999 10:24:12 -0700 (PDT)
Received: from donews.cts.com (donews.cts.com [192.188.72.21])
	by king.cts.com (8.8.7/8.8.7) with SMTP id KAA15017;
	Thu, 7 Oct 1999 10:24:11 -0700 (PDT)
Received: from fatcity by donews.cts.com with uucp
	(Smail3.1.29.1 #5) id m11ZHGz-00007ma; Thu, 7 Oct 99 10:24 PDT
Received: by fatcity.com (21-May-1998/v1.0f-b66/bab) via UUCP id 000B34EC; Thu, 07 Oct 1999 10:12:29 -0800
Message-ID: <F001.000B34EC.19991007101229@fatcity.com>
X-Comment: OpenGL Game Developers Mailing List
X-Sender: "Stephen J Baker" <sjbaker@hti.com>
Reply-To: OPENGL-GAMEDEV-L@fatcity.com
Errors-To: ML-ERRORS@fatcity.com
Organization: Fat City Network Services, San Diego, California
X-ListServer: v1.0f, build 66; ListGuru (c) 1996-1999 Bruce A. Bergman
Precedence: bulk
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Transfer-Encoding: 7bit
From: "Stephen J Baker" <sjbaker@hti.com>
Sender: root@fatcity.com
To: Multiple recipients of list OPENGL-GAMEDEV-L <OPENGL-GAMEDEV-L@fatcity.com>
Subject: Re: The return of PolygonOffset
Date: Thu, 07 Oct 1999 10:12:29 -0800

On Thu, 7 Oct 1999, Gil Gribb wrote:

> > The present implementation of glPolygonOffset is reasonably
> > good when you are doing multipass rendering because you are
> > sending the same geometry down the pipe twice in a row and
> > most reasonable implementations are going to generate exact
> > Z values anyway. But if the 'daughter' polygons don't have
> > the same vertices as the 'base', the whole thing becomes
> > something of a lottery.
> >
> 
> It used to be the case that sending identical geometric data produced
> identical z values on all consumer hardware.

But OpenGL never guaranteed that - so you should always have been
using glPolygonOffset.  In one of the RedBook appendices, it tells
you under what circumstances you are allowed to assume that.

> But for some reason we find we
> have to use polygonoffset in many situations that we didn't used to have to.
> What really sucks is that different gl implementations are using radically
> different formulas for polygon offset.

Well, that's not entirely the problem - different OpenGL implementations
NEED to use different offset calculations. The issue is that the amount
of offset that you need varies from one OpenGL implementation to another,
depending on:

1) The number of bits of Z in the Z buffer hardware.
2) The relationship between Z and the number being written to the
   physical Z memory (some machines compress Z - eg SGI workstations)
3) The degree of accuracy in the Z interpolator in the rasterizer
   hardware.
4) The degree of accuracy in the Z interpolator in any fallback
   software rasterizer.
5) The amount of inconsistancy between hardware and software
   fallback Z-interpolation algorithms.

That's what makes glPolygonOffset so sucky. Just the entire
concept of it is broken-by-design.

Steve Baker                (817)619-2657 (Vox/Vox-Mail)
Raytheon Systems Inc.      (817)619-2466 (Fax)
Work: sjbaker@hti.com      http://www.hti.com
Home: sjbaker1@airmail.net http://web2.airmail.net/sjbaker1

----- 
FAQ and OpenGL Resources at:
  http://www.geocities.com/SiliconValley/Hills/9956/OpenGL

-- 
Author: Stephen J Baker
  INET: sjbaker@hti.com

Fat City Network Services    -- (619) 538-5051  FAX: (619) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

From fatcity!root@news.cts.com  Thu Oct  7 14:27:35 1999
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["1696" "Thu" "7" "October" "1999" "12:15:50" "-0800" "Gil Gribb" "ggribb@mail.ravensoft.com" nil "39" "Re: The return of PolygonOffset " "^From:" nil nil "10" nil nil nil nil nil]
	nil)
Received: from usagi.cts.com (usagi.cts.com [209.68.192.66])
	by mail.me.umn.edu (8.9.3/8.9.3) with ESMTP id OAA47594
	for <curt@me.umn.edu>; Thu, 7 Oct 1999 14:27:35 -0500 (CDT)
	(envelope-from fatcity!root@news.cts.com)
Received: from king.cts.com (root@king.cts.com [198.68.168.21])
	by usagi.cts.com (8.9.3/8.9.3) with ESMTP id MAA27111;
	Thu, 7 Oct 1999 12:25:19 -0700 (PDT)
Received: from donews.cts.com (donews.cts.com [192.188.72.21])
	by king.cts.com (8.8.7/8.8.7) with SMTP id MAA18282;
	Thu, 7 Oct 1999 12:25:17 -0700 (PDT)
Received: from fatcity by donews.cts.com with uucp
	(Smail3.1.29.1 #5) id m11ZJ9L-00007Fa; Thu, 7 Oct 99 12:24 PDT
Received: by fatcity.com (21-May-1998/v1.0f-b66/bab) via UUCP id 000B37B6; Thu, 07 Oct 1999 12:15:50 -0800
Message-ID: <F001.000B37B6.19991007121550@fatcity.com>
X-Comment: OpenGL Game Developers Mailing List
X-Sender: "Gil Gribb" <ggribb@mail.ravensoft.com>
Reply-To: OPENGL-GAMEDEV-L@fatcity.com
Errors-To: ML-ERRORS@fatcity.com
Organization: Fat City Network Services, San Diego, California
X-ListServer: v1.0f, build 66; ListGuru (c) 1996-1999 Bruce A. Bergman
Precedence: bulk
Mime-Version: 1.0
Content-Type: text/plain;	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
From: "Gil Gribb" <ggribb@mail.ravensoft.com>
Sender: root@fatcity.com
To: Multiple recipients of list OPENGL-GAMEDEV-L <OPENGL-GAMEDEV-L@fatcity.com>
Subject: Re: The return of PolygonOffset 
Date: Thu, 07 Oct 1999 12:15:50 -0800

> PolygonOffset is just a performance hack.  If you want good quality
> edges and decaling, you can do it with stencils.  (Draw the base
> polygon, setting the stencil bit when the Z test passes and clearing
> it otherwise; then enable stencil test, disable depth test, and draw
> the edges or decals.) This is just one of many reasons why hardware
> developers should support stencil planes.  Fortunately most
> current-generation chips seem to do so.

Questionable. For the stencil technique to work, you have to switch
renderstates every triangle. This is very bad. In order to submit big
batches of triangles efficiently, you need to send first the whole mesh for
pass one, then the whole mesh for pass two. It should be obvious that both
passes need to be z-buffered. When batched this way, the stencil approach
cannot render self-overlapping geometry with decals properly; polygonoffset
can.

I claim for multipass techniques, I shouldn't even have to use
polygonoffset, but I do.
-Gil



----- 
FAQ and OpenGL Resources at:
  http://www.geocities.com/SiliconValley/Hills/9956/OpenGL

-- 
Author: Gil Gribb
  INET: ggribb@mail.ravensoft.com

Fat City Network Services    -- (619) 538-5051  FAX: (619) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

From fatcity!root@news.cts.com  Thu Oct  7 14:36:48 1999
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["2376" "Thu" "7" "October" "1999" "10:59:27" "-0800" "Neal Tringham" "neal@pseudonymz.demon.co.uk" nil "55" "Re: The return of PolygonOffset" "^From:" nil nil "10" nil nil nil nil nil]
	nil)
Received: from usagi.cts.com (usagi.cts.com [209.68.192.66])
	by mail.me.umn.edu (8.9.3/8.9.3) with ESMTP id OAA49017
	for <curt@me.umn.edu>; Thu, 7 Oct 1999 14:36:47 -0500 (CDT)
	(envelope-from fatcity!root@news.cts.com)
Received: from king.cts.com (root@king.cts.com [198.68.168.21])
	by usagi.cts.com (8.9.3/8.9.3) with ESMTP id LAA03743;
	Thu, 7 Oct 1999 11:16:21 -0700 (PDT)
Received: from donews.cts.com (donews.cts.com [192.188.72.21])
	by king.cts.com (8.8.7/8.8.7) with SMTP id LAA29541;
	Thu, 7 Oct 1999 11:16:19 -0700 (PDT)
Received: from fatcity by donews.cts.com with uucp
	(Smail3.1.29.1 #5) id m11ZI4g-00003Pa; Thu, 7 Oct 99 11:15 PDT
Received: by fatcity.com (21-May-1998/v1.0f-b66/bab) via UUCP id 000B35DB; Thu, 07 Oct 1999 10:59:27 -0800
Message-ID: <F001.000B35DB.19991007105927@fatcity.com>
X-Comment: OpenGL Game Developers Mailing List
X-Sender: "Neal Tringham" <neal@pseudonymz.demon.co.uk>
Reply-To: OPENGL-GAMEDEV-L@fatcity.com
Errors-To: ML-ERRORS@fatcity.com
Organization: Fat City Network Services, San Diego, California
X-ListServer: v1.0f, build 66; ListGuru (c) 1996-1999 Bruce A. Bergman
Precedence: bulk
Mime-Version: 1.0
Content-Type: text/plain;	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
From: "Neal Tringham" <neal@pseudonymz.demon.co.uk>
Sender: root@fatcity.com
To: Multiple recipients of list OPENGL-GAMEDEV-L <OPENGL-GAMEDEV-L@fatcity.com>
Subject: Re: The return of PolygonOffset
Date: Thu, 07 Oct 1999 10:59:27 -0800

Stephen J Baker <sjbaker@hti.com> writes:
>I have found that glPolygonOffset is very patchily implemented. Some
>card/drivers silently do nothing - and even on those for which it does
>work, the amount of offset has to be determined experimentally.

In your experience, what are the cards/drivers on which it silently does
nothing?  Does it include the current ATI Rage Pro drivers, by any chance?
(or are the values required for the Rage Pro quite different to all the
others?:-))

>The present implementation of glPolygonOffset is reasonably
>good when you are doing multipass rendering because you are
>sending the same geometry down the pipe twice in a row and
>most reasonable implementations are going to generate exact
>Z values anyway. But if the 'daughter' polygons don't have
>the same vertices as the 'base', the whole thing becomes
>something of a lottery.

Yes - I use it for volumetric shadows, since we can't be confident about
having hardware stencil buffer support.  For this application it seems to be
usable (since the shadows are basically in the same plane as the recipient
polygons, although they're not exactly the same vertices).

>
>This is one area where the OpenGL spec has been flawed from
>day one. glPolygonOffset is just a band-aid applied in
>OGL 1.1.

Yes.  I personally find the way different cards do different things with the
same input values rather disconcerting, and not the sort of thing I would
have expected from OpenGL (and, to be fair, not the sort of thing I get from
OpenGL for just about every other thing I do with it).

                        Neal Tringham (VX)
                        (neal@pseudonymz.demon.co.uk)



----- 
FAQ and OpenGL Resources at:
  http://www.geocities.com/SiliconValley/Hills/9956/OpenGL

-- 
Author: Neal Tringham
  INET: neal@pseudonymz.demon.co.uk

Fat City Network Services    -- (619) 538-5051  FAX: (619) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

From fatcity!root@news.cts.com  Thu Oct  7 15:39:05 1999
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["2993" "Thu" "7" "October" "1999" "13:15:41" "-0800" "Stephen J Baker" "sjbaker@hti.com" nil "65" "Re: The return of PolygonOffset " "^From:" nil nil "10" nil nil nil nil nil]
	nil)
Received: from usagi.cts.com (usagi.cts.com [209.68.192.66])
	by mail.me.umn.edu (8.9.3/8.9.3) with ESMTP id PAA56596
	for <curt@me.umn.edu>; Thu, 7 Oct 1999 15:39:05 -0500 (CDT)
	(envelope-from fatcity!root@news.cts.com)
Received: from king.cts.com (root@king.cts.com [198.68.168.21])
	by usagi.cts.com (8.9.3/8.9.3) with ESMTP id NAA16970;
	Thu, 7 Oct 1999 13:36:53 -0700 (PDT)
Received: from donews.cts.com (donews.cts.com [192.188.72.21])
	by king.cts.com (8.8.7/8.8.7) with SMTP id NAA05344;
	Thu, 7 Oct 1999 13:36:51 -0700 (PDT)
Received: from fatcity by donews.cts.com with uucp
	(Smail3.1.29.1 #5) id m11ZK9R-00005da; Thu, 7 Oct 99 13:28 PDT
Received: by fatcity.com (21-May-1998/v1.0f-b66/bab) via UUCP id 000B3815; Thu, 07 Oct 1999 13:15:41 -0800
Message-ID: <F001.000B3815.19991007131541@fatcity.com>
X-Comment: OpenGL Game Developers Mailing List
X-Sender: "Stephen J Baker" <sjbaker@hti.com>
Reply-To: OPENGL-GAMEDEV-L@fatcity.com
Errors-To: ML-ERRORS@fatcity.com
Organization: Fat City Network Services, San Diego, California
X-ListServer: v1.0f, build 66; ListGuru (c) 1996-1999 Bruce A. Bergman
Precedence: bulk
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Transfer-Encoding: 7bit
From: "Stephen J Baker" <sjbaker@hti.com>
Sender: root@fatcity.com
To: Multiple recipients of list OPENGL-GAMEDEV-L <OPENGL-GAMEDEV-L@fatcity.com>
Subject: Re: The return of PolygonOffset 
Date: Thu, 07 Oct 1999 13:15:41 -0800

On Thu, 7 Oct 1999, Gil Gribb wrote:

> > PolygonOffset is just a performance hack.  If you want good quality
> > edges and decaling, you can do it with stencils.  (Draw the base
> > polygon, setting the stencil bit when the Z test passes and clearing
> > it otherwise; then enable stencil test, disable depth test, and draw
> > the edges or decals.) This is just one of many reasons why hardware
> > developers should support stencil planes.  Fortunately most
> > current-generation chips seem to do so.
> 
> Questionable. For the stencil technique to work, you have to switch
> renderstates every triangle. This is very bad. In order to submit big
> batches of triangles efficiently, you need to send first the whole mesh for
> pass one, then the whole mesh for pass two. It should be obvious that both
> passes need to be z-buffered. When batched this way, the stencil approach
> cannot render self-overlapping geometry with decals properly; polygonoffset
> can.

Yes - I agree - the Stencil algorithm isn't fast and it certainly
causes no end of problems with the limitation of no part of the
daughter geometry being allowed to hang off the edge of the parent.

> I claim for multipass techniques, I shouldn't even have to use
> polygonoffset, but I do.

Yes - it seems a great shame that OpenGL doesn't guarantee that
behaviour.  However, in a world where software fallbacks could
potentially be needed, it would have been unwise for the OpenGL
spec to promise perfect Z correlation. (Always remember -
OpenGL pre-dates hardware 3D on PC's and not all OpenGL
applications are games - so software fallbacks were [past tense]
very important to the spec.)

You *could* write software fallbacks to accurately emulate the
rasterization algorithms of the hardware (eg deliberately
throwing away precision)...but they would be *MUCH* slower
than optimised software.

I can't think of any good reasons why OpenGL shouldn't require
repeatable Z calculations otherwise though....hmmm - maybe
switching polygon smoothing off and on would change Z roundoff
errors...nothing important though.

Steve Baker                (817)619-2657 (Vox/Vox-Mail)
Raytheon Systems Inc.      (817)619-2466 (Fax)
Work: sjbaker@hti.com      http://www.hti.com
Home: sjbaker1@airmail.net http://web2.airmail.net/sjbaker1

----- 
FAQ and OpenGL Resources at:
  http://www.geocities.com/SiliconValley/Hills/9956/OpenGL

-- 
Author: Stephen J Baker
  INET: sjbaker@hti.com

Fat City Network Services    -- (619) 538-5051  FAX: (619) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

From fatcity!root@news.cts.com  Thu Oct  7 16:12:43 1999
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["2583" "Thu" "7" "October" "1999" "13:56:43" "-0800" "akin@pobox.com" "akin@pobox.com" nil "61" "Re: The return of PolygonOffset " "^From:" nil nil "10" nil nil nil nil nil]
	nil)
Received: from usagi.cts.com (usagi.cts.com [209.68.192.66])
	by mail.me.umn.edu (8.9.3/8.9.3) with ESMTP id QAA58035
	for <curt@me.umn.edu>; Thu, 7 Oct 1999 16:12:43 -0500 (CDT)
	(envelope-from fatcity!root@news.cts.com)
Received: from king.cts.com (root@king.cts.com [198.68.168.21])
	by usagi.cts.com (8.9.3/8.9.3) with ESMTP id OAA27709;
	Thu, 7 Oct 1999 14:10:14 -0700 (PDT)
Received: from donews.cts.com (donews.cts.com [192.188.72.21])
	by king.cts.com (8.8.7/8.8.7) with SMTP id OAA13730;
	Thu, 7 Oct 1999 14:10:11 -0700 (PDT)
Received: from fatcity by donews.cts.com with uucp
	(Smail3.1.29.1 #5) id m11ZKn8-00007na; Thu, 7 Oct 99 14:09 PDT
Received: by fatcity.com (21-May-1998/v1.0f-b66/bab) via UUCP id 000B3871; Thu, 07 Oct 1999 13:56:43 -0800
Message-ID: <F001.000B3871.19991007135643@fatcity.com>
X-Comment: OpenGL Game Developers Mailing List
X-Sender: akin@pobox.com
Reply-To: OPENGL-GAMEDEV-L@fatcity.com
Errors-To: ML-ERRORS@fatcity.com
Organization: Fat City Network Services, San Diego, California
X-ListServer: v1.0f, build 66; ListGuru (c) 1996-1999 Bruce A. Bergman
Precedence: bulk
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
From: akin@pobox.com
Sender: root@fatcity.com
To: Multiple recipients of list OPENGL-GAMEDEV-L <OPENGL-GAMEDEV-L@fatcity.com>
Subject: Re: The return of PolygonOffset 
Date: Thu, 07 Oct 1999 13:56:43 -0800


| > PolygonOffset is just a performance hack.  If you want good quality
| > edges and decaling, you can do it with stencils.  (Draw the base
| > polygon, setting the stencil bit when the Z test passes and clearing
| > it otherwise; then enable stencil test, disable depth test, and draw
| > the edges or decals.) This is just one of many reasons why hardware
| > developers should support stencil planes.  Fortunately most
| > current-generation chips seem to do so.
| 
| Questionable. For the stencil technique to work, you have to switch
| renderstates every triangle. This is very bad. ...

It's a user-controlled quality/performance tradeoff.  If you want
super quality, use stencils; if you want speed and can tolerate the
occasional glitch, use polygon offset.  That doesn't seem necessarily
bad to me.

| I claim for multipass techniques, I shouldn't even have to use
| polygonoffset, but I do.

In practice, there's almost no way to guarantee Z equality on separate
passes if the rendering state changes in any nontrivial way.  The
``invariance'' appendix in the OpenGL spec goes into this at some
length.

As Steve mentioned, the reference-plane technique can solve this
problem, but I gather that consumer-level hardware developers haven't
progressed to that level yet.  Perhaps some of them will, after
reading this discussion.

As for polygon offset, I hear that implementations are not consistent,
even though there's no technical reason (that I know of) for that to
be true.  So it sounds like we should put some bug-fix pressure on the
IHVs that are in error.  I'll add a polygon offset test to the next
release of glean.

For those who are interested in the edges-on-polygons problem in
particular, Paul Heckbert wrote a summary of implementation
techniques.  Check

	http://www-cgi.cs.cmu.edu/afs/cs.cmu.edu/user/ph/www/heckbert.html#papers
in the section titled ``Software.''

Allen
----- 
FAQ and OpenGL Resources at:
  http://www.geocities.com/SiliconValley/Hills/9956/OpenGL

-- 
Author: 
  INET: akin@pobox.com

Fat City Network Services    -- (619) 538-5051  FAX: (619) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

From fatcity!root@news.cts.com  Thu Oct  7 17:11:02 1999
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["1364" "Thu" "7" "October" "1999" "14:58:20" "-0800" "akin@pobox.com" "akin@pobox.com" nil "33" "Re: The return of PolygonOffset " "^From:" nil nil "10" nil nil nil nil nil]
	nil)
Received: from usagi.cts.com (usagi.cts.com [209.68.192.66])
	by mail.me.umn.edu (8.9.3/8.9.3) with ESMTP id RAA61240
	for <curt@me.umn.edu>; Thu, 7 Oct 1999 17:11:02 -0500 (CDT)
	(envelope-from fatcity!root@news.cts.com)
Received: from king.cts.com (root@king.cts.com [198.68.168.21])
	by usagi.cts.com (8.9.3/8.9.3) with ESMTP id PAA16878;
	Thu, 7 Oct 1999 15:09:23 -0700 (PDT)
Received: from donews.cts.com (donews.cts.com [192.188.72.21])
	by king.cts.com (8.8.7/8.8.7) with SMTP id PAA29239;
	Thu, 7 Oct 1999 15:09:21 -0700 (PDT)
Received: from fatcity by donews.cts.com with uucp
	(Smail3.1.29.1 #5) id m11ZLis-000045a; Thu, 7 Oct 99 15:09 PDT
Received: by fatcity.com (21-May-1998/v1.0f-b66/bab) via UUCP id 000B392D; Thu, 07 Oct 1999 14:58:20 -0800
Message-ID: <F001.000B392D.19991007145820@fatcity.com>
X-Comment: OpenGL Game Developers Mailing List
X-Sender: akin@pobox.com
Reply-To: OPENGL-GAMEDEV-L@fatcity.com
Errors-To: ML-ERRORS@fatcity.com
Organization: Fat City Network Services, San Diego, California
X-ListServer: v1.0f, build 66; ListGuru (c) 1996-1999 Bruce A. Bergman
Precedence: bulk
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
From: akin@pobox.com
Sender: root@fatcity.com
To: Multiple recipients of list OPENGL-GAMEDEV-L <OPENGL-GAMEDEV-L@fatcity.com>
Subject: Re: The return of PolygonOffset 
Date: Thu, 07 Oct 1999 14:58:20 -0800


| I can't think of any good reasons why OpenGL shouldn't require
| repeatable Z calculations otherwise though....

The big problem is compilation.  Even if you always use the same piece
of source code to implement a given function, optimizing compilers
will turn that source code into different object code depending on the
context in which it's compiled.  (Similar effects occur when
synthesizing gates from hardware design languages.) The differences in
object code lead to differences in floating-point error, roundoff,
etc. for rendering in different states.

This phenomenon has been observed in practice, and is one of the
reasons for including appendix A in the spec.

Allen
----- 
FAQ and OpenGL Resources at:
  http://www.geocities.com/SiliconValley/Hills/9956/OpenGL

-- 
Author: 
  INET: akin@pobox.com

Fat City Network Services    -- (619) 538-5051  FAX: (619) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

From fatcity!root@news.cts.com  Thu Oct  7 19:09:32 1999
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["2335" "Thu" "7" "October" "1999" "16:57:15" "-0800" "Gil Gribb" "ggribb@mail.ravensoft.com" nil "61" "Re: The return of PolygonOffset " "^From:" nil nil "10" nil nil nil nil nil]
	nil)
Received: from usagi.cts.com (usagi.cts.com [209.68.192.66])
	by mail.me.umn.edu (8.9.3/8.9.3) with ESMTP id TAA66539
	for <curt@me.umn.edu>; Thu, 7 Oct 1999 19:09:32 -0500 (CDT)
	(envelope-from fatcity!root@news.cts.com)
Received: from king.cts.com (root@king.cts.com [198.68.168.21])
	by usagi.cts.com (8.9.3/8.9.3) with ESMTP id RAA22146;
	Thu, 7 Oct 1999 17:08:38 -0700 (PDT)
Received: from donews.cts.com (donews.cts.com [192.188.72.21])
	by king.cts.com (8.8.7/8.8.7) with SMTP id RAA27649;
	Thu, 7 Oct 1999 17:08:36 -0700 (PDT)
Received: from fatcity by donews.cts.com with uucp
	(Smail3.1.29.1 #5) id m11ZNaN-00007Da; Thu, 7 Oct 99 17:08 PDT
Received: by fatcity.com (21-May-1998/v1.0f-b66/bab) via UUCP id 000B39CE; Thu, 07 Oct 1999 16:57:15 -0800
Message-ID: <F001.000B39CE.19991007165715@fatcity.com>
X-Comment: OpenGL Game Developers Mailing List
X-Sender: "Gil Gribb" <ggribb@mail.ravensoft.com>
Reply-To: OPENGL-GAMEDEV-L@fatcity.com
Errors-To: ML-ERRORS@fatcity.com
Organization: Fat City Network Services, San Diego, California
X-ListServer: v1.0f, build 66; ListGuru (c) 1996-1999 Bruce A. Bergman
Precedence: bulk
Mime-Version: 1.0
Content-Type: text/plain;	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
From: "Gil Gribb" <ggribb@mail.ravensoft.com>
Sender: root@fatcity.com
To: Multiple recipients of list OPENGL-GAMEDEV-L <OPENGL-GAMEDEV-L@fatcity.com>
Subject: Re: The return of PolygonOffset 
Date: Thu, 07 Oct 1999 16:57:15 -0800

> | I can't think of any good reasons why OpenGL shouldn't require
> | repeatable Z calculations otherwise though....
>
> The big problem is compilation.  Even if you always use the same piece
> of source code to implement a given function, optimizing compilers
> will turn that source code into different object code depending on the
> context in which it's compiled.  (Similar effects occur when
> synthesizing gates from hardware design languages.) The differences in
> object code lead to differences in floating-point error, roundoff,
> etc. for rendering in different states.
>
> This phenomenon has been observed in practice, and is one of the
> reasons for including appendix A in the spec.

Fair enough, I'll buy that. But if this is the case, you can't even
guarantee that the second pass even hits the same pixels! So your proposed
stencil approach won't work perfectly either. I guess the solution is to
just get everybody on the same page with polygonoffset.

I guess we need a decision procedure. Given:

*Near and far clip planes
*FOV
*Bits in z buffer

And assuming vanilla consumer hardware.  What is the recommended polygon
offset for two common senerios?

a) Multipass; draw each polygon twice. The second pass is identical in all
aspects that reasonably related to the z buffer.
b) Sub-polygon decal; draw smaller polygons on top of big polygons. The
second pass is intended to be planar to first pass, but since vertices are
not identical to the first pass error is expected.

If the reccomendation is application dependent, what would be the criteria
for choosing good parameters for polygon offset?

-Gil







----- 
FAQ and OpenGL Resources at:
  http://www.geocities.com/SiliconValley/Hills/9956/OpenGL

-- 
Author: Gil Gribb
  INET: ggribb@mail.ravensoft.com

Fat City Network Services    -- (619) 538-5051  FAX: (619) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

From fatcity!root@news.cts.com  Fri Oct  8 09:38:59 1999
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["3117" "Fri" "8" "October" "1999" "07:00:27" "-0800" "Gil Gribb" "ggribb@mail.ravensoft.com" nil "83" "Re: The return of PolygonOffset" "^From:" nil nil "10" nil nil nil nil nil]
	nil)
Received: from usagi.cts.com (usagi.cts.com [209.68.192.66])
	by mail.me.umn.edu (8.9.3/8.9.3) with ESMTP id JAA98612
	for <curt@me.umn.edu>; Fri, 8 Oct 1999 09:38:59 -0500 (CDT)
	(envelope-from fatcity!root@news.cts.com)
Received: from king.cts.com (root@king.cts.com [198.68.168.21])
	by usagi.cts.com (8.9.3/8.9.3) with ESMTP id HAA16524;
	Fri, 8 Oct 1999 07:35:48 -0700 (PDT)
Received: from donews.cts.com (donews.cts.com [192.188.72.21])
	by king.cts.com (8.8.7/8.8.7) with SMTP id HAA22152;
	Fri, 8 Oct 1999 07:35:48 -0700 (PDT)
Received: from fatcity by donews.cts.com with uucp
	(Smail3.1.29.1 #5) id m11ZaiR-000046a; Fri, 8 Oct 99 07:09 PDT
Received: by fatcity.com (21-May-1998/v1.0f-b66/bab) via UUCP id 000B3CAA; Fri, 08 Oct 1999 07:00:27 -0800
Message-ID: <F001.000B3CAA.19991008070027@fatcity.com>
X-Comment: OpenGL Game Developers Mailing List
X-Sender: "Gil Gribb" <ggribb@mail.ravensoft.com>
Reply-To: OPENGL-GAMEDEV-L@fatcity.com
Errors-To: ML-ERRORS@fatcity.com
Organization: Fat City Network Services, San Diego, California
X-ListServer: v1.0f, build 66; ListGuru (c) 1996-1999 Bruce A. Bergman
Precedence: bulk
Mime-Version: 1.0
Content-Type: text/plain;	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
From: "Gil Gribb" <ggribb@mail.ravensoft.com>
Sender: root@fatcity.com
To: Multiple recipients of list OPENGL-GAMEDEV-L <OPENGL-GAMEDEV-L@fatcity.com>
Subject: Re: The return of PolygonOffset
Date: Fri, 08 Oct 1999 07:00:27 -0800

I guess if other people aren't finding the need to use polygon offset with
multipass and we are (I think mostly with voodoos) then we have a problem in
our code. The only thing I can think is that maybe the floating point
control word is getting screwed up.
-Gil


> At 12:28 AM 10/8/99 -0800, you wrote:
> >
> >On 07-Oct-99 Gil Gribb wrote:
> >>
> >> I claim for multipass techniques, I shouldn't even have to use
> >> polygonoffset, but I do.
> >> -Gil
> >>
> >
> >Well, now I have to ask --
> >
> >does anybody have specific examples consumer-space PC cards that don't do
> >what's expected when you throw identical-geometry multipass techniques at
> them?
> >We've been using multipass techniques throughout our last project (and
> >extensively in our current project) using a depth function of GL_LEQUAL
and
> >identical geometry (terrain or vehicles, for example) with no problems on
any
> >of the chipsets we've tested with.
> >
> >Of course, all of our multipass objects are batched either into display
lists
> >or compiled vertex arrays, which might remove some of the geometric
> variance --
> >but I'm curious to know what video card/driver combos are a good test
case for
> >failure here.
> >
> >Joe
>
> I use GL_LEQUAL for identical geometry multi-pass as well, and haven't
> noticed a problem on Rage 128, Permedia-2, Voodoos, G200/G400, TNT...  No
> problems reported by users, either, in both of our public test releases.
I
> also use the clip plane tweak trick for multi-pass in another segment of
> rendering, and haven't seen any problems there.
>
>
> -- Seumas McNally, Lead Programmer, Longbow Digital Arts
> -- http://www.LongbowDigitalArts.com/seumas/
>
> -----
> FAQ and OpenGL Resources at:
>   http://www.geocities.com/SiliconValley/Hills/9956/OpenGL
>
> --
> Author: Seumas McNally
>   INET: longbow@longbowdigitalarts.com
>
> Fat City Network Services    -- (619) 538-5051  FAX: (619) 538-5051
> San Diego, California        -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L
> (or the name of mailing list you want to be removed from).  You may
> also send the HELP command for other information (like subscribing).

----- 
FAQ and OpenGL Resources at:
  http://www.geocities.com/SiliconValley/Hills/9956/OpenGL

-- 
Author: Gil Gribb
  INET: ggribb@mail.ravensoft.com

Fat City Network Services    -- (619) 538-5051  FAX: (619) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

From fatcity!root@news.cts.com  Fri Oct  8 10:16:02 1999
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["4823" "Fri" "8" "October" "1999" "07:57:11" "-0800" "Tom Forsyth" "Tom.Forsyth@3dlabs.com" nil "121" "RE: The return of PolygonOffset" "^From:" nil nil "10" nil nil nil nil nil]
	nil)
Received: from usagi.cts.com (usagi.cts.com [209.68.192.66])
	by mail.me.umn.edu (8.9.3/8.9.3) with ESMTP id KAA99836
	for <curt@me.umn.edu>; Fri, 8 Oct 1999 10:16:02 -0500 (CDT)
	(envelope-from fatcity!root@news.cts.com)
Received: from king.cts.com (root@king.cts.com [198.68.168.21])
	by usagi.cts.com (8.9.3/8.9.3) with ESMTP id IAA27434;
	Fri, 8 Oct 1999 08:13:01 -0700 (PDT)
Received: from donews.cts.com (donews.cts.com [192.188.72.21])
	by king.cts.com (8.8.7/8.8.7) with SMTP id IAA00206;
	Fri, 8 Oct 1999 08:12:59 -0700 (PDT)
Received: from fatcity by donews.cts.com with uucp
	(Smail3.1.29.1 #5) id m11Zbha-00006Pa; Fri, 8 Oct 99 08:12 PDT
Received: by fatcity.com (21-May-1998/v1.0f-b66/bab) via UUCP id 000B3DA6; Fri, 08 Oct 1999 07:57:11 -0800
Message-ID: <F001.000B3DA6.19991008075711@fatcity.com>
X-Comment: OpenGL Game Developers Mailing List
X-Sender: Tom Forsyth <Tom.Forsyth@3dlabs.com>
Reply-To: OPENGL-GAMEDEV-L@fatcity.com
Errors-To: ML-ERRORS@fatcity.com
Organization: Fat City Network Services, San Diego, California
X-ListServer: v1.0f, build 66; ListGuru (c) 1996-1999 Bruce A. Bergman
Precedence: bulk
Mime-Version: 1.0
Content-Type: text/plain;	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
From: Tom Forsyth <Tom.Forsyth@3dlabs.com>
Sender: root@fatcity.com
To: Multiple recipients of list OPENGL-GAMEDEV-L <OPENGL-GAMEDEV-L@fatcity.com>
Subject: RE: The return of PolygonOffset
Date: Fri, 08 Oct 1999 07:57:11 -0800

Are you passing the vertices in the same order each time? There might be a
problem on some cards (notably the ones that need CPU assistance for
triangle setup) if you draw vertices 1,2,3 in the first pass, and 2,3,1 in
the second. There may also be problems with this sort of setup if they try
to cache edge-slope calculations, for example if you draw the triangles in a
different order (e.g. 1,2,3; 3,2,4 in the first pass, 3,2,4; 1,2,3 in the
second pass). I seem to recall V1s (and maybe V2s - I've never been sure)
needed CPU maths assistance to set up triangles.

If the setup is purely in hardware, neither of these should be a problem -
the results should be identical for each pass.

Tom Forsyth, DirectX Team, 3Dlabs
email: Tom.Forsyth@3Dlabs.com

On Friday, October 08, 1999 4:00 PM, Gil Gribb
[SMTP:ggribb@mail.ravensoft.com] wrote:
> I guess if other people aren't finding the need to use polygon offset with
> multipass and we are (I think mostly with voodoos) then we have a problem
in
> our code. The only thing I can think is that maybe the floating point
> control word is getting screwed up.
> -Gil
> 
> 
> > At 12:28 AM 10/8/99 -0800, you wrote:
> > >
> > >On 07-Oct-99 Gil Gribb wrote:
> > >>
> > >> I claim for multipass techniques, I shouldn't even have to use
> > >> polygonoffset, but I do.
> > >> -Gil
> > >>
> > >
> > >Well, now I have to ask --
> > >
> > >does anybody have specific examples consumer-space PC cards that don't
do
> > >what's expected when you throw identical-geometry multipass techniques
at
> > them?
> > >We've been using multipass techniques throughout our last project (and
> > >extensively in our current project) using a depth function of GL_LEQUAL
> and
> > >identical geometry (terrain or vehicles, for example) with no problems
on
> any
> > >of the chipsets we've tested with.
> > >
> > >Of course, all of our multipass objects are batched either into display
> lists
> > >or compiled vertex arrays, which might remove some of the geometric
> > variance --
> > >but I'm curious to know what video card/driver combos are a good test
> case for
> > >failure here.
> > >
> > >Joe
> >
> > I use GL_LEQUAL for identical geometry multi-pass as well, and haven't
> > noticed a problem on Rage 128, Permedia-2, Voodoos, G200/G400, TNT...
No
> > problems reported by users, either, in both of our public test releases.
> I
> > also use the clip plane tweak trick for multi-pass in another segment of
> > rendering, and haven't seen any problems there.
> >
> >
> > -- Seumas McNally, Lead Programmer, Longbow Digital Arts
> > -- http://www.LongbowDigitalArts.com/seumas/
> >
> > -----
> > FAQ and OpenGL Resources at:
> >   http://www.geocities.com/SiliconValley/Hills/9956/OpenGL
> >
> > --
> > Author: Seumas McNally
> >   INET: longbow@longbowdigitalarts.com
> >
> > Fat City Network Services    -- (619) 538-5051  FAX: (619) 538-5051
> > San Diego, California        -- Public Internet access / Mailing Lists
> > --------------------------------------------------------------------
> > To REMOVE yourself from this mailing list, send an E-Mail message
> > to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
> > the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L
> > (or the name of mailing list you want to be removed from).  You may
> > also send the HELP command for other information (like subscribing).
> 
> ----- 
> FAQ and OpenGL Resources at:
>   http://www.geocities.com/SiliconValley/Hills/9956/OpenGL
> 
> -- 
> Author: Gil Gribb
>   INET: ggribb@mail.ravensoft.com
> 
> Fat City Network Services    -- (619) 538-5051  FAX: (619) 538-5051
> San Diego, California        -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L
> (or the name of mailing list you want to be removed from).  You may
> also send the HELP command for other information (like subscribing).
----- 
FAQ and OpenGL Resources at:
  http://www.geocities.com/SiliconValley/Hills/9956/OpenGL

-- 
Author: Tom Forsyth
  INET: Tom.Forsyth@3dlabs.com

Fat City Network Services    -- (619) 538-5051  FAX: (619) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

From fatcity!root@news.cts.com  Fri Oct  8 12:17:21 1999
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["6030" "Fri" "8" "October" "1999" "10:00:18" "-0800" "Scott, John" "JScott@ravensoft.com" nil "295" "RE: The return of PolygonOffset" "^From:" nil nil "10" nil nil nil nil nil]
	nil)
Received: from usagi.cts.com (usagi.cts.com [209.68.192.66])
	by mail.me.umn.edu (8.9.3/8.9.3) with ESMTP id MAA06746
	for <curt@me.umn.edu>; Fri, 8 Oct 1999 12:17:21 -0500 (CDT)
	(envelope-from fatcity!root@news.cts.com)
Received: from king.cts.com (root@king.cts.com [198.68.168.21])
	by usagi.cts.com (8.9.3/8.9.3) with ESMTP id KAA11348;
	Fri, 8 Oct 1999 10:15:42 -0700 (PDT)
Received: from donews.cts.com (donews.cts.com [192.188.72.21])
	by king.cts.com (8.8.7/8.8.7) with SMTP id KAA00797;
	Fri, 8 Oct 1999 10:15:40 -0700 (PDT)
Received: from fatcity by donews.cts.com with uucp
	(Smail3.1.29.1 #5) id m11ZdcI-00003ca; Fri, 8 Oct 99 10:15 PDT
Received: by fatcity.com (21-May-1998/v1.0f-b66/bab) via UUCP id 000B3F82; Fri, 08 Oct 1999 10:00:18 -0800
Message-ID: <F001.000B3F82.19991008100018@fatcity.com>
X-Comment: OpenGL Game Developers Mailing List
X-Sender: "Scott, John" <JScott@ravensoft.com>
Reply-To: OPENGL-GAMEDEV-L@fatcity.com
Errors-To: ML-ERRORS@fatcity.com
Organization: Fat City Network Services, San Diego, California
X-ListServer: v1.0f, build 66; ListGuru (c) 1996-1999 Bruce A. Bergman
Precedence: bulk
Mime-Version: 1.0
Content-Type: text/plain;	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
From: "Scott, John" <JScott@ravensoft.com>
Sender: root@fatcity.com
To: Multiple recipients of list OPENGL-GAMEDEV-L <OPENGL-GAMEDEV-L@fatcity.com>
Subject: RE: The return of PolygonOffset
Date: Fri, 08 Oct 1999 10:00:18 -0800

We have 4 passes -



1. Architecture.

2. Lightmaps.

3. Detail texturing

4. Volumetric fog.



The volumetric fog is causing the problem [presumably] because it doesn't
use identical geometry.



We also have a problem with the specular pass on models. This was exhibited
on most cards.



Cheers

John



John 'Pagan' Scott, BSc.(Hons), ARCS 

Technology Programmer, Raven Software



Are you passing the vertices in the same order each time? There might be a

problem on some cards (notably the ones that need CPU assistance for

triangle setup) if you draw vertices 1,2,3 in the first pass, and 2,3,1 in

the second. There may also be problems with this sort of setup if they try

to cache edge-slope calculations, for example if you draw the triangles in a

different order (e.g. 1,2,3; 3,2,4 in the first pass, 3,2,4; 1,2,3 in the

second pass). I seem to recall V1s (and maybe V2s - I've never been sure)

needed CPU maths assistance to set up triangles.



If the setup is purely in hardware, neither of these should be a problem -

the results should be identical for each pass.



Tom Forsyth, DirectX Team, 3Dlabs

email: Tom.Forsyth@3Dlabs.com



On Friday, October 08, 1999 4:00 PM, Gil Gribb

[SMTP:ggribb@mail.ravensoft.com] wrote:

> I guess if other people aren't finding the need to use polygon offset with

> multipass and we are (I think mostly with voodoos) then we have a problem

in

> our code. The only thing I can think is that maybe the floating point

> control word is getting screwed up.

> -Gil

> 

> 

> > At 12:28 AM 10/8/99 -0800, you wrote:

> > >

> > >On 07-Oct-99 Gil Gribb wrote:

> > >>

> > >> I claim for multipass techniques, I shouldn't even have to use

> > >> polygonoffset, but I do.

> > >> -Gil

> > >>

> > >

> > >Well, now I have to ask --

> > >

> > >does anybody have specific examples consumer-space PC cards that don't

do

> > >what's expected when you throw identical-geometry multipass techniques

at

> > them?

> > >We've been using multipass techniques throughout our last project (and

> > >extensively in our current project) using a depth function of GL_LEQUAL

> and

> > >identical geometry (terrain or vehicles, for example) with no problems

on

> any

> > >of the chipsets we've tested with.

> > >

> > >Of course, all of our multipass objects are batched either into display

> lists

> > >or compiled vertex arrays, which might remove some of the geometric



 > variance --

> > >but I'm curious to know what video card/driver combos are a good test

> case for

> > >failure here.

> > >

> > >Joe

> >

> > I use GL_LEQUAL for identical geometry multi-pass as well, and haven't

> > noticed a problem on Rage 128, Permedia-2, Voodoos, G200/G400, TNT...

No

> > problems reported by users, either, in both of our public test releases.

> I

> > also use the clip plane tweak trick for multi-pass in another segment of

> > rendering, and haven't seen any problems there.

> >

> >

> > -- Seumas McNally, Lead Programmer, Longbow Digital Arts

> > -- http://www.LongbowDigitalArts.com/seumas/

> >

> > -----

> > FAQ and OpenGL Resources at:

> >   http://www.geocities.com/SiliconValley/Hills/9956/OpenGL

> >

> > --

> > Author: Seumas McNally

> >   INET: longbow@longbowdigitalarts.com

> >

> > Fat City Network Services    -- (619) 538-5051  FAX: (619) 538-5051

> > San Diego, California        -- Public Internet access / Mailing Lists

> > --------------------------------------------------------------------

> > To REMOVE yourself from this mailing list, send an E-Mail message

> > to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in

> > the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L

> > (or the name of mailing list you want to be removed from).  You may

> > also send the HELP command for other information (like subscribing).

> 

> ----- 

> FAQ and OpenGL Resources at:

>   http://www.geocities.com/SiliconValley/Hills/9956/OpenGL

> 

> -- 

> Author: Gil Gribb

>   INET: ggribb@mail.ravensoft.com

> 

> Fat City Network Services    -- (619) 538-5051  FAX: (619) 538-5051

> San Diego, California        -- Public Internet access / Mailing Lists

> --------------------------------------------------------------------

> To REMOVE yourself from this mailing list, send an E-Mail message

> to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in

> the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L

> (or the name of mailing list you want to be removed from).  You may

> also send the HELP command for other information (like subscribing).

----- 

FAQ and OpenGL Resources at:

  http://www.geocities.com/SiliconValley/Hills/9956/OpenGL



-- 

Author: Tom Forsyth

  INET: Tom.Forsyth@3dlabs.com



Fat City Network Services    -- (619) 538-5051  FAX: (619) 538-5051

San Diego, California        -- Public Internet access / Mailing Lists

--------------------------------------------------------------------

To REMOVE yourself from this mailing list, send an E-Mail message

to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in

the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L

(or the name of mailing list you want to be removed from).  You may

also send the HELP command for other information (like subscribing).

----- 
FAQ and OpenGL Resources at:
  http://www.geocities.com/SiliconValley/Hills/9956/OpenGL

-- 
Author: Scott, John
  INET: JScott@ravensoft.com

Fat City Network Services    -- (619) 538-5051  FAX: (619) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

From fatcity!root@news.cts.com  Fri Oct  8 16:31:13 1999
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["5762" "Fri" "8" "October" "1999" "14:12:03" "-0800" "akin@pobox.com" "akin@pobox.com" nil "120" "Re: The return of PolygonOffset " "^From:" nil nil "10" nil nil nil nil nil]
	nil)
Received: from usagi.cts.com (usagi.cts.com [209.68.192.66])
	by mail.me.umn.edu (8.9.3/8.9.3) with ESMTP id QAA21229
	for <curt@me.umn.edu>; Fri, 8 Oct 1999 16:31:12 -0500 (CDT)
	(envelope-from fatcity!root@news.cts.com)
Received: from king.cts.com (root@king.cts.com [198.68.168.21])
	by usagi.cts.com (8.9.3/8.9.3) with ESMTP id OAA29555;
	Fri, 8 Oct 1999 14:29:27 -0700 (PDT)
Received: from donews.cts.com (donews.cts.com [192.188.72.21])
	by king.cts.com (8.8.7/8.8.7) with SMTP id OAA02609;
	Fri, 8 Oct 1999 14:29:25 -0700 (PDT)
Received: from fatcity by donews.cts.com with uucp
	(Smail3.1.29.1 #5) id m11ZhXt-00007ya; Fri, 8 Oct 99 14:27 PDT
Received: by fatcity.com (21-May-1998/v1.0f-b66/bab) via UUCP id 000B4226; Fri, 08 Oct 1999 14:12:03 -0800
Message-ID: <F001.000B4226.19991008141203@fatcity.com>
X-Comment: OpenGL Game Developers Mailing List
X-Sender: akin@pobox.com
Reply-To: OPENGL-GAMEDEV-L@fatcity.com
Errors-To: ML-ERRORS@fatcity.com
Organization: Fat City Network Services, San Diego, California
X-ListServer: v1.0f, build 66; ListGuru (c) 1996-1999 Bruce A. Bergman
Precedence: bulk
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
From: akin@pobox.com
Sender: root@fatcity.com
To: Multiple recipients of list OPENGL-GAMEDEV-L <OPENGL-GAMEDEV-L@fatcity.com>
Subject: Re: The return of PolygonOffset 
Date: Fri, 08 Oct 1999 14:12:03 -0800


Gil Gribb wrote:
| Fair enough, I'll buy that. But if this is the case, you can't even
| guarantee that the second pass even hits the same pixels! So your proposed
| stencil approach won't work perfectly either.

Yes; if the decal is flush with the edge of the base polygon, you can
run into trouble at the edge.  I've never seen it happen except when
there was a software fallback, but it is possible.

| I guess we need a decision procedure. Given:
| 
| *Near and far clip planes
| *FOV
| *Bits in z buffer
| 
| And assuming vanilla consumer hardware.  What is the recommended polygon
| offset for two common senerios?
| 
| a) Multipass; draw each polygon twice. The second pass is identical in all
| aspects that reasonably related to the z buffer.
| b) Sub-polygon decal; draw smaller polygons on top of big polygons. The
| second pass is intended to be planar to first pass, but since vertices are
| not identical to the first pass error is expected.
| 
| If the reccomendation is application dependent, what would be the criteria
| for choosing good parameters for polygon offset?

The recommendation depends on the primitives you're drawing, but there
shouldn't be much dependence on the other things you mentioned.

glPolygonOffset has two arguments:  ``factor'' and ``units''. 
``factor'' is used to force separation between two primitives with
different slopes.  (Particularly in the case where the depth value for
a primitive at a given pixel is determined by sampling the primitive
at some point other than the pixel; lines are the most common case of
this.) ``units'' is used to force separation between two primitives
with the same depth slope.  (Particularly depth slope zero, since
``factor'' can't provide any separation in that case.)

``factor'' is just a scale factor that's applied to the slope of the
base polygon.  ``units'' is more complicated; it's expressed in units
of ``minimum resolvable difference'' (MRD).  1 MRD is the minimum
amount necessary to force two perfectly coplanar polygons to be
separated in depth from one another at every sample point.  If
arithmetic in the pipeline and rasterizer were unlimited in accuracy,
1 MRD would always equal 1 least-significant bit of the Z buffer. 
Since accuracy is limited in practice, and the interactions are
complicated, the best way to determine the MRD is by experiment.  For
SGI machines, I used a simple binary search to find minimum separation
distances for polygons drawn at the near and far clipping planes, and
then took the largest of the two values as the MRD.  This is something
the IHVs need to do, not application developers; at the end of the
process, all the app developer needs to do is specify a ``units''
value of 1.0, and that's guaranteed to separate two perfectly coplanar
primitives.

Now I think we need to do two studies:  A simple approximation, and an
error analysis.  My guess is that the approximation will work pretty
well on all correct implementations of glPolygonOffset.

The simple approximation is to observe that for the two scenarios you
mentioned, the primitives have essentially the same slopes.  That
means you can ignore the ``factor'' argument altogether.  1 MRD is
the minimum amount needed to guarantee separation between two primitives
with the same depth slope, and that's all you need, so the following
command ought to do the trick:

	glPolygonOffset(0.0, 1.0);

The error analysis is much harder, and I'm not sure how to
characterize all the parameters.  For example, in your scenario (b),
precisely how much difference is expected between the slopes of the
base polygon and the slopes of the decal polygon?  And then there are
the arithmetic errors in geometry processing and rasterization, which
vary from machine to machine.

As a back-of-the-envelope guess, I'd say that current cards always
have better slope accuracy than 1 part in 2**12, otherwise you'd see
depth-buffering artifacts for some full-screen primitives on large
screens.  Assuming a maximum primitive width of 2**10 pixels, and a
possible slope difference of 2**(-12) per pixel, then the implied
value for the ``factor'' argument is 2**(10-12), or 0.25.

If your decal polygon depth slope is always within 1/1000 of the base
polygon depth slope (and typically I'd expect *much* better
consistency than that), then a 2**10-pixel-wide primitive implies you
need a ``factor'' argument of about 1.0 to maintain separation.  So
the following command should give a margin of safety adequate for the
truly paranoid:

	glPolygonOffset(1.0, 1.0);

In the tests I've run, I've seen MRD values that are larger than I
would have guessed, which indicates that a surprising number of LSBs
are lost at various points in the pipeline.  Slope accuracy for
iteration and decal polygons is often much better than I assumed
above.  So my expectation would be that 1 MRD would actually be large
enough to cover a lot of the slope errors that occur in real
applications, and you wouldn't need a nonzero ``factor'' argument. 
Always assuming that glPolygonOffset is implemented correctly, of
course.

Allen
----- 
FAQ and OpenGL Resources at:
  http://www.geocities.com/SiliconValley/Hills/9956/OpenGL

-- 
Author: 
  INET: akin@pobox.com

Fat City Network Services    -- (619) 538-5051  FAX: (619) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

From fatcity!root@news.cts.com  Fri Oct  8 18:11:52 1999
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["1044" "Fri" "8" "October" "1999" "15:57:38" "-0800" "Bass, Garrett T." "gtbass@utmb.edu" nil "32" "RE: The return of PolygonOffset" "^From:" nil nil "10" nil nil nil nil nil]
	nil)
Received: from usagi.cts.com (usagi.cts.com [209.68.192.66])
	by mail.me.umn.edu (8.9.3/8.9.3) with ESMTP id SAA24614
	for <curt@me.umn.edu>; Fri, 8 Oct 1999 18:11:52 -0500 (CDT)
	(envelope-from fatcity!root@news.cts.com)
Received: from king.cts.com (root@king.cts.com [198.68.168.21])
	by usagi.cts.com (8.9.3/8.9.3) with ESMTP id QAA29211;
	Fri, 8 Oct 1999 16:09:41 -0700 (PDT)
Received: from donews.cts.com (donews.cts.com [192.188.72.21])
	by king.cts.com (8.8.7/8.8.7) with SMTP id QAA25243;
	Fri, 8 Oct 1999 16:09:39 -0700 (PDT)
Received: from fatcity by donews.cts.com with uucp
	(Smail3.1.29.1 #5) id m11Zj8o-00009Ha; Fri, 8 Oct 99 16:09 PDT
Received: by fatcity.com (21-May-1998/v1.0f-b66/bab) via UUCP id 000B42C1; Fri, 08 Oct 1999 15:57:38 -0800
Message-ID: <F001.000B42C1.19991008155738@fatcity.com>
X-Comment: OpenGL Game Developers Mailing List
X-Sender: "Bass, Garrett T." <gtbass@utmb.edu>
Reply-To: OPENGL-GAMEDEV-L@fatcity.com
Errors-To: ML-ERRORS@fatcity.com
Organization: Fat City Network Services, San Diego, California
X-ListServer: v1.0f, build 66; ListGuru (c) 1996-1999 Bruce A. Bergman
Precedence: bulk
Mime-Version: 1.0
Content-type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
From: "Bass, Garrett T." <gtbass@utmb.edu>
Sender: root@fatcity.com
To: Multiple recipients of list OPENGL-GAMEDEV-L <OPENGL-GAMEDEV-L@fatcity.com>
Subject: RE: The return of PolygonOffset
Date: Fri, 08 Oct 1999 15:57:38 -0800

>We have 4 passes -

>1. Architecture.
>2. Lightmaps.
>3. Detail texturing
>4. Volumetric fog.

John,

	How do you do your volumetric fog?  It seems that if you were using
vertex-color fogging then you wouldn't need a separate pass for it.  I'm
curious what fog method you use.  Perhaps some kind of fogmaps?

Regards,
Garett Bass
gtbass@utmb.edu
----- 
FAQ and OpenGL Resources at:
  http://www.geocities.com/SiliconValley/Hills/9956/OpenGL

-- 
Author: Bass, Garrett T.
  INET: gtbass@utmb.edu

Fat City Network Services    -- (619) 538-5051  FAX: (619) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

From fatcity!root@news.cts.com  Fri Oct  8 18:42:25 1999
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["1415" "Fri" "8" "October" "1999" "16:26:16" "-0800" "Scott, John" "JScott@ravensoft.com" nil "67" "RE: The return of PolygonOffset" "^From:" nil nil "10" nil nil nil nil nil]
	nil)
Received: from usagi.cts.com (usagi.cts.com [209.68.192.66])
	by mail.me.umn.edu (8.9.3/8.9.3) with ESMTP id SAA26151
	for <curt@me.umn.edu>; Fri, 8 Oct 1999 18:42:25 -0500 (CDT)
	(envelope-from fatcity!root@news.cts.com)
Received: from king.cts.com (root@king.cts.com [198.68.168.21])
	by usagi.cts.com (8.9.3/8.9.3) with ESMTP id QAA07114;
	Fri, 8 Oct 1999 16:39:47 -0700 (PDT)
Received: from donews.cts.com (donews.cts.com [192.188.72.21])
	by king.cts.com (8.8.7/8.8.7) with SMTP id QAA01751;
	Fri, 8 Oct 1999 16:39:46 -0700 (PDT)
Received: from fatcity by donews.cts.com with uucp
	(Smail3.1.29.1 #5) id m11Zjc1-00005la; Fri, 8 Oct 99 16:39 PDT
Received: by fatcity.com (21-May-1998/v1.0f-b66/bab) via UUCP id 000B42E9; Fri, 08 Oct 1999 16:26:16 -0800
Message-ID: <F001.000B42E9.19991008162616@fatcity.com>
X-Comment: OpenGL Game Developers Mailing List
X-Sender: "Scott, John" <JScott@ravensoft.com>
Reply-To: OPENGL-GAMEDEV-L@fatcity.com
Errors-To: ML-ERRORS@fatcity.com
Organization: Fat City Network Services, San Diego, California
X-ListServer: v1.0f, build 66; ListGuru (c) 1996-1999 Bruce A. Bergman
Precedence: bulk
Mime-Version: 1.0
Content-Type: text/plain;	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
From: "Scott, John" <JScott@ravensoft.com>
Sender: root@fatcity.com
To: Multiple recipients of list OPENGL-GAMEDEV-L <OPENGL-GAMEDEV-L@fatcity.com>
Subject: RE: The return of PolygonOffset
Date: Fri, 08 Oct 1999 16:26:16 -0800

It is pretty much vertex fogging, but we subdivide the faces in a preprocess
and generate a separate set of fog faces. The faces for regular architecture
are just too big for it to look good. Non identical vertices to transform -
polygonoffset is required.



Cheers

John



John 'Pagan' Scott, BSc.(Hons), ARCS 

Technology Programmer, Raven Software



We have 4 passes -



>1. Architecture.

>2. Lightmaps.

>3. Detail texturing

>4. Volumetric fog.



John,



	How do you do your volumetric fog?  It seems that if you were using

vertex-color fogging then you wouldn't need a separate pass for it.  I'm

curious what fog method you use.  Perhaps some kind of fogmaps?



Regards,

Garett Bass

gtbass@utmb.edu

----- 
FAQ and OpenGL Resources at:
  http://www.geocities.com/SiliconValley/Hills/9956/OpenGL

-- 
Author: Scott, John
  INET: JScott@ravensoft.com

Fat City Network Services    -- (619) 538-5051  FAX: (619) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

From fatcity!root@news.cts.com  Mon Oct 11 07:39:52 1999
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["1873" "Mon" "11" "October" "1999" "05:26:45" "-0800" "Stephen J Baker" "sjbaker@hti.com" nil "44" "Re: The return of PolygonOffset " "^From:" nil nil "10" nil nil nil nil nil]
	nil)
Received: from usagi.cts.com (usagi.cts.com [209.68.192.66])
	by mail.me.umn.edu (8.9.3/8.9.3) with ESMTP id HAA41806
	for <curt@me.umn.edu>; Mon, 11 Oct 1999 07:39:51 -0500 (CDT)
	(envelope-from fatcity!root@news.cts.com)
Received: from king.cts.com (root@king.cts.com [198.68.168.21])
	by usagi.cts.com (8.9.3/8.9.3) with ESMTP id FAA29248;
	Mon, 11 Oct 1999 05:38:49 -0700 (PDT)
Received: from donews.cts.com (donews.cts.com [192.188.72.21])
	by king.cts.com (8.8.7/8.8.7) with SMTP id FAA04008;
	Mon, 11 Oct 1999 05:38:48 -0700 (PDT)
Received: from fatcity by donews.cts.com with uucp
	(Smail3.1.29.1 #5) id m11aej0-00003ra; Mon, 11 Oct 99 05:38 PDT
Received: by fatcity.com (21-May-1998/v1.0f-b66/bab) via UUCP id 000B4B13; Mon, 11 Oct 1999 05:26:45 -0800
Message-ID: <F001.000B4B13.19991011052645@fatcity.com>
X-Comment: OpenGL Game Developers Mailing List
X-Sender: "Stephen J Baker" <sjbaker@hti.com>
Reply-To: OPENGL-GAMEDEV-L@fatcity.com
Errors-To: ML-ERRORS@fatcity.com
Organization: Fat City Network Services, San Diego, California
X-ListServer: v1.0f, build 66; ListGuru (c) 1996-1999 Bruce A. Bergman
Precedence: bulk
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Transfer-Encoding: 7bit
From: "Stephen J Baker" <sjbaker@hti.com>
Sender: root@fatcity.com
To: Multiple recipients of list OPENGL-GAMEDEV-L <OPENGL-GAMEDEV-L@fatcity.com>
Subject: Re: The return of PolygonOffset 
Date: Mon, 11 Oct 1999 05:26:45 -0800

On Thu, 7 Oct 1999 akin@pobox.com wrote:

> | I can't think of any good reasons why OpenGL shouldn't require
> | repeatable Z calculations otherwise though....
> 
> The big problem is compilation.  Even if you always use the same piece
> of source code to implement a given function, optimizing compilers
> will turn that source code into different object code depending on the
> context in which it's compiled.  (Similar effects occur when
> synthesizing gates from hardware design languages.) The differences in
> object code lead to differences in floating-point error, roundoff,
> etc. for rendering in different states.
> 
> This phenomenon has been observed in practice, and is one of the
> reasons for including appendix A in the spec.
 
Ah!  Now I understand.  Bummer.

That makes even the 'reference plane' approach subject to problems
then...which is nasty because that's the only thing I've come across
that comes close to solving the problem perfectly.

Steve Baker                (817)619-2657 (Vox/Vox-Mail)
Raytheon Systems Inc.      (817)619-2466 (Fax)
Work: sjbaker@hti.com      http://www.hti.com
Home: sjbaker1@airmail.net http://web2.airmail.net/sjbaker1

----- 
FAQ and OpenGL Resources at:
  http://www.geocities.com/SiliconValley/Hills/9956/OpenGL

-- 
Author: Stephen J Baker
  INET: sjbaker@hti.com

Fat City Network Services    -- (619) 538-5051  FAX: (619) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

From fatcity!root@news.cts.com  Wed Oct 13 14:58:54 1999
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["1973" "Wed" "13" "October" "1999" "12:40:02" "-0800" "Sean L. Palmer" "spalmer@pobox.com" nil "41" "Re: The return of PolygonOffset" "^From:" nil nil "10" nil nil nil nil nil]
	nil)
Received: from usagi.cts.com (usagi.cts.com [209.68.192.66])
	by mail.me.umn.edu (8.9.3/8.9.3) with ESMTP id OAA07483
	for <curt@me.umn.edu>; Wed, 13 Oct 1999 14:58:52 -0500 (CDT)
	(envelope-from fatcity!root@news.cts.com)
Received: from king.cts.com (root@king.cts.com [198.68.168.21])
	by usagi.cts.com (8.9.3/8.9.3) with ESMTP id MAA09971;
	Wed, 13 Oct 1999 12:57:08 -0700 (PDT)
Received: from donews.cts.com (donews.cts.com [192.188.72.21])
	by king.cts.com (8.8.7/8.8.7) with SMTP id MAA15167;
	Wed, 13 Oct 1999 12:57:02 -0700 (PDT)
Received: from fatcity by donews.cts.com with uucp
	(Smail3.1.29.1 #5) id m11bUWB-00006Za; Wed, 13 Oct 99 12:56 PDT
Received: by fatcity.com (21-May-1998/v1.0f-b66/bab) via UUCP id 000B6F92; Wed, 13 Oct 1999 12:40:02 -0800
Message-ID: <F001.000B6F92.19991013124002@fatcity.com>
X-Comment: OpenGL Game Developers Mailing List
X-Sender: "Sean L. Palmer" <spalmer@pobox.com>
Reply-To: OPENGL-GAMEDEV-L@fatcity.com
Errors-To: ML-ERRORS@fatcity.com
Organization: Fat City Network Services, San Diego, California
X-ListServer: v1.0f, build 66; ListGuru (c) 1996-1999 Bruce A. Bergman
Precedence: bulk
Mime-Version: 1.0
Content-Type: text/plain;	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
From: "Sean L. Palmer" <spalmer@pobox.com>
Sender: root@fatcity.com
To: Multiple recipients of list OPENGL-GAMEDEV-L <OPENGL-GAMEDEV-L@fatcity.com>
Subject: Re: The return of PolygonOffset
Date: Wed, 13 Oct 1999 12:40:02 -0800

I just made some translucent wall/floor decals and am wondering if rendering
them last using GL_LEQUAL depth compare mode, AND forcibly offsetting the
vertices away from the wall by a small (imperceptible, but numerically
significant) amount, would do the trick on all hardware.  Seems to work
great on the hardware I've tried so far.

By doing the small offset toward the front of the wall polygon, I am
intending to make sure that when the hardware rounds the vertex coordinates,
that it doesn't end up rounding them so the polygon plane is behind the
wall, but in front of it, so that LEQUAL compare will work ok.

Note that for this app I don't care if you see z-fighting well off in the
distance, as there generally won't be much light that far away.  Seems the
error would be highest when the objects are only a few pixels in screen
space--but at that point it's not going to matter.

I just realized the problem lies not in specifying the decal vertices so
they lie in front of the plane of the original polygon, but the problem is
that the hardware will round not only the decal poly but also the wall poly,
and it could make errors in the exact wrong directions for both

Now, for the FUTURE, how would I be able to ensure correct sorting at all
ranges?  Or can I?

----- 
FAQ and OpenGL Resources at:
  http://www.geocities.com/SiliconValley/Hills/9956/OpenGL

-- 
Author: Sean L. Palmer
  INET: spalmer@pobox.com

Fat City Network Services    -- (619) 538-5051  FAX: (619) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

From fatcity!root@news.cts.com  Wed Oct 13 21:58:25 1999
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["4275" "Wed" "13" "October" "1999" "19:41:36" "-0800" "Sean L. Palmer" "spalmer@pobox.com" nil "101" "Re: The return of PolygonOffset" "^From:" nil nil "10" nil nil nil nil nil]
	nil)
Received: from usagi.cts.com (usagi.cts.com [209.68.192.66])
	by mail.me.umn.edu (8.9.3/8.9.3) with ESMTP id VAA26378
	for <curt@me.umn.edu>; Wed, 13 Oct 1999 21:58:25 -0500 (CDT)
	(envelope-from fatcity!root@news.cts.com)
Received: from king.cts.com (root@king.cts.com [198.68.168.21])
	by usagi.cts.com (8.9.3/8.9.3) with ESMTP id TAA00323;
	Wed, 13 Oct 1999 19:56:16 -0700 (PDT)
Received: from donews.cts.com (donews.cts.com [192.188.72.21])
	by king.cts.com (8.8.7/8.8.7) with SMTP id TAA07918;
	Wed, 13 Oct 1999 19:56:13 -0700 (PDT)
Received: from fatcity by donews.cts.com with uucp
	(Smail3.1.29.1 #5) id m11bb3p-0000Aba; Wed, 13 Oct 99 19:56 PDT
Received: by fatcity.com (21-May-1998/v1.0f-b66/bab) via UUCP id 000B7AFC; Wed, 13 Oct 1999 19:41:36 -0800
Message-ID: <F001.000B7AFC.19991013194136@fatcity.com>
X-Comment: OpenGL Game Developers Mailing List
X-Sender: "Sean L. Palmer" <spalmer@pobox.com>
Reply-To: OPENGL-GAMEDEV-L@fatcity.com
Errors-To: ML-ERRORS@fatcity.com
Organization: Fat City Network Services, San Diego, California
X-ListServer: v1.0f, build 66; ListGuru (c) 1996-1999 Bruce A. Bergman
Precedence: bulk
Mime-Version: 1.0
Content-Type: text/plain;	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
From: "Sean L. Palmer" <spalmer@pobox.com>
Sender: root@fatcity.com
To: Multiple recipients of list OPENGL-GAMEDEV-L <OPENGL-GAMEDEV-L@fatcity.com>
Subject: Re: The return of PolygonOffset
Date: Wed, 13 Oct 1999 19:41:36 -0800

Considering how bad support seems to be for polygonoffset, it seemed to be
the easier approach, and believe it or not is seems to be working flawlessly
even on 16-bit zbuffers.

Go figure.  ;)

I do agree with you in theory though.  I'm not taking slope or distance or
anything into account.  So I'd expect to see errors, but I don't see any.

> Offsetting the vertices is _not_ what you want to do. It just doesn't jive
> with the error going on with the z buffer. Although we have had our share
of
> trouble tweaking polygonoffset, it works much much better that a simple
> offset. Even if you compute the offset using some sound analysis of
> plausible z buffer errors, it still doesn't work very well.
> -Gil
>
>
> > I just made some translucent wall/floor decals and am wondering if
> rendering
> > them last using GL_LEQUAL depth compare mode, AND forcibly offsetting
the
> > vertices away from the wall by a small (imperceptible, but numerically
> > significant) amount, would do the trick on all hardware.  Seems to work
> > great on the hardware I've tried so far.
> >
> > By doing the small offset toward the front of the wall polygon, I am
> > intending to make sure that when the hardware rounds the vertex
> coordinates,
> > that it doesn't end up rounding them so the polygon plane is behind the
> > wall, but in front of it, so that LEQUAL compare will work ok.
> >
> > Note that for this app I don't care if you see z-fighting well off in
the
> > distance, as there generally won't be much light that far away.  Seems
the
> > error would be highest when the objects are only a few pixels in screen
> > space--but at that point it's not going to matter.
> >
> > I just realized the problem lies not in specifying the decal vertices so
> > they lie in front of the plane of the original polygon, but the problem
is
> > that the hardware will round not only the decal poly but also the wall
> poly,
> > and it could make errors in the exact wrong directions for both
> >
> > Now, for the FUTURE, how would I be able to ensure correct sorting at
all
> > ranges?  Or can I?
> >
> > -----
> > FAQ and OpenGL Resources at:
> >   http://www.geocities.com/SiliconValley/Hills/9956/OpenGL
> >
> > --
> > Author: Sean L. Palmer
> >   INET: spalmer@pobox.com
> >
> > Fat City Network Services    -- (619) 538-5051  FAX: (619) 538-5051
> > San Diego, California        -- Public Internet access / Mailing Lists
> > --------------------------------------------------------------------
> > To REMOVE yourself from this mailing list, send an E-Mail message
> > to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
> > the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L
> > (or the name of mailing list you want to be removed from).  You may
> > also send the HELP command for other information (like subscribing).
>
> -----
> FAQ and OpenGL Resources at:
>   http://www.geocities.com/SiliconValley/Hills/9956/OpenGL
>
> --
> Author: Gil Gribb
>   INET: ggribb@mail.ravensoft.com
>
> Fat City Network Services    -- (619) 538-5051  FAX: (619) 538-5051
> San Diego, California        -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L
> (or the name of mailing list you want to be removed from).  You may
> also send the HELP command for other information (like subscribing).

----- 
FAQ and OpenGL Resources at:
  http://www.geocities.com/SiliconValley/Hills/9956/OpenGL

-- 
Author: Sean L. Palmer
  INET: spalmer@pobox.com

Fat City Network Services    -- (619) 538-5051  FAX: (619) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

From fatcity!root@news.cts.com  Thu Oct 14 08:49:30 1999
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["1631" "Thu" "14" "October" "1999" "06:29:47" "-0800" "Stephen J Baker" "sjbaker@hti.com" nil "37" "Re: The return of PolygonOffset" "^From:" nil nil "10" nil nil nil nil nil]
	nil)
Received: from usagi.cts.com (usagi.cts.com [209.68.192.66])
	by mail.me.umn.edu (8.9.3/8.9.3) with ESMTP id IAA50311
	for <curt@me.umn.edu>; Thu, 14 Oct 1999 08:49:30 -0500 (CDT)
	(envelope-from fatcity!root@news.cts.com)
Received: from king.cts.com (root@king.cts.com [198.68.168.21])
	by usagi.cts.com (8.9.3/8.9.3) with ESMTP id GAA03758;
	Thu, 14 Oct 1999 06:47:55 -0700 (PDT)
Received: from donews.cts.com (donews.cts.com [192.188.72.21])
	by king.cts.com (8.8.7/8.8.7) with SMTP id GAA24442;
	Thu, 14 Oct 1999 06:47:54 -0700 (PDT)
Received: from fatcity by donews.cts.com with uucp
	(Smail3.1.29.1 #5) id m11blEF-00003za; Thu, 14 Oct 99 06:47 PDT
Received: by fatcity.com (21-May-1998/v1.0f-b66/bab) via UUCP id 000B8132; Thu, 14 Oct 1999 06:29:47 -0800
Message-ID: <F001.000B8132.19991014062947@fatcity.com>
X-Comment: OpenGL Game Developers Mailing List
X-Sender: "Stephen J Baker" <sjbaker@hti.com>
Reply-To: OPENGL-GAMEDEV-L@fatcity.com
Errors-To: ML-ERRORS@fatcity.com
Organization: Fat City Network Services, San Diego, California
X-ListServer: v1.0f, build 66; ListGuru (c) 1996-1999 Bruce A. Bergman
Precedence: bulk
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Transfer-Encoding: 7bit
From: "Stephen J Baker" <sjbaker@hti.com>
Sender: root@fatcity.com
To: Multiple recipients of list OPENGL-GAMEDEV-L <OPENGL-GAMEDEV-L@fatcity.com>
Subject: Re: The return of PolygonOffset
Date: Thu, 14 Oct 1999 06:29:47 -0800

On Wed, 13 Oct 1999, Gil Gribb wrote:

> Offsetting the vertices is _not_ what you want to do. It just doesn't jive
> with the error going on with the z buffer. Although we have had our share of
> trouble tweaking polygonoffset, it works much much better that a simple
> offset. Even if you compute the offset using some sound analysis of
> plausible z buffer errors, it still doesn't work very well.

Right - an offset in the actual model coordinates doesn't work
well because the offset tends to be visible as a parallax effect.

For all its faults, the glPolygonOffset happens *AFTER* perspective,
so the pixels touched by an offset polygon should be the same
as the ones that would be touched by one without an offset.

Steve Baker                (817)619-2657 (Vox/Vox-Mail)
Raytheon Systems Inc.      (817)619-2466 (Fax)
Work: sjbaker@hti.com      http://www.hti.com
Home: sjbaker1@airmail.net http://web2.airmail.net/sjbaker1

----- 
FAQ and OpenGL Resources at:
  http://www.geocities.com/SiliconValley/Hills/9956/OpenGL

-- 
Author: Stephen J Baker
  INET: sjbaker@hti.com

Fat City Network Services    -- (619) 538-5051  FAX: (619) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

From fatcity!root@news.cts.com  Thu Oct 14 11:13:47 1999
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["2087" "Thu" "14" "October" "1999" "08:56:26" "-0800" "Neal Tringham" "neal@pseudonymz.demon.co.uk" nil "44" "Re: The return of PolygonOffset" "^From:" nil nil "10" nil nil nil nil nil]
	nil)
Received: from usagi.cts.com (usagi.cts.com [209.68.192.66])
	by mail.me.umn.edu (8.9.3/8.9.3) with ESMTP id LAA57433
	for <curt@me.umn.edu>; Thu, 14 Oct 1999 11:13:47 -0500 (CDT)
	(envelope-from fatcity!root@news.cts.com)
Received: from king.cts.com (root@king.cts.com [198.68.168.21])
	by usagi.cts.com (8.9.3/8.9.3) with ESMTP id JAA24185;
	Thu, 14 Oct 1999 09:11:23 -0700 (PDT)
Received: from donews.cts.com (donews.cts.com [192.188.72.21])
	by king.cts.com (8.8.7/8.8.7) with SMTP id JAA00948;
	Thu, 14 Oct 1999 09:11:18 -0700 (PDT)
Received: from fatcity by donews.cts.com with uucp
	(Smail3.1.29.1 #5) id m11bnRv-00005za; Thu, 14 Oct 99 09:09 PDT
Received: by fatcity.com (21-May-1998/v1.0f-b66/bab) via UUCP id 000B858B; Thu, 14 Oct 1999 08:56:26 -0800
Message-ID: <F001.000B858B.19991014085626@fatcity.com>
X-Comment: OpenGL Game Developers Mailing List
X-Sender: "Neal Tringham" <neal@pseudonymz.demon.co.uk>
Reply-To: OPENGL-GAMEDEV-L@fatcity.com
Errors-To: ML-ERRORS@fatcity.com
Organization: Fat City Network Services, San Diego, California
X-ListServer: v1.0f, build 66; ListGuru (c) 1996-1999 Bruce A. Bergman
Precedence: bulk
Mime-Version: 1.0
Content-Type: text/plain;	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
From: "Neal Tringham" <neal@pseudonymz.demon.co.uk>
Sender: root@fatcity.com
To: Multiple recipients of list OPENGL-GAMEDEV-L <OPENGL-GAMEDEV-L@fatcity.com>
Subject: Re: The return of PolygonOffset
Date: Thu, 14 Oct 1999 08:56:26 -0800

Sean L. Palmer <spalmer@pobox.com> writes:
>I think for this game (it's almost done) I'm gonna stick with the manual
>offset, and try glPolygonOffset once the drivers seem to be a little more
>ready for it, next game.  ;)

I can see your point.

It is true that for my stuff I initially tried doing manual offsets for the
shadows on the grounds that a number of drivers didn't seem to implement
polygon offset at all at that stage, and there were... problems.  Basically
it proved impossible to get the different parts of the volumetric shadows
not to tear visibly against each other and not z fight with the underlying
geometry on all cards, for all the obvious reasons which I think Gil Gribb's
already talked about.  So I've ended up using polygon offset and disabling
the shadows in the default menu options on the ATI Rage Pro (where polygon
offset doesn't seem to do anything - if anyone's got it working on the Rage
Pro I'd be very pleased to hear from them:-)).

But if you need the offset to work on drivers where polygon offset currently
isn't supported (i.e. you need it for something that is guaranteed rendering
functionality rather than an option) a manual offset may be your best option
for a game that's due to be mastered within the month or something...

                            Neal Tringham (VX)
                            (neal@pseudonymz.demon.co.uk)



----- 
FAQ and OpenGL Resources at:
  http://www.geocities.com/SiliconValley/Hills/9956/OpenGL

-- 
Author: Neal Tringham
  INET: neal@pseudonymz.demon.co.uk

Fat City Network Services    -- (619) 538-5051  FAX: (619) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

From fatcity!root@news.cts.com  Thu Oct 14 13:14:58 1999
X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
	["3725" "Thu" "14" "October" "1999" "10:43:00" "-0800" "Stephen J Baker" "sjbaker@hti.com" nil "78" "Re: The return of PolygonOffset" "^From:" nil nil "10" nil nil nil nil nil]
	nil)
Received: from usagi.cts.com (usagi.cts.com [209.68.192.66])
	by mail.me.umn.edu (8.9.3/8.9.3) with ESMTP id NAA64073
	for <curt@me.umn.edu>; Thu, 14 Oct 1999 13:14:58 -0500 (CDT)
	(envelope-from fatcity!root@news.cts.com)
Received: from king.cts.com (root@king.cts.com [198.68.168.21])
	by usagi.cts.com (8.9.3/8.9.3) with ESMTP id LAA12477;
	Thu, 14 Oct 1999 11:13:26 -0700 (PDT)
Received: from donews.cts.com (donews.cts.com [192.188.72.21])
	by king.cts.com (8.8.7/8.8.7) with SMTP id LAA08069;
	Thu, 14 Oct 1999 11:13:25 -0700 (PDT)
Received: from fatcity by donews.cts.com with uucp
	(Smail3.1.29.1 #5) id m11bpB1-00001Da; Thu, 14 Oct 99 11:00 PDT
Received: by fatcity.com (21-May-1998/v1.0f-b66/bab) via UUCP id 000B88CE; Thu, 14 Oct 1999 10:43:00 -0800
Message-ID: <F001.000B88CE.19991014104300@fatcity.com>
X-Comment: OpenGL Game Developers Mailing List
X-Sender: "Stephen J Baker" <sjbaker@hti.com>
Reply-To: OPENGL-GAMEDEV-L@fatcity.com
Errors-To: ML-ERRORS@fatcity.com
Organization: Fat City Network Services, San Diego, California
X-ListServer: v1.0f, build 66; ListGuru (c) 1996-1999 Bruce A. Bergman
Precedence: bulk
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Transfer-Encoding: 7bit
From: "Stephen J Baker" <sjbaker@hti.com>
Sender: root@fatcity.com
To: Multiple recipients of list OPENGL-GAMEDEV-L <OPENGL-GAMEDEV-L@fatcity.com>
Subject: Re: The return of PolygonOffset
Date: Thu, 14 Oct 1999 10:43:00 -0800

On Thu, 14 Oct 1999, Neal Tringham wrote:

> Sean L. Palmer <spalmer@pobox.com> writes:
> >I think for this game (it's almost done) I'm gonna stick with the manual
> >offset, and try glPolygonOffset once the drivers seem to be a little more
> >ready for it, next game.  ;)
> 
> I can see your point.
> 
> It is true that for my stuff I initially tried doing manual offsets for the
> shadows on the grounds that a number of drivers didn't seem to implement
> polygon offset at all at that stage, and there were... problems.  Basically
> it proved impossible to get the different parts of the volumetric shadows
> not to tear visibly against each other and not z fight with the underlying
> geometry on all cards, for all the obvious reasons which I think Gil Gribb's
> already talked about.  So I've ended up using polygon offset and disabling
> the shadows in the default menu options on the ATI Rage Pro (where polygon
> offset doesn't seem to do anything - if anyone's got it working on the Rage
> Pro I'd be very pleased to hear from them:-)).
 
I don't think glPolygonOffset works with Mesa/3Dfx either...although
there was some talk of fixing that in the upcoming Mesa 3.1 release.

> But if you need the offset to work on drivers where polygon offset currently
> isn't supported (i.e. you need it for something that is guaranteed rendering
> functionality rather than an option) a manual offset may be your best option
> for a game that's due to be mastered within the month or something...
 
One trick that I've found to work is to nudge the near/far clip planes
somewhat between rendering the base and layer geometry. That has the
effect of changing the meaning of the Z values currently in the Z
buffer - so that (in effect) we move the scene as currently rendered
bodily backwards - render the decal layer at it's normal Z -
then bodily move everything back where it was by changing the
clip planes back again.

This works (actually, very well) on all OpenGL implementations...
but suffers from three problems:

1) You don't know how much to move everything by - it's something you
   have to play with and set up for every board type. (Which may not
   be so bad if there are only one or two that don't do glPolygonOffset)

2) Because you moved the clip planes, any decaled geometry which
   is poking through the plane of the screen is clipped differently
   from the underlying base polygon. I don't see that as an important
   issue.

3) It's likely that the driver is poorly optimised for rapid changes
   in the near/far clip.  Mesa (for example) recomputes the fog tables
   each time you do it. However, since decals need to be sorted by
   state anyway, it's no big deal really.

Whilst these problems are manageable, I'd only use this trick on
systems that don't implement a good glPolygonOffset.

Steve Baker                (817)619-2657 (Vox/Vox-Mail)
Raytheon Systems Inc.      (817)619-2466 (Fax)
Work: sjbaker@hti.com      http://www.hti.com
Home: sjbaker1@airmail.net http://web2.airmail.net/sjbaker1

----- 
FAQ and OpenGL Resources at:
  http://www.geocities.com/SiliconValley/Hills/9956/OpenGL

-- 
Author: Stephen J Baker
  INET: sjbaker@hti.com

Fat City Network Services    -- (619) 538-5051  FAX: (619) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB OPENGL-GAMEDEV-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

