Frustum culling - best practices?

[WIld Sage]

I want to implement frustum culling into my game engine, and I'm not quite sure how to go about doing it. A few questions:

1) How do I get a frustum that matches my current view, and test spheres against it? (not bothering with boxes, I don't need to be that precise)

2) Would it be best to send all my geometry to the graphics memory when the area loads, then only call a draw on what passes the frustum test, or should I dynamically load/unload geometry to/from graphics memory?

3) related to #1, how can I create a frustum using an arbitrary set of points, so I can implement portal culling?

and 4), while I'm here, what's a good outdoor culling method that works well with portal culling indoors?

[Aleksandar]

1) Search the net for the "Radar approach". It's the fastest method I know about.

2) If it is possible to hold all objects in graphics memory, it is certainly the fastest method to draw. But probably you'll need some kind of content management to deal with LOD and emerging objects.

3) You can modify 1) approach, but it raises the cost of culling. The culling is effective only if it is faster then drawing. In any case, you can try and measure the speed.

[WIld Sage]

Well eventually the method will be used to navigate a literally infinitely large world, so yes, culling will *always* be faster than drawing lol.

The real trick is, I want my game to be able to run well on both older and newer hardware, and I know that on most older cards, graphics memory is a premium. Even the 1gb my card has probably wouldn't hold *everything* I'd want at once.

[Aleksandar]

Why did you ask that when you already know the answer? :)
You definitely need some kind of scene management.

[WIld Sage]

Yes, I suppose scene management would be the crux of it lol. Do you know of any tutorials I could look at to get started with that? I was also looking into SceniX - would it be appropriate for what I need? (portal culling + infinite seamless world are not negotiable)