CompuServe Thread

What I meant was that you can "model" a bump map fairly easily. Say yuo wanted a bitmap that produced a bump of a series of balls around a clock face. Without too much thought, you could quickly make a cylinder and array a series of GSspheres around it, letting them intersect the cylinder as much as you want them to "bump" out in the map. Now go into video post (there's no need for lighting!) and render the perpendicular viewport. You now have grey scale map that corresponds to the distance the objects were from you – an bump map of balls pushing through a round face. Now I bet you were searching for a way to do true displacement mapping – actuallly changing the profile of a mesh. Well, in the hands of a good IPAS prograrmer that could be possible now that R4 gives them access to the Z-Buffer. For example, Digimation's new LenzEFX package effects glows around objects based upon the Z-Buffer – allowing you to exapand the glow as far as you wish from the surface of the mesh. – Phil

>>I hope DavidS jumps in and elaborates a little for everyone… What, and spoil the suprise? Ok, time for a shameless plug… All the details are in chapter 12 of "3D Studio special effects" <g> Using the Z-buffer as a mask in video post, an object can be made to fade into the background or layer behind it. I think the best results would come from using a matte rendered with a white matte material and distance cueing, instead of the true Z-buffer image as derived from the Seez IPAS. (see my note to Gary). Sorry, I can't really go into much detail now, but I do go into extreme detail on this method in the book, so anyone interested should definately have a look. David

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).