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.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   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.

Interesting theory! :-)

I'm kind of thinking it'll be cool when motion capture finally comes to the 
masses. When someone sends out a PDF you can print out, cut up, and tape to 
your clothes, and point a web cam at yourself...

Pretty much everything else is available for free at this point, at least in 
the video rendering path.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> clipka wrote:
> > That's some other strange association people have: RPG == fantasy.
> > SciFi-RGBs have proven this connotation to be wrong.
>          ^^^
>
> You know you've been ray-tracing too long when...

LOL - yeah, that has happened to me multiple times recently; to me, "RPG" is a
7-letter acronym: "RGB<backspace><backspace>PG" :P

Post a reply to this message

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