Clearing the z buffer with my own z data

OpenGL OpenGL: Advanced Coding
1

If I want to clear the z buffer with my own pregenerated z buffer array, how would I do that?

Is the glDrawPixels the only way?. The reason I ask is ofcourse because its a bit too slow…

2

Originally posted by AndersO:
Is the glDrawPixels the only way?

If your hardware supports fragment programs, you can render a textured quad that fits over the whole viewport, and setup the fragment program to output the texture colors to the depth component.
I don’t know if it will really be faster, though. I think it should be faster on high-end consumer-level cards.

3

take a look at the ARB_buffer_region extension. with this extension, you can draw copy the depthbuffer into an offscreen buffer (but still in videomem) and of course back from this buffer to the depthbuffer.
this works fine with all nvidia cards, but on radeons it’s still tooo slow. actually radeons don’t support the buffer_region extension, but you can simulate the behaviour of this extension with pbuffers und make_current_read. however, readeons have an strange internal depthformat which leads to very slow depthbuffer-reads/writes…(all radeons below 9500pro. newer cards are ok)

actually, there is no unified solution for all cards. you have to code at least 2 paths (nvidia/ati).
http://oss.sgi.com/projects/ogl-sample/registry/ARB/wgl_buffer_region.txt http://oss.sgi.com/projects/ogl-sample/registry/ARB/wgl_pbuffer.txt http://oss.sgi.com/projects/ogl-sample/registry/ARB/wgl_make_current_read.txt

4

For static depth data, AdrianD’s method is the best.

For dynamic data, you should try out drawing GL_POINTS. I’ve written a bit more about that in this thread , for me it’s quite acceptable. AdrianD didn’t want to agree though

5

Originally posted by zeckensack:
[b]For static depth data, AdrianD’s method is the best.

For dynamic data, you should try out drawing GL_POINTS. I’ve written a bit more about that in this thread , for me it’s quite acceptable. AdrianD didn’t want to agree though [/b]

actually, i agreed. With the boundingbox optimizations i metioned it turend out, that this method(with boundingbox outimizations) is the fastest solution for ALL systems!
so i decided to use it even if a buffer_region extension is present!
i also skipped my 8-bit-dpethbuffer-shadowmap approach(beacuse this method works much much slower than the new one)

im still using my buffer_region/pbuffer solutions, but only when stencil shadows are turned on.
in all other cases i am using the GL_POINTS approach. it gives me a speedup of 100%!!!

thanks, zeckensack.

6

I would avoid glDrawPixels.

I think that using buffer_region is the simplest fastest way to get things working.
The only problem is that when you do a save while the window is partially covered or offscreen, you loose the pixels in those regions.
Otherwise, it is very fast and easy to use.

I wish ATI had the extension as well.

7

Well, I was hoping for something that worked on “all cards” at acceptable framerates. Perhaps I’ll give the GL_POINTS approach a go.

Thanks for all your ideas!

[This message has been edited by AndersO (edited 08-23-2003).]