Real-time lattice deformations in games
Author
Hey everyone,
I don't know if this is in the right place or not but I'm hoping that the right people will see this. I'm not actually a programmer, but a technical artist that is planning to learn programming in the near future for the purpose of creating some editor tools.
Anyway, I had a question about real-time deformations through the use of lattices or grids for games. I did a search on gamedev.net but didn't come up with anything relevant to my question. Anytime I do research on real-time deformations I find articles that pertain to character animation but I would like to find information that relates to manipulating static meshes.
For Example: Say I have a tree with exposed roots and several branches I modeled in Max or Maya. I need 60 of these trees for the level that I'm creating. Each tree also needs to have slightly different orientations for their root and branch structures but I don't want to export 60 versions of the tree from Max or Maya as seperate static meshes. From what I understand, it's typically better for performance to instance one static mesh 60 times as opposed to instancing 60 unique static meshes only once. So would it be possible to create an in-game lattice or deformation system that would allow you to adjust the vertices of a single static mesh between each instance of it in the game?
These deformations wouldn't have to be animated at all. I am simply interested in a system that could manipulate a static mesh in the engine through an editor tool so that I could get multiple variations of one static mesh through instancing without the need to create several unique static meshes. It seems that doing something like this shouldn't be that difficult, so I guess that my next question would be this? Would this type of deformation or manipulation have a significant impact on performance?
Remember, these aren't animated deformations and the final result from the editor tool can be baked, collapsed, frozen, etc. before actually being displayed in the game. Like I said I'm not a programmer, but I think an editor or in-game lattice system like this could be extremely beneficial for several situations. The tree is just one example that I thought would illustrate the concept. I actually have a much more elaborate system in mind that would utilize this type of lattice deformation ability. I would just like to know if any experienced or knowledgeable programmers are aware of any issues that would arise or have to be addressed.
Thanks. I'll appreciate any feedback I can get.
BTW, this type of system doesn't have to be engine/editor specific. I'm just thinking in general terms right now.
Since the meshes aren't animated, you could build the 60 deformed meshes at load-time based on the original mesh and some parameters. On the other hand, there might be some advantages to using a single mesh and animating it.
If you're talking strictly trees, then there's other fully featured products out there (http://www.speedtree.com/)
When you need large ammounts of trees, you'll usually resort to some procedural generation, and have your meshes built on the fly. While using instancing leads to performance improvements, proper handling of levels of detail, billboarding, and similar techniques will yield much greater performance benefits.
When you need large ammounts of trees, you'll usually resort to some procedural generation, and have your meshes built on the fly. While using instancing leads to performance improvements, proper handling of levels of detail, billboarding, and similar techniques will yield much greater performance benefits.
Author
Antheus,
Thanks for the suggestion. If I was only considering this technique for the application of trees and foliage I would conclude that this approach isn't worth the effort and that there are probably more ideal solutions available. However, I don't intend for the application of this technique to be restrictred solely to trees and foliage, but plan on using it for much more exotic static meshes.
John Bolton,
Your idea of actually using an animation to drive the deformation positions is interesting. I'm assuming each instance of the object would have the same initial position and then each instanced variation would load a unique animation file that would only be 1 frame in length that would set the mesh to the desired deformation position. Is this what you were thinking of?
Would this work with a lattice, or were you thinking of using hierarchial animation with bones? I would prefer not to use a bone system. It'd probably work well with roots and branches but not with some of the other static meshes I have in mind.
Thanks for the suggestion. If I was only considering this technique for the application of trees and foliage I would conclude that this approach isn't worth the effort and that there are probably more ideal solutions available. However, I don't intend for the application of this technique to be restrictred solely to trees and foliage, but plan on using it for much more exotic static meshes.
John Bolton,
Your idea of actually using an animation to drive the deformation positions is interesting. I'm assuming each instance of the object would have the same initial position and then each instanced variation would load a unique animation file that would only be 1 frame in length that would set the mesh to the desired deformation position. Is this what you were thinking of?
Would this work with a lattice, or were you thinking of using hierarchial animation with bones? I would prefer not to use a bone system. It'd probably work well with roots and branches but not with some of the other static meshes I have in mind.
The problem with generating 60 deformed trees up-front is that you then have to store 60 copies of pretty similar information in memory. Granted, the vertex data for a tree is probably not very big, but it'd still be nicer to avoid using 60 times as much data.
I think you're best off taking the shader approach to deform a base model at runtime. To approach the lattice problem...
Given your base mesh and the undeformed lattice over it, figure out the 'cube' of the lattice that each vertex falls within. Pick one corner of that cube to be the 'origin' for the cube, and take the edges that meet at that corner as the basis vectors. Taken together they make a new vector space for this cube; calculate and store the vertex position (and other data, if you want) in this vector space, along with the ID numbers of the lattice vertices that make up the cube (or possibly just a cube ID).
At runtime, you have one copy of the mesh - vertices in lattice-cube-space - in a vertex buffer, and each lattice as a list of lattice vertex positions, either in system memory or in a vertex buffer as well (all of them laid end-to-end).
When rendering, you have a shader that takes the vertex position from the mesh along with the information necessary to retrieve the 'bounding points' from the lattice data, and then you calculate the world space position easily enough. The lattice data is either passed in vertex shader constants, or maybe you could use hardware instancing to draw a bunch of deformed meshes all in a single batch.
I think you're best off taking the shader approach to deform a base model at runtime. To approach the lattice problem...
Given your base mesh and the undeformed lattice over it, figure out the 'cube' of the lattice that each vertex falls within. Pick one corner of that cube to be the 'origin' for the cube, and take the edges that meet at that corner as the basis vectors. Taken together they make a new vector space for this cube; calculate and store the vertex position (and other data, if you want) in this vector space, along with the ID numbers of the lattice vertices that make up the cube (or possibly just a cube ID).
At runtime, you have one copy of the mesh - vertices in lattice-cube-space - in a vertex buffer, and each lattice as a list of lattice vertex positions, either in system memory or in a vertex buffer as well (all of them laid end-to-end).
When rendering, you have a shader that takes the vertex position from the mesh along with the information necessary to retrieve the 'bounding points' from the lattice data, and then you calculate the world space position easily enough. The lattice data is either passed in vertex shader constants, or maybe you could use hardware instancing to draw a bunch of deformed meshes all in a single batch.
Author
I'm not sure how I would use a shader to actually drive the lattice data, but I'll take your word for it that this is a feasible approach. After all, I"m not a programmer... yet.
Basically though, it sounds as if it's better from a performance perspective to actually determine the deformed mesh vertices at runtime rather than having them all stored as seperate lattice vertex information for each instance of the object in the level. That makes sense to me unless I misunderstood what you were saying.
Basically though, it sounds as if it's better from a performance perspective to actually determine the deformed mesh vertices at runtime rather than having them all stored as seperate lattice vertex information for each instance of the object in the level. That makes sense to me unless I misunderstood what you were saying.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
