Recording multiple vehicles out of sync

[MotherSuperior]

When I record multiple vehicles in this case 4wheel extended traveling in single file down a road they will become out of sync with each other. I will record my first vehicle and it will work fine, then I will record my second vehicle and stay a certain distance behind the first vehicle and it will look fine until I play back the animation of both vehicles driving and the second vehicle will drive faster than the first one even though it wasn't showing this when I was recording, only when playing back the animation. I did a test by lining each of these vehicles next to each other with the same controls (Button 0 for gas) and recording both at the same time and one vehicle will travel faster than the other one, I believe this may be the problem once the animation is played back, I do not know how to control the vehicles speed as the velocity multiplier has no effect. Another thing I noticed was that whenever I record a vehicles animation lets say from frame 0 to 300 when it reaches frame 300 the playback head will jump back to a seemingly random frame let's say 197 and there will only be keys up to this frame even though I set it to record and did record to frame 300. I am using the latest version of the Craft director studio v9.2.1 using 3DS max 2010. Any input would be appreciated since I currently cannot record this convoy of vehicles without them ramming into each other since the recording is unpredictable.

[Carl Buhre]

When I record multiple vehicles in this case 4wheel extended traveling in single file down a road they will become out of sync with each other. I will record my first vehicle and it will work fine, then I will record my second vehicle and stay a certain distance behind the first vehicle and it will look fine until I play back the animation of both vehicles driving and the second vehicle will drive faster than the first one even though it wasn't showing this when I was recording, only when playing back the animation. I did a test by lining each of these vehicles next to each other with the same controls (Button 0 for gas) and recording both at the same time and one vehicle will travel faster than the other one, I believe this may be the problem once the animation is played back, I do not know how to control the vehicles speed as the velocity multiplier has no effect. Another thing I noticed was that whenever I record a vehicles animation lets say from frame 0 to 300 when it reaches frame 300 the playback head will jump back to a seemingly random frame let's say 197 and there will only be keys up to this frame even though I set it to record and did record to frame 300. I am using the latest version of the Craft director studio v9.2.1 using 3DS max 2010. Any input would be appreciated since I currently cannot record this convoy of vehicles without them ramming into each other since the recording is unpredictable.

It sounds like your scene is too heavy, that you're getting a low FPS. When the frame rate is too low the recording will have to drop frames in order to keep up. According to Micael Belin, our system developer, the system is supposed to just drop drawing the frames but not drop writing the key frame data if it can't keep up. But I know from personal testing that it can act the way you're describing if the performance gets too low.

This is something that you can easily avoid though. If you aren't already, I would suggest hiding the high poly models of the vehicles when you're recording. If that doesn't help, try hiding some parts of the scene to get a better FPS. If you STILL can't get a good enough FPS, you can always just record the vehicles one at a time. Once you have your recording that you're content with, use Resimulate to update the animation (if you make any changes) since Resimulate is not affected by low frame rates.

I hope this gives you some ideas how to avoid the problem. Please let us know if you're still encountering the problem or have any other questions or comments. Good luck!

[MotherSuperior]

Carl,

Thank you, hiding everything except a few proxy geometry objects in my scene while recording is now allowing me to recording the full duration of my animation timeline. However I do not know the threshold of how much I am allowed to have unhidden for a recording, I am not sure if it is CPU, videcard or system ram dependent. This is vital since I need certain objects unhidden in order to avoid driving into them. Is there a predictable way to measure if my system will be able to record all frames depending on how much of my scene is visible when recording? IE X number of polygons visible etc...

[Carl Buhre]

Carl,

Thank you, hiding everything except a few proxy geometry objects in my scene while recording is now allowing me to recording the full duration of my animation timeline. However I do not know the threshold of how much I am allowed to have unhidden for a recording, I am not sure if it is CPU, videcard or system ram dependent. This is vital since I need certain objects unhidden in order to avoid driving into them. Is there a predictable way to measure if my system will be able to record all frames depending on how much of my scene is visible when recording? IE X number of polygons visible etc...

I'd say at least a frame rate over 10 frames per second. In 3ds Max it's possible to right-click the viewport and select "Show Statistics" to be able to view the current FPS. I'm not sure how to do it, or if it's possible in Maya. It should be fairly easy to see though, if your recording seems sort of choppy or more of a slide show then a fluid recording, then you might encounter this problem.

You can try and unhide the crucial objects and see if it doesn't impact your performance too much. If it does, you can always place a simple box that's about the same size as the object you're trying to avoid, in the same place, and then drive around the box. I'm sure you understand what I mean.
That is just a workaround though, that's not normal workflow but if your scene is very heavy and your objects too, then it's definitely a method that works.