Page 1 of 2 12 LastLast
Results 1 to 10 of 16

Thread: Removing unneeded polys

  1. #1
    Senior Member Regular Contributor
    Join Date
    Sep 2001
    Location
    macedon, ny
    Posts
    288

    Removing unneeded polys

    I understand backface culling just fine. My question is depth testing. Does opengl internaly not draw things that are behind others? Is that the purpose of depth testing or not? I am looking for an easy way to tell opengl not to draw that polys that are behind other polys, and thus wont be seen anyways. I kind of did things backwards. I have already designed a way to cull entire objects from my frustum with some plane tests, and I have designed a way to set a LOD from those tests. My problem is with my Map, I want to render my Map Fast and efficiently, so I first though about using one interleaved array for the entire map, but if opengl dosnt remove the faces behind one another, isnt this a HUGE performace hit? I have read about BSP trees and such, but those are a little out of my scope, and I have always though that the simple answer tends to be the best, and BSPs seem far to difficult, must be an easier way.?. If opengl dosnt remove the hidden faces, I have come up with another possiblity, please let me know if you think this idea will work. (Im not sure if this is the theory behind a BSP or not) My idea is this, create a Map for starters. Then create an index of each Plane normal within the map. Then create an index of each poly that lies on that particulare plane. Then after each time the camera is updated check to see which planes lie within my viewing frustum, then with those planes, check to see which of the polys per plain lye within my frustum, then simply only draw those planes? Only problem with this idea is that is seems quite intensive, I mean, image a map of an apartment building, there could be 1000 planes, with an average of 50 polys per plane. Now say we check 1000 planes to see if there inside the frustum, then say ther is 30 planes inside the frustum, we then check 1500 polys. Or maybe I should simply cut out the poly check, and just render the all the polys in those planes, and save some CPU cycles, and let the video card handle a "little" extra data. Anyone have any ideas?? Or getting back to my original question, will opengl simply not draw things that are behind others?? please help.. Thanks.

  2. #2
    Senior Member Regular Contributor
    Join Date
    Jul 2001
    Posts
    442

    Re: Removing unneeded polys

    That is what the Z buffer is for. It is a non-trivial problem to clip background polygons against foreground polygons in order *not* to render them at all. There are quick visibility tests you can perform on groups of polygons (but not in a `polygon soup' application). The Z buffer will sort out all depth problems for you.

  3. #3
    Senior Member Regular Contributor
    Join Date
    Sep 2001
    Location
    macedon, ny
    Posts
    288

    Re: Removing unneeded polys

    So if I stay with my frustum culling for lets say objects, and characters, and let OpenGL's depth test handle my map Data, things will run smoothly? Figuring on a quake 3 level of detail map? Not a horendous amount of polys, but a fair amount. The reason I would like to stick with the frustum culling for the others, is that i think there is no sense having opengl test all those polys just to see if there visable, if thats how it works. So thank you very much. If I have missunderstood this at all, please let me know. Thanks.

  4. #4
    Senior Member OpenGL Pro
    Join Date
    Oct 2000
    Location
    Fargo, ND
    Posts
    1,753

    Re: Removing unneeded polys

    Sorry, I got lost in your original post, but I think I get the general gist of it. (Paragraphs might have made it a bit more readable.)

    The way depth testing works is basically like so...

    When you draw a polygon, it test against the depth buffer, and depending on what your depth function is, it will decided to draw or not to draw.

    So say you have drawn polygon 1, and your depth function is GL_LESS (the defalt). Assuming nothing else has been draw, polygon 1 is drawn, and it's depth is written into the depth buffer.

    Now you try to draw polygon 2, which is completely behind polygon 1. Since polygon 2 is behind polygon 1, the depth will be greater than what is currently in the depth buffer, and the depth test will fail, so it won't be drawn.

    Now if you were to draw polygon 2 first, it would get drawn, and then when you draw polygon 1, it would simply draw over polygon 2 because the depth test would succeed in both cases.
    Deiussum
    Software Engineer and OpenGL enthusiast

  5. #5
    Senior Member Regular Contributor
    Join Date
    Sep 2001
    Location
    macedon, ny
    Posts
    288

    Re: Removing unneeded polys

    Well, i guess that would be faster than attempting to write my own algorithm to do that. Only way I could think of to make this method faster would be to first find the closest say "20" planes, and render those first. Then attempt the rest, which most, would fail, unless the 20 planes we started with were all close to the ground, leavin far open spaces to be seen. (Explained badly, but i hope you get the gist) But in doing so, that would require me to break the map up into alot of chuncks, like a couple polys per plane. So think it would be much faster just to leave the Map in an interleaved array, and let the depth buffer do its thing. Also might help with multitexturing (if i use CVAs) that way opengl already knows what is where, so it dosnt have to do the calculations twice.

  6. #6
    Member Newbie
    Join Date
    May 2002
    Posts
    49

    Re: Removing unneeded polys

    Originally posted by dabeav:
    So if I stay with my frustum culling for lets say objects, and characters, and let OpenGL's depth test handle my map Data, things will run smoothly?
    Umm, no

    Depth testing has nothing to do with speed (well almost, it saves some memory bandwidth), just with image correctness. You still send geometry to the card, this geometry is still lit, rasterized, textured etc, and then some pixels fail the depth test and don't get written to the frame buffer.

    Speaking of Q3 maps, a GF4 easily handles ALL the leaf faces of q3dm11.bsp when put in one vertex array and drawn with a single glDrawElements (GL_POLYGON), 70+ fps. And that's without CVA or VAR. On the other hand, with BSP and glBegin/glEnd of the same data the frame rate drops to 20 . And on the third hand, BSP + PVS culling + state sorting + vertex arrays easily makes 200+ fps.

    All this is to say the culling performed by the CPU is usually beneficial.

    Regards,
    -velco

  7. #7
    Member Contributor
    Join Date
    Apr 2002
    Location
    Spain
    Posts
    63

    Re: Removing unneeded polys

    Originally posted by velco:
    Umm, no

    Depth testing has nothing to do with speed (well almost, it saves some memory bandwidth), just with image correctness. You still send geometry to the card, this geometry is still lit, rasterized, textured etc, and
    I don't think so:

    First. If you cull all the polygons outside the frustrum, you save all the depth-testing that you would have to do otherwise with these "extra" polygons.

    Second. Depth test goes before texturing and ligtning. There is no need to waste time doing calculations of fragments that never will be seen.

    Third. By using frustum culling, you haven't got to send occluded polygons to the card, so you save bandwith, too. Is not the same to render 3,000 polys than 30,000. Although a GF4 can render a Quake3 level at 70fps, it is a waste of power. In fact, Quake 3 doesn't need a GF4 becasue it selects the polys that it has to render before sending them to the graphics pipeline. That was the reason that allowed me to play Quake 3 with a Banshee .

    [This message has been edited by Azdo (edited 06-20-2002).]

  8. #8
    Member Contributor
    Join Date
    Jun 2002
    Location
    Alamogordo, NM USA
    Posts
    67

    Re: Removing unneeded polys

    As an added point, if you are truly concerned about sending data down and not using it. The new NVidia extension allow, as I understand it, a test if any Z-writes were made during a section (so you can find out if the entire object was occluded).

    Occlusion testing helps too, but the Z-buffering definately helps better than coding it yourself. If you do your own occlusion test, make sure it is on higher order objects so that the time you spend in the test, is made up for in tris not sent. However, we still send it all down now, and get good frame rates.
    Japanese Proverb: "Talk about things of tomorrow and the mice in the ceiling laugh."

  9. #9
    Member Newbie
    Join Date
    May 2002
    Posts
    49

    Re: Removing unneeded polys

    Originally posted by Azdo:
    I don't think so:

    First. If you cull all the polygons outside the frustrum, you save all the depth-testing that you would have to do otherwise with these "extra" polygons.
    Yes. And you save much more that the depth testing - transformations, lighting calculations, rasterization, texturing.


    Second. Depth test goes before texturing and ligtning. There is no need to waste time doing calculations of fragments that never will be seen.
    This is not true.

    Please, read the OpenGL 1.3 spec, page 10, section "2.4 Basic GL operation".


    Third. By using frustum culling, you haven't got to send occluded polygons to the card, so you save bandwith, too. Is not the same to render 3,000 polys than 30,000. Although a GF4 can render a Quake3 level at 70fps, it is a waste of power. In fact, Quake 3 doesn't need a GF4 becasue it selects the polys that it has to render before sending them to the graphics pipeline. That was the reason that allowed me to play Quake 3 with a Banshee .
    My point exactly. Even on a relatively high end card (4400), some operations performed by the CPU can improve the frame rate - it is not "the GPU can do anything better/faster".

    Regards,
    -velco

  10. #10
    Senior Member Regular Contributor
    Join Date
    Nov 2000
    Location
    Sydney, NSW, Australia
    Posts
    426

    Re: Removing unneeded polys

    Just to clarify: Depth Sorting is a per pixel calculation, not a per polygon calculation. It checks the depth values of separate pixels, and depending on the z value, draws one pixel instead of another.
    BSP trees as far as i know allow you to disable depth sorting because the BSP trees allow you to straight away draw the polygons in the right order, as in the furthest polygons first, and the closest last. This offers a speed increase because depth sorting OpenGL style is pretty slow...
    :: Sleep is a poor substitute for caffeine ::

Page 1 of 2 12 LastLast

Similar Threads

  1. glDrawArrays draws unneeded points
    By hockeyman in forum OpenGL: Basic Coding
    Replies: 1
    Last Post: 07-09-2012, 02:51 AM
  2. Removing llvmpipe
    By AndrewMiles in forum OpenGL: User Software
    Replies: 2
    Last Post: 02-26-2012, 10:49 AM
  3. Removing drawPolygon
    By in forum OpenGL: Basic Coding
    Replies: 2
    Last Post: 11-15-2004, 02:12 PM
  4. removing demo
    By in forum OpenGL: User Software
    Replies: 1
    Last Post: 01-27-2003, 07:32 AM
  5. Removing color
    By wire in forum OpenGL: Basic Coding
    Replies: 2
    Last Post: 11-18-2000, 03:01 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Proudly hosted by Digital Ocean