Performance on rendering

[DarkShadow44]

Hi,
I use my own Modelformat ^^

I want to render "high-definition" (that means many vertices) sceletal-animated models.
Is it better to load ALL vertices for EVERY frame into memory and render them, or shall I load the basic structure (frame 1) and calculate the new vertices every time I render it ?

[Dark Photon]

So you're asking whether to do skinning on the CPU or GPU?

You can nearly always find corner examples that will break a general case, so as usual the answer is "it depends". There are also use cases such as collision detection that may push you to one or the other.

But we've done skinning on the GPU (and are far from alone there) and it's plenty fast.

[DarkShadow44]

No I mean, if I shall use a big modelfile with contains all pre-calculated vertices for my animations or, a smaller one, but then calculate the vertices for every frame.

So the question is: memory <-> CPU/GPU

[Dark Photon]

No I mean, if I shall use a big modelfile with contains all pre-calculated vertices for my animations or, a smaller one, but then calculate the vertices for every frame.

So the question is: memory <-> CPU/GPU

I think I understand. You're considering 100% pre-calculated animation step poses vs. dynamic calculation/skinning either on the CPU or the GPU.

Yeah, you got it. Mem vs. cycles.

Depending on total size, in either case you can have all the data on the GPU in VBOs/textures.

[DarkShadow44]

I think I understand. You're considering 100% pre-calculated animation step poses vs. dynamic calculation/skinning either on the CPU or the GPU.

Yeah, exaclty that


You mean, that if I have enough memory, I should use that ?

[akashiraffee]

You mean, that if I have enough memory, I should use that ?

If you can place it in video memory with a VBO, you might as well. After all, nothing else will be using that anyway, and it's the "most ideal" option.

However, you must then rely on the card having a certain amount of memory.

If you are going to store it in normal memory, I think the bus and transfers will be a bottleneck more than the CPU, depending on the intensity of the work. Try it and see.

[Alfonse Reinheart]

You mean, that if I have enough memory, I should use that ?

No. Well, I don't know if he means it, but I wouldn't suggest it.

Vertex animation-based animation is not superior to bone-based animation. Especially if you want to play multiple animations at once (blending one animation out while another one blends in). And of course, while you might be able to fit one of these in memory, what if you want 2 different meshes that use the same animation? The baked position data for one mesh is useless for the other, while the bone-based animation data is transferable to another mesh.

Unless you are deliberately trying to simulate Quake 1-style animation, I would strongly advise against this.

[DarkShadow44]

Vertex animation-based animation is not superior to bone-based animation.

why ?
If I want multiple animations, I just draw animation 1 and then draw animation 5 for example.

The baked position data for one mesh is useless for the other

?????
I can move the objects by using glTranlatef()


I also don't know how to calculate the vertex coordinates for bone animations ^^

[Dark Photon]

[You mean, that if I have enough memory, I should use that ?

Only you know all of your application's constraints. But if that's your only constraint and its satisfied, then sure! Go for it!

You might play around with doing skinning on the GPU at some point, because that's a fun shader exercise, though it does eat more GPU cycles.

[Alfonse Reinheart]

why ?
If I want multiple animations, I just draw animation 1 and then draw animation 5 for example.

The kind of animation you're talking about is essentially analogous to sprite animation in 2D. You have a series of bitmaps and you pick which one to draw based on the animation. So if you have a 3-step walk cycle, you draw frame A, then frame B, then frame C.

However, you cannot create a frame between A and B without drawing another frame. You can't create a frame halfway between A and C algorithmically; you have to draw it beforehand.

With skeletal animation, everything is done with a series of matrices. So you can combine multiple animation frames to get the final correct animation.

I also don't know how to calculate the vertex coordinates for bone animations

Maybe you should learn. Vertex animation is sometimes used these days, but it is quite rare. Skeletal animation just has too many advantages to allow vertex animation to be used in anything except a few specialized niches.