Laying down depth information

Im curious as to what others are doing

an ideal senerio would be would be able to blit the depth info from the framebuffer to another buffer (but since you cant do this with differing sizes its a no go, though u can stick the depth info in a texture and then draw that as any size u want, i.e. the same size argument seems a bit weak)

anyways I find the fastest method when I wanna lay down the same depth info in another texture/FB is to just redraw the whole scene again.
Is this what others have also experienced?

ta zed

Don’t worry, I’m listening to you, zed.
I do all my drawing to a fully equipped fbo, if that’s any help. The windows framebuffer is so 5 years ago.

Actually, I didn’t play with that.
But I can suppose, that if you have not very high-tesselated geometry, so, as you said, it might be more efficient to draw the whole scene again. Because alternatives are not very convenient - full-screen quad with depth-replace shader or full-screen point cloud, each pixel has it’s point, and accessing depth texture in vertex shader, recomposing output homogenous position.
I did the latter method, and it was 1.5X faster, than doing depth replace in fragment shader.

Don’t worry, I’m listening to you, zed.

and so you should, for my word is gospel

The windows framebuffer is so 5 years ago.

FBO + AA only came about a couple of years ago, not to mention that not all hardware supports it (btw ‘not to mention’ is a nonsense sentence.)
theres also the fact rendering to a FBO first + blitting to a screen is quite a bit slower IIRC >10% last time I checked, then just rendering to the framebuffer.

true using a FBO gives far more flexibility, but it does have some drawbacks

Because alternatives are not very convenient - full-screen quad with depth-replace shader or full-screen point cloud, each pixel has it’s point, and accessing depth texture in vertex shader, recomposing output homogenous position.
I did the latter method, and it was 1.5X faster, than doing depth replace in fragment shader.
sounds funky, so funky that I’ve no idea what youre talking about :slight_smile:

You’ve backed me into a corner, zed. I don’t like this corner. It smells of urine and despair. What will become of me?

Jackis, I too was left with a feeling of disorientation after reading your prose. Speak ye bullshit?

What Jackis meant about depth-replace:
draw a fullscreen quad with this frag shader:
void main(){ gl_FragDepth = texture2D(depthTex,coord).x; }

What Jackis meant about point-cloud:
draw 1280*720 points with this vert shader:
void main(){gl_Position= gl_Vertex; gl_Position.w = texture2D(depthTex,coord).x;}

Thanks, Ilian, you’re totally right - that’s what I’ve meant.
You helped knackered to understand my “bullshit”.

[EDIT]: Ilian, in my point’s vertex code I did a little bit more sophisticated math, because of DepthRange and because of perspective divisions. So I left W as 1, and recomputed Z as texRECT(depthMap,…)*2.0f-1.0f to make it in NDC unit post-projection cube.

draw 1280*720 points with this vert shader:
void main(){gl_Position= gl_Vertex; gl_Position.w = texture2D(depthTex,coord).x;}

I’m shocked if this is optimal, 1+million vertices
Though I do take your word for it.

zed,
me, I was shocked too, but that was the case - points were faster (not much, about 20-40%), than doing depth-replace in fragment shader. That was for 256*256 FBO. May be, for large screens it would be even slower, I didn’t test it actually.

Meh, my old 7600GT could dynamically generate a VBO with 1280x720x2 points, and draw 1280x720 lines at 100fps iirc, with blending enabled, VBO being transferred from a FBO via a PBO, and having the structure: “hvec2 pos; DWORD colorRGBA;”. It was only problematic when all lines were 50+ px long and/or very wide.
:slight_smile:

I’m using what I term a Quasi Monte Carlo Chicken Bone Simulation to construct a probability lattice for a hierarchical depth discarding predicate. The idea is to throw an assortment of virtual chicken bones whose shapes – largely described by cylinders and spheres – uniquely determine the outcome of the simulation but are not in feature completeness known a priori. A “roll of the bones” is then followed by a Minkowski sum of those bones falling within a predetermined volume of interest, principally the volume of the projected pixel under consideration. The volume of intersection of the Minkowski Bone and the probability lattice determines the likelihood that the depth test will fail, thus serving to predicate the depth fill semi deterministically with the desirable aperiodic property of NTMC. It’s a crap shoot, in so many words.

Good heavens modus, what happened to your nickname?

CatDog

Name’s Stan - Housewares.

modus… was a bit moded and I got a good deal on a new one.

ro revist this old exiting topic

heres my pipeline simplified

Im actually finding it much faster (~30%)
when I need to redraw the depth info (3x in the above picture) instead of first creating a depth texture + then blitting that later on,
to just say bugger it Ill redraw the whole depth info again, i.e. I redraw an extra ~500 meshes per frame since its cheaper than ‘quickly’ bliting the depth info again.

I find this crazy, perhaps others here are doing the ‘slow’ way without realising it

Interesting.
What’s the overdraw ratio for your typical scenes? If you have high overdraw, your approach must have been slower, then blitting depth somehow. But I wouldn’t count on it and I totally believe your experience on that.
By the way, how did you perform depth blitting?

Yeah, I would basically ask the same questions as Jackis… You say ~30% faster and ~500 additional draw calls but what about your depth complexity? How much geometry? What method exactly are you using for the blit (have you tried ARB_copy_buffer)? What hardware is this on, you’ve tried on different hw? What about depth formats?

Still, presumably your depth complexity is just over 1, poly counts not very high etc. Doesn’t make much sense (but then what about Jackis’ points! lol!), would suggest some poorly optimised function on the driver side.

Well, Madoc, that’s not LOL with points )) 2 years ago that was the only way to make some very specific task run quite fast. Yeah, it’s not elegant at all, but depth-replace was more costly.

I’m not denying that it was faster, that’s what I find funny. It seems completely absurd that drawing millions of points should be faster than very simple per fragment operations. It’s either funny or just plain scary.

Actually, I was speaking only about 256*256 viewport, and that’s only 64K points. May be, for larger resolutions it won’t be the case, as I’ve mentioned. But right now it doesn’t matter, because there are much more convenient way to blit depth ))
But okay, we’re still waiting for zed’s responses )

I havent tried ARB_copy_buffer, first time Ive seen it but from a quick look it seems to be only available on new hardware (+ new drivers cause it doesnt show up in my driver string), so thats out of the question.

Ill try a much simpler case in a couple of hours + report my results, IIRC theres quite a performance hit just from storing the depthbuffer in a FBO. but Ill get back to yous on that.