Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I'm currently working with upgrading and restructuring an OpenGL render engine. The engine is used for visualising large scenes of architectural data (buildings with interior), and the amount of objects can become rather large. As is the case with any building, there is a lot of occluded objects within walls, and you naturally only see the objects that are in the same room as you, or the exterior if you are on the outside. This leaves a large number of objects that should be occluded through occlusion culling and frustum culling.

At the same time there is a lot of repetative geometry that can be batched in renderbatches, and also a lot of objects that can be rendered with instanced rendering.

The way I see it, it can be difficult to combine renderbatching and culling in an optimal fashion. If you batch too many objects in the same VBO it's difficult to cull the objects on the CPU in order to skip rendering that batch. At the same time if you skip the culling on the cpu, a lot of objects will be processed by the GPU while they are not visible. If you skip batching copletely in order to more easily cull on the CPU, there will be an unwanted high amount of render calls.

I have done some research into existing techniques and theories as to how these problems are solved in modern graphics, but I have not been able to find any concrete solution. An idea a colleague and me came up with was restricting batches to objects relatively close to eachother e.g all chairs in a room or within a radius of n meeters. This could be simplified and optimized through use of oct-trees.

Does anyone have any pointers to techniques used for scene managment, culling, batching etc in state of the art modern graphics engines?

share|improve this question
4  
What I do to combine batching with culling is keep static vertex buffers and dynamic index buffers, and batch unculled objects into the index buffers. –  Jimmy Shelter Jun 21 '13 at 12:11
    
That's a good idea. I wont have much time to fiddle around with the work this weekend, but I'll be checking inn and looking for more tips if anyone steps up :) Thanks for the reply though, mh01! –  Kristian Skarseth Jun 21 '13 at 20:50
    
I'm going to quote a reply i got on gamedev.net forums in case anyone else stumble upon this thread and have a similiar question: "Hi, I recently presented an article at the GRAPP 2013 conference that deals with exactly this stuff - high level of occlusion AND high level of component replication: link /Mikael" Link to the forum thread –  Kristian Skarseth Jun 24 '13 at 9:58
add comment

1 Answer

The way I see it, it can be difficult to combine renderbatching and culling in an optimal fashion. If you batch too many objects in the same VBO it's difficult to cull the objects on the CPU in order to skip rendering that batch. At the same time if you skip the culling on the cpu, a lot of objects will be processed by the GPU while they are not visible. If you skip batching copletely in order to more easily cull on the CPU, there will be an unwanted high amount of render calls.

You would usually cull objects first. Only then do you walk your potentially visible set and build batches for rendering.

If culling your objects proves to be slow you could try grouping them into bounding volume hierarchies and cull those first.

share|improve this answer
    
I think we have a good design for our solution put together now. We'll indeed be performing culling and then building batches from the potentially visible objects. –  Kristian Skarseth Jun 24 '13 at 17:47
    
The objects will also be grouped in BVH. After research we have settled with kd-tree. –  Kristian Skarseth Jun 24 '13 at 19:41
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.