can't really access the data linearly as state caching is more important than culling. Looking at that link you give me now though, thanks for sharing

This doesn't make sense to me -- the culling data is positions/bounds, which aren't render-states. Storing positions/bounds in a linear array should have no impact on your render state caching/sorting.

I've just recently come across this question myself so I thought I'll just add to this thread instead of creating a new one.

I'm actually more interested in the higher level design of managing a scene and incorporating multiple culling techniques rather then implementation details of said techniques. To be more specific here's a number of questions:

1) Is there such thing as a scene manager these days? If so, what is its purpose exactly? Does it manage a group of spatial views and automagically determine which one an object gets inserted into?
2) When and who determines what culling technique are applied to objects? (Eg. static vs. dynamic objects)

[quote name='Xcrypt' timestamp='1338340402' post='4944509']
I'm not an expert on the matter, but from what I have read in recent articles, scene graphs are a no-go today. I would like some enlightenment on the topic too.

Scenegraphs themselves can be useful, but having them heavily tied into other systems is a no-go. All the scenegraph should be responsible for is concatenation of transforms - and thats a distinct process that can be done in isolation before culling even begins.
[/quote]
Not to confuse the issue or nitpick, but what you are describing is a hierarchical tree and not a graph. A hierarchical tree generally has only one meaningful way to traverse, (that is from top-down) and can therefor only be optimized for a single purpose.

A scene graph in the traditional sense is a multipurpose database that can be traversed in many different ways to visit nodes in different optimal orders for different purposes. The thing about "scenegraph" is that it has turned into a blanket term that gets thrown around and misrepresented. If you're just storing a tree to do transforms to/from world space, then you don't have a scene graph so don't even call it that.

They are not an obsolete concept and they did not die out with the fixed function pipeline, as I think is a commonly held belief. They are just as applicable today as they ever were, they just didn't turn out to be all that useful in practice and are really more trouble than they are worth.

On the other hand, if you were to embed an existing graph database and actually squeeze some good real-time performance out of it, you'd have a potentially very powerful tool at your disposal. I just don't see the need, it's overkill in most cases.