Skip to main content
gamedev.net
🔒 Locked

Render To depth buffer?

Started by duhroach 8 replies 650+ views
Original Post
duhroach
duhroach
Hey all, i read alot about "Rendering to the depth buffer, and reading from that" I was wondering, how exactually do you render to the "depth buffer" as opposed to the regualr screen? and on top of that, how do you read those pixels back? thanks ~Main == Colt "MainRoach" McAnlis Programmer www.badheat.com/sinewave
DannerGL
DannerGL
Your render as normal but you disable the writes to RGBA with glColorMask(GL_FALSE, GL_FALSE, GL_FALSE, GL_FALSE). If you have a stencil buffer also use glStencilMask(0)/

You can use glReadPixels to read the depth buffer back, but be warned that it''s probably going to be slow.
duhroach
duhroach
How do you read the depth buffer?
just a glReadPixels()? and if so, what flags do i use?

~Main

==
Colt "MainRoach" McAnlis
Programmer
www.badheat.com/sinewave
DannerGL
DannerGL
quote:
Original post by duhroach
How do you read the depth buffer?
just a glReadPixels()? and if so, what flags do i use?


Just glReadPixels. Use GL_DEPTH in the format parameter (5th argument).

Xero-X2
Xero-X2
well its not really an answer to your question but it is a tip.

Neveruse glReadPixels if you can avoid it (unless it not realtime). reason - Take a geforce2 mx give it a depth and color clear at about 500 X 400 pixel display size you get a few 100fps
add a glreadpixel command you get .1 fps, not saying this happens this bad for every one but it did happen for me. just a good thing to know about reading pixels, if its not realtime I guess its ok tho.

NOTE : that was to read one pixel.
"I seek knowledge and to help those who also seek it"
duhroach
duhroach
Well if the read pixels function is so slow, what about
glCopyTexImage2D()?

~Main

==
Colt "MainRoach" McAnlis
Programmer
www.badheat.com/sinewave
DannerGL
DannerGL
quote:
Original post by duhroach
Well if the read pixels function is so slow, what about
glCopyTexImage2D()?

That depends on the hardware you''re using. Some hardware uses a tiling architecture for the depth buffer where the hardware can''t read from depth buffer for copys and reads. Other hardware can do it pretty efficiently.

XeroX2 is right about glReadPixels...It''s going to be pretty slow...how slow depends on the graphics accelerator you''re using.


zedzeek
zedzeek
>>Neveruse glReadPixels if you can avoid it (unless it not realtime). reason - Take a geforce2 mx give it a depth and color clear at about 500 X 400 pixel display size you get a few 100fps
add a glreadpixel command you get .1 fps, not saying this happens this bad for every one but it did happen for me. just a good thing to know about reading pixels, if its not realtime I guess its ok tho.

NOTE : that was to read one pixel. <<

youre doing something majorly wrong then
i can do 20million pixels a second on my gf2mx (in 16 bit), 12million(in 32bit)

this is for RGB data btw,

for depth data readpixels gives me 13.5million

http://uk.geocities.com/sloppyturds/kea/kea.html
http://uk.geocities.com/sloppyturds/gotterdammerung.html
duhroach
duhroach
Well, the reason I ask, is because i''m trying to impliment a HOM algo. Which requires things being rendered to the Depth Buffer, and then checked against the bounding box for things.

Now what if we put it in like a parallel process or something?

~Main

==
Colt "MainRoach" McAnlis
Programmer
www.badheat.com/sinewave
DannerGL
DannerGL
quote:
Original post by duhroach
Well, the reason I ask, is because i''m trying to impliment a HOM algo. Which requires things being rendered to the Depth Buffer, and then checked against the bounding box for things.

Look into using the NV_occlusion_query or HP_occlusion_test for this type of thing...these will probably be faster than using glReadPixels.

Keep in mind that anytime you have to get data from the API, it will inherently be slow: The hardware has to wait for all the rendering in the graphics pipe to complete, then it has to transfer data over the BUS to return it to your app.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.