XNA Creators Club Online
Page 1 of 1 (5 items)
Sort Posts: Previous Next

Terrain Occlusion Culling

Last post 4/13/2007 3:42 PM by Michael Coles. 4 replies.
  • 4/13/2007 11:09 AM

    Terrain Occlusion Culling

    Does the XNA render pipeline have built in occlusion culling?  I'm running the multitextured terrain tutorial from Riemer's, no water though, and it's running pretty slowly.  One model, a sky box, and a map that's 600 by 600 "tiles", each 100 units square, and it's running at 14 FPS.  I wrote an occlusion method to test the bounding box of each tile against the camera frustum and make a new index buffer based on the included verts, and it actually ran slower.  I did notice that with none of my own routines though, the frame rate sped up when I was viewing less terrain, which makes me think it does in fact have built in occlusion. 

     So, does it support built in culling or do I need to write a better algorithm, and does anyone have any tips to speed it up a bit?

  • 4/13/2007 12:06 PM In reply to

    Re: Terrain Occlusion Culling

    Answer
    Reply Quote

    There is no built in culling in the low level XNA graphics API. I don't know about Riemer's tutorial.

    Creating new index buffers each frame is likely to be very slow: you generally don't want to be modifying GPU resources dynamically. The best way to do this kind of thing is to pre-sort your buffers into sectors, so you can just issue draw calls specifying different sub-regions of the existing index and vertex buffers depending on your culling results.

    XNA Framework Developer - blog - homepage
  • 4/13/2007 12:20 PM In reply to

    Re: Terrain Occlusion Culling

    On a further note, if you are checking 600x600 (360,000) AABB's against a frustum per frame, then expect a mighty CPU overhead. Try not doing so much work per frame ( i try not to go over 256x256 (65,536) checks per frame). Also a hierarchical partioning tree like Quadtree would help, effectively giving you an early out option for check the AABB's, instead of checking them all.
    Michael Coles
    Senior Programmer
    Digini Inc.
    http://www.blade3d.com
  • 4/13/2007 2:23 PM In reply to

    Re: Terrain Occlusion Culling

    In my experience, rebuilding vertex or index data is out of the question for large things such as terrain.  You just won't get the performance you want.  If you want to do dynamic LOD, one option is to construct pyramids of index buffers for each LOD, resulting in smaller geometry submissions for terrain tiles that are farther from the camera, at the expense of memory.  Personally, I am using brute force techniques and I may implement a per-tile occlusion culling scheme in the long term.
  • 4/13/2007 3:42 PM In reply to

    Re: Terrain Occlusion Culling

    Rebuilding buffers certainly isnt out of the question, you just have to do it effeciently. Look up Geometry Clip Map terrain. The implementation of thats reads in terrain data, and rebuild index buffers for a set of rectangluar clips (4 rectangles built up with triangle strips) each update.
    Michael Coles
    Senior Programmer
    Digini Inc.
    http://www.blade3d.com
Page 1 of 1 (5 items) Previous Next
var gDomain='m.webtrends.com'; var gDcsId='dcschd84w10000w4lw9hcqmsz_8n3x'; var gTrackEvents=1; var gFpc='WT_FPC'; /*<\/scr"+"ipt>");} /*]]>*/
DCSIMG