Darren New <dne### [at] sanrrcom> wrote:
> Patrick Elliott wrote:
> > Less to do with AI than with animation limitations. The more things you
> > have moving at the "best" rate, the harder your hardware needs to work.
>
> Is that really true? I thought the whole (visible) scene got pumped out to
> the graphics card on every frame. Hence the need for AGPx8 and such.

There is some stuff that - fortunately - does not need to be pumped around for
each frame. Traditionally, textures are such stuff. I bet static meshes are
another one these days: Applying the same transformation matrix to a wagonload
of vertices is no big deal for a GPU, and sufficient to have the object hover
around and maybe rotate.

One more reason to not animate stuff which is just barely visible.

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Patrick Elliott wrote:
>>> Less to do with AI than with animation limitations. The more things you 
>>> have moving at the "best" rate, the harder your hardware needs to work. 
> 
>> Is that really true? I thought the whole (visible) scene got pumped out to 
>> the graphics card on every frame. Hence the need for AGPx8 and such.
> 
>   It may have something to do with LODs: When the object is farther away,
> it usually will be switched to a version with less triangles. It might also
> be that in this case the lowest-resolution LOD models were not animated at
> all, and thus the effect you see.
> 
Exactly.

-- 
void main () {

     if version = "Vista" {
       call slow_by_half();
       call DRM_everything();
     }
     call functional_code();
   }
   else
     call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models, 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

> There is some stuff that - fortunately - does not need to be pumped around 
> for
> each frame. Traditionally, textures are such stuff. I bet static meshes 
> are
> another one these days: Applying the same transformation matrix to a 
> wagonload
> of vertices is no big deal for a GPU, and sufficient to have the object 
> hover
> around and maybe rotate.

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.

Post a reply to this message

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

>  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.

Graphics cards can store quite a lot of mesh and texture data on-board, the 
CPU algorithm just needs to carefully predict and spread out any big updates 
to avoid noticeable frame rate drops.  For example some common meshes like 
trees and grass might always be in the GPU memory, but some detailed 
versions of buildings might only be loaded when you get near to them, and 
the actual mesh load peformed over several frames.  The terrain is also 
typically sectioned up, and the LOD for each section is dtermined by a CPU 
algorithm and the GPU updated whenever necessary.  This way, *most* frames 
you will hardly be sending any data from the CPU to the GPU, and the frames 
where you do need to send mesh data you are only sending a very small amount 
that won't impact the rendering performance.

Of course if it all doesn't fit in normal CPU RAM the CPU algorithm must 
also manage reading from the disk in a similar way to be transparent.

It's certainly not trivial to implement a massive game environment.

Post a reply to this message

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

clipka <nomail@nomail> wrote:
> As the player normally can't move too fast, there's probably plenty of time to
> "swap in" scenery data by and by.

  I wouldn't say there's "plenty of time" because the CPU, the GPU the
I/O buses and the graphics bus have to do quite a lot of other things
at the same time, at 60 frames per second preferably.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> clipka <nomail@nomail> wrote:
> > As the player normally can't move too fast, there's probably plenty of time to
> > "swap in" scenery data by and by.
>
>   I wouldn't say there's "plenty of time" because the CPU, the GPU the
> I/O buses and the graphics bus have to do quite a lot of other things
> at the same time, at 60 frames per second preferably.

Let's look at it this way:

Traditionally, games have been organized in individual "maps"; Let's say such a
map would usually load within 30 seconds, and you'd spend at least 5 minutes in
there.

If the game layout was roughly one-dimensional (say, a FPS in the classic
corridor-type setting), a simple approach at hiding the loading times would be
to pre-load the data for the next map. That would gives you 300 seconds to
perform a 30-second loading operation. For two-dimensional games (vast
landscape to travel freely), the task of choosing which "maps" to load would be
less straightforward, but I guess it wouldn't significantly change the amount of
data to be provided, if the algorithm is designed smart enough.

So this takes 10% of your resources, right?

Wrong.

When it comes to moving data, by far the worst bottleneck in your computer
system is the hard disk. In classic games, while loading a new map the
processor is just as bored as the player, waiting for the disk hardware to
retrieve sector by sector. (Don't expect the stuff to be readily available in
the hard disk's tiny internal cache; so this will *not* push SATA to its
limits.)

So it takes 10% of your total *hard disk* bandwidth. Say, when was the last time
you played a computer game and your hard disk was constantly busy?

I guess that leaves us with, say, 1% of CPU and GPU bandwidth to be set aside
for preloading maps - at most. And it's a task that can be easily priorized:
There's no strict deadline to get the job done; for instance, in the heat of
the action it can safely be deferred until after the fight (all the more since
you usually don't move very far during a hot battle).

Post a reply to this message

> I guess that leaves us with, say, 1% of CPU and GPU bandwidth to be set 
> aside
> for preloading maps - at most. And it's a task that can be easily 
> priorized:
> There's no strict deadline to get the job done; for instance, in the heat 
> of
> the action it can safely be deferred until after the fight (all the more 
> since
> you usually don't move very far during a hot battle).

Especially if you keep a low-res (both mesh and texture) version available 
for the surrounding parts of the map anyway, if there is any slight delay 
with the high-res versions loading it's not going to ruin anything.  This 
happened in GTA San Andreas, if you (maybe with a little hack (-:) drove or 
flew really fast then you could actually see these low-res models for a 
second until the high res ones could be loaded.

Post a reply to this message

"scott" <sco### [at] scottcom> wrote:
> > I guess that leaves us with, say, 1% of CPU and GPU bandwidth to be set
> > aside
> > for preloading maps - at most. And it's a task that can be easily
> > priorized:
> > There's no strict deadline to get the job done; for instance, in the heat
> > of
> > the action it can safely be deferred until after the fight (all the more
> > since
> > you usually don't move very far during a hot battle).
>
> Especially if you keep a low-res (both mesh and texture) version available
> for the surrounding parts of the map anyway, if there is any slight delay
> with the high-res versions loading it's not going to ruin anything.  This
> happened in GTA San Andreas, if you (maybe with a little hack (-:) drove or
> flew really fast then you could actually see these low-res models for a
> second until the high res ones could be loaded.

No hack! It happened all the time to me on the PS2 version, usually when I was
letting off some steam or trying for stunt bonuses in the super-taxis. When you
came to an abrupt halt, the low-detail high-speed versions of buildings etc
could be visible for up to half a second, sometimes more. I couldn't comment on
how this reflects on my gameplay :-}

Post a reply to this message