   Animated Models
  Hi,just a quick question, when you animate a model in you engine and perform the vertex updates on the cpu how to you store the results?a) each model is associated with a model_instance and each model_instance holds a copy of the original mesh?b) you hold 2 copies of the mesh 1 reference and 1 that is updated when rendering the animationsvariant b) might be a problem with multipass rendering, on the other hand a) would consume a lot of memory in large scenesany other ideas? maybe some sort of animation cache? so if some model_instances are currently not visible you can release their animatedmesh containers and provide them for visible instances?Thx for your answers   
  If I were to do this, I would store one reference copy that was never modified; all my instances would point to this one reference copy in some way, and then have their own copy of their modified/skinned verts; when skinning, I would transform each vert from the reference copy into the instance's buffer.  I would also allow for each instance's copy to get flushed based on some memory management scheme that took visibility/last-used/level-of-interest into account.Now, the question is, why not just skin on the gpu (i.e., no need to keep instance-specific copies of the mesh)? Are you targeting very low-end video cards? Or do you do cool cpu-side-stuff with the skinned mesh?   ;  This memory management should be implemented in the model class itself then and the instances just aquire a reference of a mesh copy to animated it.instance->calculate_passes_necessary();instance->model->acquire_mesh();instance->animate();instance->model->acquire_passes(5); // used for 5 passesinstance->render()->model->onepass_rendered();...if(instance->model->still_valid())instance->render()->model->onepass_rendered();else{instance->model->acquire_mesh();instance->animate();instance->acquire_passes(4); // 4 passes leftinstance->render()->model->onepass_rendered();}...instance->model->release();Thats the easies way I can think of at the moment.Once this is implemented animation blending will be the next big step.Each vertex can have an arbitrary number of bone weightsdoing this on the GPU would be a little bit expensive especially when doing multipass rendering(e.g: for shadow maps ...)The CPU isn t the bottleneck nowadays, a physics engine takes maybe 6-20%   ;  Saying the CPU isn't the bottleneck nowadays is a bit of an over-generalization... that said, you're right that if you're doing a lot of passes on those skinned meshes, then baking them to static buffers can be a win... still, it all depends on whether you're vertex or pixel bound; if pixel bound, offloading the skinning to the cpu won't help much.The arbitrary number of weights argument isn't a great one, as you can have weights that are zeroed out in your vertex and just create a shader that supports the maximum number of weights you want to have (i.e., 2, or 4, or more). Generally, more than 4 weights won't get you much.Anyway, not meaning to argue against the cpu-skinning path, in the end it's best to support multiple paths (cpu or gpu-skinning), and test your real-world performance.   ;  well I think it makes a differences offloading skinning to the CPU when you are pixel bound, since nowadays GPUs use a unified architecture for fragment and vertex shaders, thus wasting performance with unnecessary skinning operations on the GPU will certainly drop your performance a little.e.g.: 12 lights each requires rendering 20 animated models with 7000 vertices for shadow map generationYou are right that more than 4 weights are pretty rare cases, but what about the additional bandwidth consumption?7000*(4*12)+7000*4 = 7000*(52) ~ 364 kb for one model 364kb*20 models * 60 frames ~ 430 mb of traffic per second+ the load for vertex processingand I need to bind a different vertex shader in order to do shader skinning, maybe I ll implement it with an abstract renderer so I can switch between:)