Hi,

I'm trying to make some well-animated .mdl models to use with gamestudio but I've already run through the problem of having very deformed animations because of using too few keyframes for my animations.

I'd like to ask for the help of people who are experienced in animation using 3DGS to share their experience with the number of frames per animation needed to create realistic and non-deformed simple animations, like running, jumping or rolling. Do you use just 4 frames for an animation like running? Or this count can go all the way to 20 or the like?

What about the total number of frames in a model? Can this count be above 100 or even more? When does the number of frames start getting heavy for the engine to handle?

Any experience sharing or advice would be very helpful!

Thanks!

depends on the animation, complexity of the model, and how much video memory your willing to use up for the model ( every animation frame takes up memory)

any animation that requires a 'rotation' like motion ( like a wheel or rotating an character limb around a joint) will usualy take more frames because vertexs can only be 'rotated' less than 30 degrees between frames, else the mesh deforms.

soem animation examples:

a pistol being fired: you could possibly do this in as little as 2 frames, for an automatic pistol

engine piston: the piston itself would need only 2 frames, but with a connecting rod motion included at least 4, add the crank shaft and you would need 12+ frames

an human arm. starting at hanging from the side to straight above the head.

Natural motion is most people rotate the elbow 90 degrees first when raising the arm,
then the upper arm rotates(around the shoulder about 110 degrees (depending on flexability),
then the upper arms contiues to rotate to 180 while the lower arm unrotates back.

so add that up its about 4+ , 4+ ,4+
so at least 12 or more frames

I thought that frames of animation used normal system memory and not video memory. Normally, it's the textures that use video memory. The limit isn't exactly known, but there have been some users who have 300+ total frames of animation. The more frames you use, the smoother the animations are, but the more memory and disk space is needed.

mm im not sure about it with some of the changes with how models are handled now. They use to be stored in video memory

If only I had a way to check how much video memory is actually used, I could test it. To find out if it does or not, just create some high-poly model and texture it. The first test would be unanimated. Load this into some test level and check the video memory usage. Next, make a few small modifications to it for a test animation and load this into the same level completely unmodified except this model. Check the video memory usage then. If the animated version takes more video memory than the nonanimated version, then vertices and things are stored in video memory. If the difference is only miniscule or unchanged, then vertex information is stored in system memory instead of video memory. It's the best way to find out.

or ask conitec they would know how the aniamtion frames are stored

I've made some tests using a model with 300 frames and nvidia's nvperfkit to check video memory usage and what I've found out is that there doesn't seem to be any video memory consumption change using a 300 frames model or a single-framed model.

The noticeable difference, though, is the size of the nexus that appears when you press F11. My model, which has 4402 faces, increased a little more than 100kb in the nexus when having only 1 frame, and about 34Mb when having 300 frames, which seems to be correct, since supposedly all the vertices are being stored for all the 300 frames.

So, my conclusion for now is that the frames are stored only in normal memory, though I'm still going to ask conitec so I can be 100% sure.

Oh, and thanks for the tip about how not to deform my models when they rotate during animation! The 30-degrees rule is quite useful!

For each additional frame in your model, you'll need this much disk space (assuming vertex animation):

filesize_from_frames = vertex_count*12*frame_count;

If you have 1000 vertices in your model, a typical average for today's mid-range models (which equates to about 1950 triangles), each frame would need 12000 bytes to store. For 300 frames, that's 3,600,000. 4402 faces is about 2300 vertices (given the typical 1.95:1 face:vertex ratio for a closed mesh), that's 27600 bytes per frame or 8,280,000 bytes. The model also has to store all the frame names and things like that. The animations use vertex positions as a basis, of which the faces are adjusted accordingly. Bones animation takes much less disk space, but memorywise, that I don't know.

Hmmmm... Interesting formula... It's weird though, since my model (vertex animation, 2497 vertices) doesn't seem to follow that formula. It occupies about 34Mb in the nexus (according to the F11 feature inside the engine), which is way bigger than the 8Mb that the formula calculates.

Maybe the formula is only for the file size, which can be different (I don't know why) than the amount of RAM that the model occupies while the game is running.

The really weird thing is that my model occupies 18.6 Mb in MDL7 format, and 5.8 Mb in MDL5, none of them matching the 8 Mb that come from the formula. Do you know if the formula is for the MDL5 or MDL7 format?

The formula doesn't take into account textures, skin vertices, faces, skin faces, and other things like that. If you have a single 1024x1024 texture at true color, that'll easily add 3 MB to the total file size, but this goes to video memory. Each face and skin face takes 6 bytes (16-bit short assigned to 3 difference vertices from 0 to 65,535, and 3*2 is 6). Each vertex takes 12 bytes (3 positions, each using a 32-bit float, 4 bytes for 3 positions makes 12). Each skin vertex takes 8 bytes (Z positions aren't stored for skin vertices). I'm quite certain of the formula (about 90%). 4420 faces translates to 13260 bytes for the model's mesh, 26520 bytes with the skin faces added on as well. There's also animation names to store (one byte per character), so, yeah, it all adds up. The full formula is this:

approx_file_size = vertices*12*frames + faces*6 + skin_faces*6 + skin_vertices*12 + texture_width*texture_height*(texture_bit_depth/8) + characters_in_frame_names + file_header_data;

This only gives a rough approximation of what you're looking at. Each bone uses 12 bytes (24 (as from storing rotational positions)?). So, yeah, there's a lot of variables and I'm still probably missing something. File header data is what determines the type of file this is and the format. This usually contains things like the type of file (file extentions make no difference, it's the file head that does (and thus, a WAV could indeed be opened as BMP image)), how many vertices and faces there are, skin widths heights, and several other things. Then the details are just read off from the contents in the file head. My 2D game's save/load system has file header data in it as well. I use a hex edittor to change the sample rates of WAV files. This is in the file's header data (bytes 18 through 1B with 1C through 1F changed as well as a consequence).