   Occlusion in Hardware
  As far as i know, the occlusion culling that we have now, are just querys. I know that sometimes a occlusion query is needed, but why don't hardware do a occlusin cullign directly in hardware withou querying information back?someting like this...glEnable ( GL_OCCLUSION );glBeginOcclusion();// Draw the Object Boundign BOxglEndOcclusion();// Draw th original meshglDisable ( GL_OCCLUSION );Well... with this... in the gl(Begin/End)Occlusion we define the geometry that will be occluded or not. If the this geometry is occluded AND the GL_OCCLUSION is enable we just ignore any draw command ( Before the vertices arrived in the vertex pipeline ).  We can ignora a whole "draw VBO command" this way.If the geometry is not occluded we render everything normally. The same occur if GL_OCCLUSION is disabled.And OpenGL can know if the object is occluded or not just setting a occluded flag to false in the end of the pixel pipeline. If a pixel is rendered, its not occluded.In the glBedinOcclusion() we set this flag to true.So anyone have any comment. I've been thinking in this, and seem a goos way of doing culling directly in hardware.   
  Nvidia hardware starting with the GeForce 6 can actually do this. They call it conditional rendering, and it either allows or prevents a draw command from rendering depending on the result of a previous occlusion query. You don't have to read back the query result -- it stays on the GPU. This functionality is implemented in Nvidia's OpenGL driver under the NVX_conditional_render extension, but unfortunately, they have not publicly released a spec. (However, it's not too hard to reverse-engineer if you feel up to it.)   ;  Such design will introduce the stall between getting results of the occlusion testing and decision making on whether to draw or not the actual geometry.These stalls are exactly the reason for introduction of "conditional" primitives to the latest hardware and pipelines.   ;Quote:Original post by illiyadaSuch design will introduce the stall between getting results of the occlusion testing and decision making on whether to draw or not the actual geometry.Well... i actually thought that because it do not return anything to the user... to prevent the stall waiting the informationg to get back...I was not aware of the NVX_conditional_render and i believed that it's exactaly what i thought. Actually it sounds that will be far more powerful and general.:);Quote:Quote:These stalls are exactly the reason for introduction of "conditional" primitives to the latest hardware and pipelines.I was not aware of the NVX_conditional_render and i believed that it's exactly what i thought. Actually it sounds that will be far more powerful and general.And so it is :)However, I was pointing out not to just NVX, but (in more general) to the 360 deferred rendering approach ("deferred" in the sense of captured/buffered-conditional-drawn and not in the sense of deferred lighting).   ;  why do u want this?the box will give false answers sometimestodays hardware unlike last century can easily handle 10,000s verts meshs, youre most likely better just laying down a depthpass (with occlusion query) u get perfect resultssidenote (from experimenting) with nvidia if u store your data as displaylists and send it the glCallList() command, and its not onscreen theres an early out on the driver. i remember the first time i saw this i got the result back >10 billion tris drawn a second and heres me, hello hello thats impossible my card only does ~120million max  :)   ;Quote:Original post by zedzeekwhy do u want this?the box will give false answers sometimestodays hardware unlike last century can easily handle 10,000s verts meshs, youre most likely better just laying down a depthpass (with occlusion query) u get perfect resultsA depth pass is utterly useless for object-level culling. 10,000 verts? Try 10,000,000. The Z-buffer isn't going to help you avoid vertex transformations.EDIT: Ah, didn't realize you were suggesting combining depth pass with occlusion query. Still, it's a pain in the butt to lay down 10,000 extra triangles every few frames just in case. Bounding boxes (or bounding box groups) are fast, and don't have to be especially conservative.[Edited by - Sneftel on December 10, 2005 2:32:07 AM];  true if your meshs have 10million verts than doing a boundingbox test first is prolly a good idea.but if theyre a more normal 10,000 its not cause A/ u will get wrong answers sometimes, thus u may needlessly change material state (eg shader/textures) which will affect performance to draw something thats not thereB/ even though occlusion test is fast it still uses filling power a bounding box will always fill more pixels than the actual geometry;  The conditional rendering, when implemented entirely in hardware, is essentially a free process - except the part where you draw the occlusion test geometry. However, drawing a box, a cone, a roughly-tessellated ellipsoid or some other primitive mesh to a z-buffer isn't exactly a very difficult thing to for even a slightly older card, much less a next-gen one. The "freeness" of the technique comes from the fact that it doesn't, in any way, interrupt the rendering pipeline when applied. This in contrast to the old way, where the user would download occlusion data from the card, thus effectively stalling any rendering that could otherwise be done during the waiting of the data.When taking into account all this, the conditional rendering implemented in hardware works very well for culling all geometry sets except the very simplest ones.The fillrate requirement of a drawing operation is almost directly proportional to the pixel shader complexity of that operation. Since drawing the proxy geometry need not actually calculate anything per-pixel except the z-buffer conditional, nor does it require any access the color buffer, it is a very cheap operation for the hardware.   ;  id say modern engine require a z fail pass on static geometry anyways, at least if you are working with very complex shaderssince static geometry is a lot faster to render than animated characters with > 30 bones and animation blending it would render a simple bbox for the character to see if its visible at all otherwise spare all the transformations and go on with the next objectalso if you have some sort of hierarchical culling you could render the z fail pass front to back and query the occlusion tests back to front for the leafs of the nodes to eliminate potential passes for lighting   