Blender scale corruption in exported character model?
by Duncan Gray · in Artist Corner · 03/29/2007 (10:30 pm) · 30 replies
I don't know if this is an exporter problem or something wrong with my blend file setup.
[edit - removed picture]
Also, in the game the players legs are running in slow motion even though the animation is set to 15 frames per sec.
Using exporter version 0.94 and latest Blender.
Any help welcome.
[edit - removed picture]
Also, in the game the players legs are running in slow motion even though the animation is set to 15 frames per sec.
Using exporter version 0.94 and latest Blender.
Any help welcome.
About the author
#2
I'll spend some time on them later, re-read the exporter docs and see if there is anything wrong.
03/30/2007 (3:15 pm)
Thanks Joseph. Ok, the scale problem is now fixed but I'm still getting slow motion animations, however, these are animations from Frank's tut so they may be problematic.I'll spend some time on them later, re-read the exporter docs and see if there is anything wrong.
#3
03/30/2007 (3:17 pm)
Oh, the animations are using IK keys, perhaps thats a clue. 
#5
# this is the number of frames we are exporting.
#numFrames = sequencePrefs['InterpolateFrames']+1
numFrames = sequence.numKeyFrames
I think the sequencePrefs['InterpolateFrames'] is where the 'stale' data is coming from via the GUI panel.
I'll leave the 'why' for you... :)
03/30/2007 (11:58 pm)
I hacked a temp solution for my exports. In DtsShape_Blender.py near line 1030 I did the following:# this is the number of frames we are exporting.
#numFrames = sequencePrefs['InterpolateFrames']+1
numFrames = sequence.numKeyFrames
I think the sequencePrefs['InterpolateFrames'] is where the 'stale' data is coming from via the GUI panel.
I'll leave the 'why' for you... :)
#8
To reproduce it, take this model and click the root animation and observe the frames slider value (41). Don't touch any frame slider values though. Then do the export.
Clicking the root animation seems to set the sequencePrefs['InterpolateFrames'] value to 41 for several of the animations, which then only gets cleared when you changethe frame slider value.
I modified the DtsShape_Blender.py file to print both the sequencePrefs['InterpolateFrames'] and the sequence.numKeyFrames values and you will see the number 41 popping up in several animations as the Interpolated value. Here is the log file.
04/01/2007 (2:03 pm)
Draging the frames slider to a new value is what fixes it because it refreshes the variable for that animation.To reproduce it, take this model and click the root animation and observe the frames slider value (41). Don't touch any frame slider values though. Then do the export.
Clicking the root animation seems to set the sequencePrefs['InterpolateFrames'] value to 41 for several of the animations, which then only gets cleared when you changethe frame slider value.
I modified the DtsShape_Blender.py file to print both the sequencePrefs['InterpolateFrames'] and the sequence.numKeyFrames values and you will see the number 41 popping up in several animations as the Interpolated value. Here is the log file.
#10
It may have nothing to do with having clicked the "root" animation as I said ealier because I notice that the first animation exported, em_scoutroot, has 41 actual frames and perhaps that value gets defaulted into uninitialized slots of the sequencePrefs array. For some reason the em_run export got the right values this time, previously, as shown ealier, it had 41 interpolated frames.
I have not looked at the python code for the GUI section yet so I can't give more definitive info at this point.
04/01/2007 (2:23 pm)
Looking in that log file I found em_back, em_side, em_root all have values which differ for actual and interpolated frames.It may have nothing to do with having clicked the "root" animation as I said ealier because I notice that the first animation exported, em_scoutroot, has 41 actual frames and perhaps that value gets defaulted into uninitialized slots of the sequencePrefs array. For some reason the em_run export got the right values this time, previously, as shown ealier, it had 41 interpolated frames.
I have not looked at the python code for the GUI section yet so I can't give more definitive info at this point.
#11
04/01/2007 (2:28 pm)
Links fixed (oops)
#13
Ever since I changed the frame-count on the em_run animation it has exported correctly as well. However the
em_back
em_side
em_root
animations are still exporting with frames counts which do not match what you see in the sequence info window. I'm sure if I change the frame count on one of them it will correct itself for that animation as well.
I can't explain why it does not occur on your rig. strange
04/01/2007 (3:27 pm)
Yes, the keyframes in the sequence info window was/is correct per what it should be. The bug is only noticeable in the export log file (see above link) and in the game.Ever since I changed the frame-count on the em_run animation it has exported correctly as well. However the
em_back
em_side
em_root
animations are still exporting with frames counts which do not match what you see in the sequence info window. I'm sure if I change the frame count on one of them it will correct itself for that animation as well.
I can't explain why it does not occur on your rig. strange
#14
04/01/2007 (3:33 pm)
Where do I find the TorqueExporter_SCONF ? Is it part of the blend file or a sepparate file on disc somewhere?
#16
First check that all is well by doing the following three checks
(1)In the action editor window, pick an animation and check the frame count.
(2)In the exporter window , click the refresh button and check that the frames for the above action is correct
(3)Now edit the TorqueExporter_SCONF file and check that the interpolated frames for the above action are a match.
Hopefully they all matched. Now to highlight the problem.
(A)
In the action editor window, highlight all the keys then push 's' to scale them and move the mouse till you have twice as many frames as before.
Repeat the three check steps above and you will find that the frames value in step(2) will not exceed the interpolated frames value from step (3) regardless of how many extra frames you scaled the animation up by.
(B)
In the action editor window, highlight all the keys then push 's' to scale them and this time move the mouse till you have halfas many frames as you originally had.
Repeat the three check steps above and you will find that the frames value in step(2) will now match the actual frame count you have in the animation window, but the the interpolated frames value from step (3)
does not drop to match the actual frame count until you manually adjust the frames slider.
This discrepancy can be a source of confusion between what you think you are exporting and what is actually going on.
So now I figure, OK, the idea was that I design my animation in the action editor and scale it in the exporter by moving the frames slider. That makes sense because scaling it in the action editor will move keys in-between frames which makes it harder to edit later on.
So now I like this idea. I scale my run animation back to 16 frames in the action editor and set the exporter frames slider to 11 frames, expecting to get the animation scaled to 11 frames. I check it in Show tool pr and see 11 frames (good) but it still plays slow, so I check the sequence info window and see thats its set to play at 11 frames per sec instead of 15 which explains that. The orc character has a run animation of 11 frames playing at 15 frames per sec
question Where does this value get set, I assumed all animations, regardless of frame count will get played at 15 frames per sec. (Its set to 15 in Blender)
Another scenario. If I wanted to scale up an animation from 5 frames in the action editor to 16 frames (interpreted) this line of code prevents that from happening.
04/09/2007 (4:02 pm)
Here is how to reproduce the discrepancy between actual and interpreted frames.First check that all is well by doing the following three checks
(1)In the action editor window, pick an animation and check the frame count.
(2)In the exporter window , click the refresh button and check that the frames for the above action is correct
(3)Now edit the TorqueExporter_SCONF file and check that the interpolated frames for the above action are a match.
Hopefully they all matched. Now to highlight the problem.
(A)
In the action editor window, highlight all the keys then push 's' to scale them and move the mouse till you have twice as many frames as before.
Repeat the three check steps above and you will find that the frames value in step(2) will not exceed the interpolated frames value from step (3) regardless of how many extra frames you scaled the animation up by.
(B)
In the action editor window, highlight all the keys then push 's' to scale them and this time move the mouse till you have halfas many frames as you originally had.
Repeat the three check steps above and you will find that the frames value in step(2) will now match the actual frame count you have in the animation window, but the the interpolated frames value from step (3)
does not drop to match the actual frame count until you manually adjust the frames slider.
This discrepancy can be a source of confusion between what you think you are exporting and what is actually going on.
So now I figure, OK, the idea was that I design my animation in the action editor and scale it in the exporter by moving the frames slider. That makes sense because scaling it in the action editor will move keys in-between frames which makes it harder to edit later on.
So now I like this idea. I scale my run animation back to 16 frames in the action editor and set the exporter frames slider to 11 frames, expecting to get the animation scaled to 11 frames. I check it in Show tool pr and see 11 frames (good) but it still plays slow, so I check the sequence info window and see thats its set to play at 11 frames per sec instead of 15 which explains that. The orc character has a run animation of 11 frames playing at 15 frames per sec
question Where does this value get set, I assumed all animations, regardless of frame count will get played at 15 frames per sec. (Its set to 15 in Blender)
Another scenario. If I wanted to scale up an animation from 5 frames in the action editor to 16 frames (interpreted) this line of code prevents that from happening.
interpolateInc = float(sequence.numKeyFrames) / float(sequencePrefs['InterpolateFrames']) # make sure it's not less than 1 if interpolateInc < 1.0: interpolateInc = 1.0
#18
What I'm getting at is, to match the playback speed of my run animation with that of the Orc, I exported it at 11 frames of animation assuming it would play at 15 frames per sec like the Orc does. Instead I got 11 frames playing at 11 frames per sec.
When I did my original hack (stated earlier), I managed to get 11 frames playing at 15 frames per sec. So somehow that animation time can be manipulated to get the desired result. I will look into that a bit further and try and see where that animation time gets extracted/calculated.
It exports the correct amount of frames but you won't get the same quality of movement.
Is it not possible to hook into Blender's method of scaling the animation and use that during the export process? That should then scale based on IPO curves rather than just dropping frames and will give a better result.
04/09/2007 (6:53 pm)
Quote:That implies that a time factor corresponding to the length of the animation is being exported with the animation. It would be useful to have the exporter fix that time factor so that animations always play at 15 frames per sec regardless of how many frames are actually in the animation.
(it's calculated in STP based on the number of frames and length of the animation)
What I'm getting at is, to match the playback speed of my run animation with that of the Orc, I exported it at 11 frames of animation assuming it would play at 15 frames per sec like the Orc does. Instead I got 11 frames playing at 11 frames per sec.
When I did my original hack (stated earlier), I managed to get 11 frames playing at 15 frames per sec. So somehow that animation time can be manipulated to get the desired result. I will look into that a bit further and try and see where that animation time gets extracted/calculated.
Quote:
Does it actually export OK if you scale the animation down from say 40 frames to 5 frames, and adjust the FPS so that it plays back at the same speed
It exports the correct amount of frames but you won't get the same quality of movement.
Is it not possible to hook into Blender's method of scaling the animation and use that during the export process? That should then scale based on IPO curves rather than just dropping frames and will give a better result.
Torque Owner Redacted