scott <sco### [at] scottcom> wrote:
> Being able to store static meshes on the video card started with DirectX 7 
> and the GeForce 256, about a decade ago.

> In most modern games even non-static meshes are held permanently on the GPU. 
> The CPU simply tells the GPU some angles (or other parameters) each frame, 
> and a vertex shader running on the GPU suitably deforms the mesh prior to 
> rendering.  This greatly reduces the data bandwidth between the CPU and GPU 
> and allows huge numbers of animated meshes to be drawn in realtime that 
> otherwise wouldn't be possible.

> It also allows for clever things like real waves in water (not just normal 
> effects), whereby the GPU can distort the water mesh itself every frame and 
> not need to transfer the whole mesh from the CPU per frame.

> Ditto for terrain, even if the terrain itself does not need to distort, you 
> can smoothly fade between different LOD levels using just the GPU to avoid 
> having to send interpolated meshes per frame.

  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.

  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.

-- 
                                                          - Warp

Post a reply to this message