Instancing in GPU's, from my little knowledge, simply draw the same object at multiple locations. Each "instance" is just a copy of the same model at a different location. Any local effects, such as animation, would effect all instances. The performance improvement comes from gpu being able to deal with virtually all the instance aspects.

One could create several variations of the same object and instance each one. This would be very useful to create variations(say for leaves on a tree) but, while allowing for rather large number of instances(basically limited by the gpu) and variation increases the the cpu's involvement by the number of variations(from the previous case).

If we could send the changes to the gpu then we could get back to the first case(or very close) and achieve very high levels of variations with limited cpu involvement.

For example,

Suppose we wanted to populate a jungle with a lot of animals. Each animal object will have many instances(many tigers and birds but all using the same template). If we had one long animation containing all the possible animations of each animal and send it to the gpu we then would simply have to tell the gpu which part of the animation each instance was in(and we could have a default animation to limit cpu-gpu communications).

This would effectively let us control all the instances with just a animation position indicator(and possible a few other parameters such as scale) and coordinate position. The gpu would take care of all the rest.

The problem, of course, is that that each instance would not have any logic associated with it. This is not a big deal though for most computer objects. The cpu generally has to take care of the logic anyways but in this case, instead to tell send all that information to the gpu we can just send it a few bytes for each instance.

For example, suppose in our jungle we have a few cheetahs and on our cpu we are keeping track of which ones are doing what and simply sending which animation we want them to use to the cpu(instead of sending all the vertex data and/or telling it how to transform them).

This seems like it would be much faster and essentially just boils down to moving some of the code from the cpu to the gpu(which as been what is happening all along).

Using such a method is not ideal because of the lack of physical modeling per instance but for far enough away objects were intersecting objects won't be seen it won't matter.

We could have thousands of birds, for example, all seemingly moving individually but generated from one model with a few animations.... the cpu doing very little but sending which animations to use to the gpu. (and of course deciding what each bird should do)

Anyways, this is a thought but it seems to me the goal of future gpu's is to deal with all the visual aspects while the cpu deals with the logic(and the communication between the too is to be minimized).

Is my interpretation of instancing with animation's flawed or could it be implemented and be useful to 3d games?


1 Answer 1


Yes, you are correct. What you suggest is a viable approach in 3D games. Popular game engines already do this, and have been doing this for some time. If you choose to do this through the vertex shader, you can improve performance in many situations.

For more information about animation: How animation works in realtime graphics


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.