Re: Problems with Z-buffer.

New Message Reply Date view Thread view Subject view Author view

Angus Dorbie (dorbie++at++sgi.com)
Fri, 15 May 1998 23:16:26 -0700

Steve Baker wrote:
>
> On Fri, 15 May 1998, Angus Dorbie wrote:
>
> > Kenneth Sewell wrote:
> > >
> > > I have been working on a flight sim that loads in several
> > > rectangular patches of terrain. The problem is that the z-buffer
> > > works correctly for the elements of each patch individually but
> > > not between the elements of two different patches. I apologize
> > > if I'm not being very clear, I'll give an example. If I have two
> > > patches A and B (each of them made up of a few thousand
> > > polygons) with A being closer to the viewer than B. All of
> > > the polygons in A have been rendered properly with respect
> > > to each other, all of the polygons of B have been rendered
> > > properly with respect to each other. However parts of B
> > > that should be hidden behind A, are drawn as though they
> > > are nearer. This only happens to part of B, the rest of it is
> > > behind A, like it should be. I am loading all of the patches
> > > at the same time and they are all children of one DCS node.
> > > I would appreciate any help you can offer. Thanks.
> > >
> >
> > This is very strange.
>
> It certainly is.
>
> > Are you sure that you have a zbuffer, could you be getting lucky
> > with the order of the polygons and just seeing a painters effect
> > but the tiles are in the wrong order and betray what's really happening?
>
> I think he must have a Z buffer of some kind because he says:
>
> > > However parts of B
> > > that should be hidden behind A, are drawn as though they
> > > are nearer. This only happens to part of B, the rest of it is
> > > behind A, like it should be.
>
> If *some* of B comes out in front and some behind then we probably
> have to assume that some kind of pixel occultation is going on.
>

Painters explains this perfectly, particularly if you consider state
sorting.

> Although it's possible that Performer is sorting polygons by
> GeoState - which might explain this behaviour in the absence
> of a Z buffer.

See, you even agree ;-)

Cheers,Angus.

>
> Another possibility is that the terrain is being rendered
> in some manner that makes Performer see some of the polygons
> as translucent - so they are sorted into a different bucket
> and rendered at the end.
>
> I would suggest that perhaps the most likely reason for this
> strange behaviour is that the Z buffer *is* present but it's
> precision is really, really, terrible. As all who read this
> list regularly will know, it's very easy for beginners to
> get this wrong.
>
> Kenneth: What near and far clip planes are you using?
> Does your terrain use a variety of pfGeoState's
> or does it all share a single pfGeoState?
>
> Steve Baker (817)619-8776 (Vox/Vox-Mail)
> Raytheon Systems Inc. (817)619-4028 (Fax)
> Work: SBaker++at++link.com http://www.hti.com
> Home: SJBaker1++at++airmail.net http://web2.airmail.net/sjbaker1

-- 
"Only the mediocre are always at their best." -- Jean Giraudoux 


For advanced 3D graphics Performer + OpenGL based examples and tutors:
http://www.dorbie.com/
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer++at++sgi.com
        Admin. requests:  info-performer-request++at++sgi.com

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:57:24 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.