Warp <war### [at] tagpovrayorg> wrote:
>   Deciding what to render and what not (iow. hidden surface/object removal)
> has to still be done with the CPU, though. Too complicated for a GPU to do,
> as it requires rather extensive and complicated code using lots of complex
> data structures.

This is moving more and more towards "hidden object removal"; a decade ago, in
an FPS like Unreal Tournament there would be a single data structure per level
representing all the static stuff, from the general room layout to the smallest
ducts & decorations, with some smart geometry tree like BSP to handle hidden
surface stuff; only the moving actors would exist as "independent" meshes, out
of pure necessity.

When I looked again a few years ago, the classic level structure had been
reduced to the basic room layout, and all the details - ducts and stuff - were
modelled as independent objects.

I conjecture that developers have been shifting more and more of the hidden
stuff removal workload to the GPU, to free the CPU for other tasks. With the
added benefit of having less traffic between CPU and GPU. So the CPU just does
a comparatively rough pre-selection of which objects *may* be visible, and the
rest is left up to Z-buffering and brute force.

>   Also, I'm wondering that nowadays there are many games with ginormous
> amounts of scenery (such as eg. Oblivion, Fallout 3 and Far Cry 2). I doubt
> all that scenery would fit in RAM at once, much less in the graphics card.
> The scenery is being loaded on-the-fly as the player advances in the terrain
> (in the latter two example games mentioned, this is done transparently,
> without any "loading" messages or delays). Naturally all this scenery needs
> to be transferred to the GPU.

As the player normally can't move too fast, there's probably plenty of time to
"swap in" scenery data by and by.

Post a reply to this message