CompuServe Thread

Hi Judy, << z-buffer..? >> Many hidden surface algorithms have been developed based on z-buffering. It is best viewed as operating in a 3 dimensional screen space. Each pixel is associated with a 2 dimensional screen coordinate (Xs,Ys) together with a depth or z-value. For each pixel we compare it's interpolated depth with the depth already stored in the z-buffer (Xs,Ys). If this value is less than the stored value then the pixel is nearer the viewer than the previously encountered pixels. If you have R4, check out the following…. File Info for SEEZ.ZIP Section: IPAS Usage Contributor: 76702,413 Size: 24924 Submitted: 11/9/94 Type: Binary Accesses: 301 Title: Zbuffer IPAS IXP plugin for 3DSr4 from Yost Group Keys: SEEZ ZBUFFER ACCESSOR IPAS IXP REQUIRES 3DSR4 YOST GROUP This zip file contains SEEZ.IXP, a public domain IPAS routine by Tom Hudson of the Yost Group that will let you access the z-buffer inside of 3DSr4 for interesting compositing effects in the Video Post system. It also includes the source code for the routine (SEEZ.C) for IPAS developers to use as a learning aid for accessing the z-buffer with their own applications. [dl time at 2400 baud: 2 min]

Judy, << z-buffer advantages? >> If you don't mind my jumping in: As I understand it the major advantage of z-buffering is that it can give you pixel-accurate intersections between objects. Other algorithms which sort at the face or object level usually pay for it with increased artifacting…faces showing through each other, and so on…because of the complicated math they use to calculate intersections. The major disadvantage of z-buffering is the memory required to maintain the buffer. There are also potential problems with the number of faces which can be behind one another in a particular line of sight, and with the minimum distance between two faces so that they will not show through each other…but I have not known 3D Studio to suffer from either of these problems. Stephen Milligan Graphic Media Systems

Hi Judy, << Could someone explain to me what is Z-Buffering and what are its advantages? >> I've tried to find all of Gary's recent comments on the z-buffer. Here they are… "Yup. You can access the z-buffer now. There's a new IPAS API call (vpost_zbuf) that'll give you a 4-BYTE-per-pixel version of it (which would be 1.2Mb for a 640×480 screen, btw). We'll put a simple little IXP up here in DL1 after R4 ships that lets you save that to an image file if you want. – G In addition to Phil's excellent technique for making bump-maps, the z-buffer gives you a depth mask that you can use for compositing, so you can do your own atmosphere-like effects. David Stinnett has this method down cold, so if he's around, he could explain it for ya. – G I can understand your confusion, but it isn't you. There isn't supposed to be any antialiasing in a z-buffer. Consider this. In the z-buffer, a pixel can have any number of surfaces inside of it, but only the nearest surface's distance is recorded. How would antialiasing be possible? You could certainly have a finer-resolution z-buffer than 8-bits (since the z-buffer info is stored as a floating-point number), but you'd have to have an IXP that wrote it out in higher bit-depth (24, for example) and then an application that could use that extra info. – G Good point. What you really need for z-buffer compositing effects is an IXP that does some filtering around the objects. Here's what's actually going on in SEEZ. SEEZ takes the 'zmin' and 'zmax' values from the FrameParm structure, then normalizes the values between the z minimum and z maximum to range from 255-0. That's why SEEZ causes the nearest part of the objects in the scene to be bright white. If the code is altered with some arbitrary near/far values, the objects will get dimmer as they recede. (Tom wrote SEEZ this way so that he could mess around with random dot stereograms.) To summarize, each pixel's Z value reflects the distance from the camera to the nearest object fragment in that pixel. If the view is not a camera, then the Z value in the pixel is not the distance from the viewer (since the view is orthographic, there is no viewpoint) but the distance from the point being looked at. In orthographic views, Z values can be negative. True, this can cause aliasing to occur if simple compositing is done, and won't work well for transparent objects, but with some filtering, it can work very effectively. This is what the folks at Digimation are probably doing to get their depth-of-field zbuffer-based routine, and it's also why I put the source code to SEEZ in the zip file… so other developers could take the concepts and run with them (a la Digimation). – G" jonas[adesk]