Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 1 of 3 123 LastLast
Results 1 to 10 of 27

Thread: Drawing & culling BSP geometry

  1. #1
    Member Regular Contributor
    Join Date
    Sep 2002
    Posts
    365

    Drawing & culling BSP geometry

    BSP geometry, like the brush objects in Unreal and Half-Life, tends to be the slowest thing to render in my engine, because it is all unique, non-instanced geometry.

    I'm attempting to speed the rendering up, but I'm not sure what I can do. The engine collapses faces with like textures into single arrays, so each texture has one large mesh all faces with that texture get collapsed into. Additionally, the engine splits the faces up by portalzones, so each portalzone has its own list of collapsed faces.

    It seems like the number of texture switches is what really slows it down. In other words, the polycount doesn't matter so much, but the number of collapsed arrays I render, each with a different texture, makes a huge difference.

    Are there any more tricks I can use to speed this up? I'm already using texture compression. Is it slow to redundantly bind a texture? I mean, if I re-bind the same texture, will OpenGL detect that I'm not really switching textures, or does it reload the texture anyways?

    Would it possibly be faster if I batched the faces without collapsing them, so I would set up a texture, draw all the faces with that texture, and use a fast BSP culling to skip some faces? Is starting and stopping your drawing a big issue in OpenGL?


  2. #2
    Advanced Member Frequent Contributor
    Join Date
    Feb 2006
    Location
    Sweden
    Posts
    744

    Re: Drawing & culling BSP geometry

    1. texture compression is slower than uncompressed.
    2. Yes texture binds are always bad, so keep them to an absolute minimum and render objects depending on which texture they have, not on a per object basis.
    3. use large texture atlases on some objects instead of many small ones, that could probably remove a few unnecessary texture binds.

  3. #3
    Senior Member OpenGL Guru
    Join Date
    Mar 2001
    Posts
    3,576

    Re: Drawing & culling BSP geometry

    texture compression is slower than uncompressed.
    No it isn't.

    Compressing a texture is slow, but if it's precompressed, it's often faster than using an uncompressed one.

  4. #4
    Member Regular Contributor
    Join Date
    Sep 2002
    Posts
    365

    Re: Drawing & culling BSP geometry

    I imagine texture compression would make things faster, since it would have to transfer less memory.

    There are three ways I can render BSP geometry:

    1. Collapsed vertex arrays and a single indice array.

    2. Collapsed vertex arrays and a start and stop indice for each face, for use with glDrawArrays().

    3. Individual vertex and indice arrays.


    The first method is fastest, but it can't really be culled, you just throw everything at the graphics card in one chunk.

    The second two methods can be optimized with culling, but are slower to draw. #3 is very slow, while I was surprised to see that #2 is about 90% as fast #1.

    At this point, I am thinking that a fast BSP-based culling routine combined with #2 might be the fastest. Of course, for major culling I am using portals, but I need additional culling in the large outside world, which isn't split into portalzones. I don't think VBOs or CVAs would do any good here, but do they do anything for unique geometry?

    Where's the make_vertex_array_twice_as_fast extension?

  5. #5
    Member Regular Contributor
    Join Date
    Mar 2005
    Posts
    301

    Re: Drawing & culling BSP geometry

    I may be wrong but...
    Assuming geometry isn't very, very large, and it's static (seems likely as BSP is mentioned), VBO could indeed help. Upload geometry to one or more VBO's, keeping in mind the 64K-vertices (unsigned short index) limit on many(/most/all?) implementations to stay on the fast path. Partition as required to allow index-batching. Then just stream the indices.

    As VBO's are really just vectors/arrays of vertex attributes stored in memory on the server (the gfx card), instead of sending up to 64K vertex attributes (assuming just xyz, s/t and normal that's 32bytes/vertex = 2MB/VBO for 64K vertices) you just send one or a few instructions to swap VBO. While 2MB may not seem much out-of-context, putting it into context of fps or just latency (especially as such an uploads likely are not written in a single batch) the delays can add up.

    To optimize this further, use two or more VBO's for indices and alternate between them, to allow the card to do its thing using one index array while you are filling another one with new indices.

    Anyway, I believe the most performance efficient way to do this is to only upload new VBO data when actually needed, and for BSP I'd guess keeping the vertex data "cached" in VBO's and only upload new indices is the optimal for overall performance.

    Also keep in mind that rebasing indices on the CPU to allow batching is often way faster than submitting it as separate batches.

  6. #6
    Advanced Member Frequent Contributor
    Join Date
    Feb 2006
    Location
    Sweden
    Posts
    744

    Re: Drawing & culling BSP geometry

    Originally posted by Korval:
    texture compression is slower than uncompressed.
    No it isn't.

    Compressing a texture is slow, but if it's precompressed, it's often faster than using an uncompressed one.
    No, compression is always slower, since it always means you have to process the data somewhat extra.
    The difference might not be that great, but compressed textures are never faster unless your memory bandwidth limited and you somehow only sample within the compressed blocks and not across them.

    On to the subject.

    Unless you have a really old graphics card you will be fill rate limited and not vertex transform limited, this means that polygons are basically free and polygon culling doesn't help that much.
    Especially if you have early z culling.

    Now, what you need is simple zone culling, use #1 ( VBO), but split it up into smaller parts (maybe into cubes of 50m x 50m x 50m, or individual buildings for themselves) and do some macro culling instead of the fine culling you are proposing.

  7. #7
    Senior Member OpenGL Guru knackered's Avatar
    Join Date
    Aug 2001
    Location
    UK
    Posts
    2,833

    Re: Drawing & culling BSP geometry

    Bollocks, more of a compressed texture fits in the texture cache therefore reducing the number of cache fills therefore being faster.
    Knackered

  8. #8
    Member Regular Contributor
    Join Date
    Sep 2002
    Posts
    365

    Re: Drawing & culling BSP geometry

    Regarding VBO's, for batched/instanced geometry, I find VBO's to be an order of magnitude faster. I just set up my arrays, then draw every instance of the mesh.

    For static geometry that only gets drawn once, because it is all unique, are you sure VBOs would make it faster? Can anyone else comment on this?

    I'm already doing macro culling, I'm just getting obsessive and seeing if there is anything more I can do to make it crazy-fast.

  9. #9
    Advanced Member Frequent Contributor
    Join Date
    Feb 2006
    Location
    Sweden
    Posts
    744

    Re: Drawing & culling BSP geometry

    Originally posted by halo:

    For static geometry that only gets drawn once, because it is all unique, are you sure VBOs would make it faster? Can anyone else comment on this?

    I'm already doing macro culling, I'm just getting obsessive and seeing if there is anything more I can do to make it crazy-fast.
    VBO's is THE!!! (i just don't know how more clear this could be) fastest method currently, especially for static objects.
    The only case where VBO does not have such a clear advantage is when you have to build a new object for every frame, but even then there is an advantage.
    I for one upload new stencil shadow volumes to a vbo several times a frame and object and i still manage to squeeze out a few more FPS compared to immediate mode, and i could probably get a few more once i check if either the object or the light has moved.

  10. #10
    Senior Member OpenGL Pro Zengar's Avatar
    Join Date
    Sep 2001
    Location
    Germany
    Posts
    1,932

    Re: Drawing & culling BSP geometry

    zeoverlord, compressed textures are faster then uncompressed ones. The DXT decompression is very cheap

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •