Getting vertices / faces after depth buffer test?
Author
I am looking for a way to retrieve all remaining and visible vertices or polygons (better both) after the depth test has been performed. What I require is the amount of vertices that are visible to the view with the current settings in form of vector data(and not as an image)
Is this possible at all with opengl?
No. You could use a hardware occlusion query, but that will only give you the number of pixels that got rendered. The depth test is performed during scan conversion, so there's no notion of vertices or faces.
What is it you're trying to achieve? I know there's a better way of doing it...
What is it you're trying to achieve? I know there's a better way of doing it...
Author
Oh great, let's see :)
I am working with models which are loaded during runtime. I need to figure the amount of vertices and polygon out which are visible to the user with the current modelview settings. So I need to check if the normals are facing towards the screen AND additionally I need to know if these vertices and polygons are visible to the user, since they may face towards the user but be occluded by other geometry.
This is required for a project, where I am creating thumbnails of arbitrary models with the highest possible entropy. Which means picking a model and view to get the most significant perspective of the model
I am working with models which are loaded during runtime. I need to figure the amount of vertices and polygon out which are visible to the user with the current modelview settings. So I need to check if the normals are facing towards the screen AND additionally I need to know if these vertices and polygons are visible to the user, since they may face towards the user but be occluded by other geometry.
This is required for a project, where I am creating thumbnails of arbitrary models with the highest possible entropy. Which means picking a model and view to get the most significant perspective of the model
As was said before, this can't be done in an easy way.
How is this:
1. Render the object normally with z-write enabled
2. enable GL_POLYGON_OFFSET_LINE with a small offset
(2 a) alternatively, glDepthFunc(GL_LEQUAL) should work too
3. start occlusion query
4. render the object again, with depth testing, and as wireframe
5. read occlusion query
This won't give you the number of faces or vertices, but it will give you a good figure of what you described. The z-test will cull away edges that are hidden by faces and leave only edges on the frontmost faces.
More visible faces mean more visible edges. Occlusion queries count pixels, but lines are made of pixels, so more visible lines will give more pixels.
Yes, some lines are longer than others, but on the average over a few thousand of them, it shouldn't matter.
A perspective with more visible faces (and thus edges) will have a greater number returned by the query.
If you really want to know the number of faces and execution time is secondary, you can of course do this:
1. Render with z-write enabled
2. enable z-test with GLLEQUAL
3. for each triangle:
- start occlusion query
- draw it
- read occlusion query
- if number of pixels > 0 increment counter
Note that this will be horrendously slow. You can remove some of the stalls by issuing a couple of queries at a time, but it will probably still be slow.
How is this:
1. Render the object normally with z-write enabled
2. enable GL_POLYGON_OFFSET_LINE with a small offset
(2 a) alternatively, glDepthFunc(GL_LEQUAL) should work too
3. start occlusion query
4. render the object again, with depth testing, and as wireframe
5. read occlusion query
This won't give you the number of faces or vertices, but it will give you a good figure of what you described. The z-test will cull away edges that are hidden by faces and leave only edges on the frontmost faces.
More visible faces mean more visible edges. Occlusion queries count pixels, but lines are made of pixels, so more visible lines will give more pixels.
Yes, some lines are longer than others, but on the average over a few thousand of them, it shouldn't matter.
A perspective with more visible faces (and thus edges) will have a greater number returned by the query.
If you really want to know the number of faces and execution time is secondary, you can of course do this:
1. Render with z-write enabled
2. enable z-test with GLLEQUAL
3. for each triangle:
- start occlusion query
- draw it
- read occlusion query
- if number of pixels > 0 increment counter
Note that this will be horrendously slow. You can remove some of the stalls by issuing a couple of queries at a time, but it will probably still be slow.
Author
Ok, thx so far. The first version you described can be also easily done by rendering the whole model white with a black background and then counting pixels :) This is already part of my testing suite but unfortunately the complex ones require some calculation and weightening. Maybe I have to create my owb z-buffer by processing this by hand ...
Thank you for your help
Thank you for your help
Quote:The first version you described can be also easily done by rendering the whole model white with a black background and then counting pixels
No, there is a difference. Counting pixels will give you a figure of the object's cross-section. Querying lines that are z-culled actually gives a figure of "how much edge" is visible.
But... stupid me... why did I say "lines" in the first place?! You can render points!
If you render your object as points, what will you get? One point for every vertex. If you run an occlusion query over that, you get a count of 1 for every pixel (have to make sure the point size is 1 of course).
Now, if you do a "normal" render pass to fill the z-buffer first, all the vertices that aren't visible will be culled, so the number returned by the query will be... (drums) the number of visible vertices!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
