Hello,

Currently, I am working on some kind of basic 3d Game, I would rather call it a 3D-Test.
I want to disply animations, but I want this to be done fast (shure).
In the OpenGL Tutorials on GPWiki (which are very nice), animations get displayed by uploading
each frame at run-time to the Graphics Card. But this seems a bit to slow, because
there is too much data being transfered. But now the Question:
Should I upload every frame of the animation as a single model or is there
not enough Graphics Card RAM for this?
I hope you know how to do this.

avrrobot

I am the next week not at home, so I wont answer any Questions etc. that are postet here.

_________________
Hope you dont mind spelling mistakes.
Greetings from Germany.

Hello avrrobot,



Consider an animation like a flip book ( https://en.wikipedia.org/wiki/Flip_book ). In some circumstances, you know what each image will be made up of (a movie), however its typical for games to have no idea what each frame will consist of, so you create the "next image" on the flip book on demand. There is no way around this.



The information you send to the graphics card is a description of the image you currently wish to draw. Your graphics card is an Artist, but without eyes, so the messages you send him describe in mathmatical words the details to draw one frame.

What you can do, and is encouraged, is each frame may share common details between other frames, you can record these details, and send them to the Artist to remember, and reference these details at any point, inserting them into your current frame.

cxzuk

I was thinking that he is asking about 3d models.
I havent quite touched the topic a lot, but you usually want skeletal based animation systems. They're more complex to set up but easier to use in the long term.

Apart from that you'd be fine with nowadays hardware if your models aren't too(ooooo) detailed.

_________________
Long pork is people!

wzl's burrow

hm, I guess some more details on animations wouldn't hurt.

While you transmit details of what you'd like your graphics card to draw, you must first generate these details. Its important to be clear that your graphics card does not animate. It does not manipulate any models, it can only draw.

An object (or subsystem) must hold the responsibility to update these details. If your looking for the "fastest" way, you have two choices, Compute or Store this information, which is specific to your application. You can not decide (accurately) before your project is finished which is best. (https://en.wikipedia.org/wiki/Premature ... o_optimize)

There are practises that can help you easily choose between Computing and Storing information (optimise) by limiting change and not disgusting between the two cases.

1. https://en.wikipedia.org/wiki/Command-query_separation
2. https://en.wikipedia.org/wiki/Uniform_access_principle

Hows that?
cxzuk

If we're talking about the MD2 demo, the animations are very large, the whole set of vertex position data gets updated every frame. The demo does use old OpenGL techniques, but I'm not sure how they could be improved by using vertex buffers due to the volume of data the changes each frame. MD2 wasn't designed top work with modern hardware or APIs.

Weezl is right about skeletal animation, the 'chunks' of the object don't change (so they can happily live on the card's buffers), they are just translated relative to each other to create the animation poses.

You can also interpolate skeletal animation to achieve smoother movement or slow motion effects, something that MD2 doesn't handle very well.

_________________
10 PRINT "Bad Monkey ";
20 GOTO 10

i guess you could create one VBO for every keyframe. i'm not sure about the datasize of a model with an average polycount (i guess it is around 20-50k in modern games?), but i'd guess it adds up rather quickly with the amount of animations you need for all the different actions.

I mean back in quake2 they had like a walking animation, shooting, and dying, with models that are of fairly low quality (poly-wise). nowadays you're expected to do strafing, jumping, reloading, all that jazz.

_________________
Long pork is people!

wzl's burrow

Even if you ignore the animation overheads, MD2 has awful texture mapping. The texture wobbles around all over the mesh. You could get away with it at 640x480, but its not suitable for today's resolutions.

_________________
10 PRINT "Bad Monkey ";
20 GOTO 10

Ah right I see.

In order to optimise, you need to work on objects individually, which is the opposite to generalisation. You can not "optimise" a MD2 demo, because one size does not fit all.

With display lists and VBOs, I think it important to keep clear that the Entity system is not part of the rendering system. If the vertex position data does not update often, then a buffer (Storing) is suitable, but if they do, your better of Computing the new data. - The key point here is that your Entity data would not access rendering primitives, VBOs, display lists etc, You can profile this interaction, and determine the benefits (can we cut down communication between these objects?) and place VBOs on the rendering client end.

I thought skeletal animation was when data (bones) was used to calculate the movement of vertex data, affecting user defined areas, and not "chunks" of polygons which can be transformed around a bone? Or is skeletal animation referred to a technique?

cxzuk

Each bone has a matrix asociated with it and a parent bone. your vertices are weighted against those matrices, how much they will be manipulated by them. You'll have to define they vertex weights in your modelling tool, which are then stored in the model format.

The whole matrix stacking and calculation of the final position for every vertex can be quite tricky to implement, but there are a number of libraries that will help you with this.

_________________
Long pork is people!

wzl's burrow

especially if you take into account local and global, and relative transformations, and the order specific-ness of matrix multiplication.

I wrote my own :thumbs not a good idea :doh but it works :rock

_________________
It's not truly yours, until you void the warranty.
Most of my problems: "I can fix that! ... oops".

Ok good, I was under the impression from codedreams definition it was suggested to be like this guy, http://www.freakingnews.com/images/app_ ... en-man.jpg

with each bit of wood as a VBO or Display List.

cxzuk

haha, that works too. see minecraft

you'll have seams and ugly edges going on though, also an increase in drawcalls. not really decent to use imo

_________________
Long pork is people!

wzl's burrow

At first, I thought about precalculated skeletal Animations for characters to maybe 5k Polys.
So there is enough RAM to upload 50 frames to the Graphics Card ?!?
I hope so

avrrobot

_________________
Hope you dont mind spelling mistakes.
Greetings from Germany.

you can do the calculations yourself

one float is 4byte
one vertexposition is 3 floats > 12 bytes

you also need uv coordinates u+v > 8 bytes

lets just assume for simplicity that you don't need normals

so 20bytes per vertex, 3 per polygon > 60 per polygon
5000 unique polygons * 60byte equal around 300kb.

by 50 frames total in around 15mb if i didn't forget something

EDIT: of course i forgot the index elements
so add another 4*3*5000*50 on top of that

_________________
Long pork is people!

wzl's burrow

My tests were like that. You can get away with hard joints when you're doing giant robots. The theory is the same, you just render the body parts in place of the 'bones' rather than deform a single mesh.

_________________
10 PRINT "Bad Monkey ";
20 GOTO 10