Model With Multiple Vertex Animations
by Robert DeMaria · in Artist Corner · 05/24/2006 (2:13 pm) · 8 replies
Please forgive me if I'm not being entirely clear. I'm a programmer and I'm repeating information my animator told me. My animator is trying to make a player model and all of the player model's animations require vertex animation. (I have a good reason for this and the model only contains about 50 vertices.) We would like all these animations to be contained in separate .dsq files. For some reason, the exporter seems to want to place the vertex animations inside the .dts file. Is there any way to export vertex animations into .dsq files rather than the main .dts file, or is it mandatory that all vertex animations be contained in the .dts file?
#2
05/24/2006 (2:34 pm)
OK. Just to be clear, can you can place as many vertex animations in the same .dts file as you like? Additionaly, can you export .dsq files and have all the vertex animations contained in the .dts file? (I'm using Torque 2D and it requires a .dsq file in order to play an animation.)
#3
05/25/2006 (5:45 am)
Robert, if your animtor can make a rig to control the animation, I would definitely go that route instead of doing morph animation. Morph animation is possible with the current exporters, but it isn't really recommended or completely supported. Just a heads up on the subject.
#4
05/25/2006 (7:53 pm)
I am aware that this is the case with morph animation. However, what we're trying to do really requires morph animation rather than skeletal animation. We've tried creating a rig so that we could avoid using a feature of the engine that isn't really supported. Unfortunately, this rig is downright nasty to use.
#5
Or if your animator wants to bounce ideas off an artist who knows Torque well, feel free to email me.
05/26/2006 (8:09 am)
Hmm... interesting. Be sure to post what you're working on when its "ready". Im quite curious to see what all the animation trouble is about. :)Or if your animator wants to bounce ideas off an artist who knows Torque well, feel free to email me.
#6
The lack of support for morph is partially my fault. Way back in the day, we had this in there to support some very specific simple shapes for a game. Note that these were 'fx' style shapes. When it came time to address what sort of functionality to extend, I wanted better bone and animation support, and really did not feel that putting a lot of work into the morph animations was a great idea (this was back when we were at Dynamix)
When we got bones and deformable meshes in there, we no longer really needed morph support (at least not the type that is in there now) for the stuff I needed to get done.
I really can't think of a model that I could not rig or animate with a bone setup that would absolutely require morphing. I understand that it might be easier for some who have a lot of experience directly animating meshes (for facial expressions or full body 'fat jiggle' effects) to use morphs, but I have not seen anything personally that could nt be done with bones.
If you can outline what you are trying to acheive, I might be able to make some suggestions about how to use the morphs effectively, suggest an animation rig that might work, or otherwise help out.
as for vertex animations, they do have to be in the DTS shape. the DSQ is for node rotations and translations, and does not contain mesh animation information. You can put all the animations is one DTS file (as in, it is possible to have many sequences in one file). note that this does not imply you can put an unlimited number in one file, but in my work, I have not hit a limit
I was not aware that animations had to be in a dsq file for use in TGB (note that I am not 100% aware of the use of DTS shapes in TGB yet).. in TGE, it does not really matter, the Shape Constructor in uses a script to assemble the DTS and the DSQs into one DTS that contains animations in memory.
hope this helps.. I would agree with adam, I would look for using a bone rig for the models, as you will be fighting an uphill battle with morphs (although with the small vertex count, the files may not be that bad to work with).
05/26/2006 (9:43 am)
@ Robert, The lack of support for morph is partially my fault. Way back in the day, we had this in there to support some very specific simple shapes for a game. Note that these were 'fx' style shapes. When it came time to address what sort of functionality to extend, I wanted better bone and animation support, and really did not feel that putting a lot of work into the morph animations was a great idea (this was back when we were at Dynamix)
When we got bones and deformable meshes in there, we no longer really needed morph support (at least not the type that is in there now) for the stuff I needed to get done.
I really can't think of a model that I could not rig or animate with a bone setup that would absolutely require morphing. I understand that it might be easier for some who have a lot of experience directly animating meshes (for facial expressions or full body 'fat jiggle' effects) to use morphs, but I have not seen anything personally that could nt be done with bones.
If you can outline what you are trying to acheive, I might be able to make some suggestions about how to use the morphs effectively, suggest an animation rig that might work, or otherwise help out.
as for vertex animations, they do have to be in the DTS shape. the DSQ is for node rotations and translations, and does not contain mesh animation information. You can put all the animations is one DTS file (as in, it is possible to have many sequences in one file). note that this does not imply you can put an unlimited number in one file, but in my work, I have not hit a limit
I was not aware that animations had to be in a dsq file for use in TGB (note that I am not 100% aware of the use of DTS shapes in TGB yet).. in TGE, it does not really matter, the Shape Constructor in uses a script to assemble the DTS and the DSQs into one DTS that contains animations in memory.
hope this helps.. I would agree with adam, I would look for using a bone rig for the models, as you will be fighting an uphill battle with morphs (although with the small vertex count, the files may not be that bad to work with).
#7
I completely understand the design decision to limit support for morph animation. For the kinds of applications that Torque was designed for, almost all the models should use skeletal animation.
Over the past few days we've been running tests with the morph animation. So far, we haven't run into any killer problems due to the animations themselves. (The problems we ran into had more to do with the fact that there's not that much information on morph animation here.) Each animation ends up being about 200 Kb.
As far as I know, the only way to let TGB know about the existence of an animation is to tell it to look for a .dsq file. This doesn't prevent you from playing a morph animation, it just means that a .dsq file for each sequence has to be generated.
I'm sure that we could create a rig that we could be happy with, but we have to weigh that against the alternatives. The test rigs we made were much more difficult to use and usually resulted in lower quality animations. I'm sure that we could improve upon these test rigs, but there's only one animator working on the project and we have a deadline. We could also generate traditional sprite sheet based animation, but this would be more time-consuming than skeletal animation and would take up more memory than morph animation. So it seems to us that morph animation is the best option.
The player character requires more animations and more complicated animations than any other character in the game. We need his animations to be easy to create and look as good as possible. For our characters that require fewer and more simple animations, we will use a rig rather than morph animation.
I'll see if the animator and the artist will let me send you and Adam a couple of our target animations so that you can see what we're trying to do. :)
@Adam
Thanks for the offer. If my animator runs into any more problems he'll probably send you an e-mail.
05/26/2006 (3:42 pm)
@JoeI completely understand the design decision to limit support for morph animation. For the kinds of applications that Torque was designed for, almost all the models should use skeletal animation.
Over the past few days we've been running tests with the morph animation. So far, we haven't run into any killer problems due to the animations themselves. (The problems we ran into had more to do with the fact that there's not that much information on morph animation here.) Each animation ends up being about 200 Kb.
As far as I know, the only way to let TGB know about the existence of an animation is to tell it to look for a .dsq file. This doesn't prevent you from playing a morph animation, it just means that a .dsq file for each sequence has to be generated.
I'm sure that we could create a rig that we could be happy with, but we have to weigh that against the alternatives. The test rigs we made were much more difficult to use and usually resulted in lower quality animations. I'm sure that we could improve upon these test rigs, but there's only one animator working on the project and we have a deadline. We could also generate traditional sprite sheet based animation, but this would be more time-consuming than skeletal animation and would take up more memory than morph animation. So it seems to us that morph animation is the best option.
The player character requires more animations and more complicated animations than any other character in the game. We need his animations to be easy to create and look as good as possible. For our characters that require fewer and more simple animations, we will use a rig rather than morph animation.
I'll see if the animator and the artist will let me send you and Adam a couple of our target animations so that you can see what we're trying to do. :)
@Adam
Thanks for the offer. If my animator runs into any more problems he'll probably send you an e-mail.
#8
if you could post a link to the relevant .dsq information for TGB, I can look over it. You should not need to do that. In the TGE, the Shape Constructor stuff allows you to take a dts and some dsqs and combine them together into one dts shape in engine.. you can do other things like order and rename the animations, but this should not be necessary if all the animations are in one file, if you look at the dump file from the export, the names and order of the sequences should be listed, and this should be all you need.
you won't be able to make dsqs out of morphs.. if you want to use morphs, make one big dts.
as the models are small, it might not present too much of a problem. Morph animations basically take a snapshot of every vertex at every frame of the animation. With larger models, this can bloat the file (they can end up being HUGE) and the playback is just a series of snapshots of the model, so depending on the application of the animation, this may or may not be a problem.
If the number of animations is large, the file may be huge, and I am not sure what kind of performance you may get.. may work fine, may be problematic.. not sure, as this would go way outside the intended application of the feature (just throwing that out just in case)
I hear you on the morphs .vs rigs..getting a good one might take longer, and in a time crunch situation, better to no be doing R and D.
on the subject of morphing vs. rigs....
I personally cannot think of anything that I would prefer to animate with morphs rather than a rig.. I did a bunch of tests a long time ago comparing the two methods and I personally liked rigs better... I did not find anything I needed morphs to do that I could not do easier with a rig..
note that these were a few examples for facial animation and a 'fat jiggle' rig, some flour sacks... stuff that people would normally say could not be done well without morphs, but the argument is one that I don't buy.
Given that the bone system was designed to be highly optimized and allows for layering of animations by using multiple animation threads (with both additive blending and overrides on a mode by node basis and transtions on a node by node basis per thread).. it really has all the bells and whistles, and does so in a high performance way. The engine side support for the features of the animation system really has the flexibility to allow me to come up with several solutions to every problem I have encountered when trying to get shapes working in game. The morph stuff is not as flexible.
but, the information I posted above should help get you on your way with morphs.. unless I am totally missing something that was done in TGB for a particualr reason, one DTS with all the animations in one file should work for you.
If you end up having performance problems or run into any snags, let me know and I will do my best to offer some help.
It would be interesting to see the model that you are trying to get working so I could better understand the problems you are dealing with regarding creating a workable rig... as if was easy to make a workable rig, it would be the preferred method of implementation, as it is well tested and is performant, whereas using morphs in this fashion is venturing in the unknown a bit (as in.. it is not known if there will be any problems.. if there are, you won't be able to find many people that will be able to help you solve them).
When the topic of supporting morphs comes up, I always say, that lacking a true multiple blend target system with support for the 3d app morph target creation, it would not be a good thing to extend the functionality of (unless we rethink how it is being done).. If I could better understand what you are trying to accomplish, we may be able to make morphs a little better (or at least document them so they are better understood) without a rewrite or rework..
hope this helps...
05/26/2006 (6:25 pm)
@ Robert, if you could post a link to the relevant .dsq information for TGB, I can look over it. You should not need to do that. In the TGE, the Shape Constructor stuff allows you to take a dts and some dsqs and combine them together into one dts shape in engine.. you can do other things like order and rename the animations, but this should not be necessary if all the animations are in one file, if you look at the dump file from the export, the names and order of the sequences should be listed, and this should be all you need.
you won't be able to make dsqs out of morphs.. if you want to use morphs, make one big dts.
as the models are small, it might not present too much of a problem. Morph animations basically take a snapshot of every vertex at every frame of the animation. With larger models, this can bloat the file (they can end up being HUGE) and the playback is just a series of snapshots of the model, so depending on the application of the animation, this may or may not be a problem.
If the number of animations is large, the file may be huge, and I am not sure what kind of performance you may get.. may work fine, may be problematic.. not sure, as this would go way outside the intended application of the feature (just throwing that out just in case)
I hear you on the morphs .vs rigs..getting a good one might take longer, and in a time crunch situation, better to no be doing R and D.
on the subject of morphing vs. rigs....
I personally cannot think of anything that I would prefer to animate with morphs rather than a rig.. I did a bunch of tests a long time ago comparing the two methods and I personally liked rigs better... I did not find anything I needed morphs to do that I could not do easier with a rig..
note that these were a few examples for facial animation and a 'fat jiggle' rig, some flour sacks... stuff that people would normally say could not be done well without morphs, but the argument is one that I don't buy.
Given that the bone system was designed to be highly optimized and allows for layering of animations by using multiple animation threads (with both additive blending and overrides on a mode by node basis and transtions on a node by node basis per thread).. it really has all the bells and whistles, and does so in a high performance way. The engine side support for the features of the animation system really has the flexibility to allow me to come up with several solutions to every problem I have encountered when trying to get shapes working in game. The morph stuff is not as flexible.
but, the information I posted above should help get you on your way with morphs.. unless I am totally missing something that was done in TGB for a particualr reason, one DTS with all the animations in one file should work for you.
If you end up having performance problems or run into any snags, let me know and I will do my best to offer some help.
It would be interesting to see the model that you are trying to get working so I could better understand the problems you are dealing with regarding creating a workable rig... as if was easy to make a workable rig, it would be the preferred method of implementation, as it is well tested and is performant, whereas using morphs in this fashion is venturing in the unknown a bit (as in.. it is not known if there will be any problems.. if there are, you won't be able to find many people that will be able to help you solve them).
When the topic of supporting morphs comes up, I always say, that lacking a true multiple blend target system with support for the 3d app morph target creation, it would not be a good thing to extend the functionality of (unless we rethink how it is being done).. If I could better understand what you are trying to accomplish, we may be able to make morphs a little better (or at least document them so they are better understood) without a rewrite or rework..
hope this helps...
Torque Owner Magnus Blikstad
dsqs have no knowledge of the vertices in the mesh.