pixels and triangles

Ummmm... Stupid question: why?

I mean, why not use a Z-buffer? (or whatever it''s called in OpenGL - I''m a D3DIM guy myself)

Z-buffers are surely much faster than any manual depth buffering methods, also they support intersecting triangles (they work on a per-pixel basis) which is near-impossible with manual depth buffering (unless you''re using your own rasterizer)

- JQ
pmjordan@gmx.at

lead programmer,
PWC Software

would the glGetPixel function do what you are wanting?

JoeMont001@aol.com www.polarisoft.n3.net

In all but truly obscene cases, it''d be quicker to just let all the triangles just fail the z-test than reading from the primary surface and causing a flush of the 3D pipeline.

As mentioned above, the hardware z-buffer will reject pixels that are already behind the visible pixels on the screen. This isn''t something you normally need to worry about.

no no no.., you guys didn''t get my point...
If you have 3000 polygons, the Zbuffer will sort them all, it will sort 3000 polygons, even if you have a big one the covers all of them in the screen!
What i''m tryng to do, is sort them from the nearest to the farthes, so that, if i have a poly than covers the screen going from 0,0,300,200, with z = 10, all the polys that would go to that screen zone and have a z greater than 10, will be clipped out, they won''t even go to the rendering pipeline!
I think it''s possible to do this, and get a really fast rendering algorithm.. i think
glgetpixel get''s the pixel from the screen. thanks, but, is there a way to know where a poly with world coordinates (10,10,10) would go in screen coordinates, before the poly is drawn????

thanks guys

Bruno

the depth buffer doesnt sort them , all it does is compare the z value of the pixel that u wanna draw with the one thats already in the buffer + if the test passes (from being closer whatever) it''ll overwrite the current pixel with the new one.

what u wanna do bruno is some sort of visability testing ( u have to do it yourself not the API (opengl), so youre gonna have to group/sort your world data have a look for occulsion culling/bsp/portal/quadtree etc

You''re not looking for a software z-buffer, that would be pointless timewise (if you''re already useing opengl)... you''re looking for a visibility algorithm, on a per polygon basis, not per pixel. you''d want instead to use the visibility data on a pre per frame basis, to choose what polys to send to the rasterizer (opengl in this case)

-mike

It''s not a stupid question at all. Far from it.
Besides there are no stupid questions at all (unless you ask whether bananas are straight in a 4D world.). Anyway,...

You should do a search on occlusion culling. What you''re trying to accomplish is very cool, but accesing the framebuffer and polling pixels isn''t the right way to do it. It will be very slow. Too slow . You will have to build your own secondary structure (C-buffer, beamtree, S-Buffer, Occlusion maps, etc.) to do occlusion.

Check out Flipcode. They have awesome documents about this stuff.

Goodluck,
And mail me if you have questions regarding occlusion culling, I experimented both with C-Buffers and beamtrees.

Jaap Suter

I guess most of you guys still didn''t understood what i want to do.., maybe it''s my english
I don''t need to sort anything, my polys are alreasy sorted trough a bsp tree....
I think you got the picture Jaap
I will look for what you sugested, if i ran out of luck, i will get in touch with you
Thanks anyway guys

Bruno