Locking the framerate

Hello,
we have a 60 seconds animation made in maya at 30 fps (1800 frames in total). This animation is going to be used in an introductory sequence; we'd like to play the whole scene in unity at the same speed it was recorded so that we could sync frames with scripted events.

Locking the framerate by calling

Code (csharp):

1. Time.captureFramerate = 30

seemed to be the way to go. Unfortunately we're having some problem.

When the scene is played in the editor the framerate locks and the animation plays nicely; on the other hand if we build the standalone application and play it on mac or windows the whole thing is played at a very high speed, and the whole animation ends in just 14 seconds or so.

Also, while the Time.time property still displays float values as always they seem to be tenths of seconds instead seconds. Any idea appreciated. Thanks,

Eugenio

 

don't have time to really rip into your issue but one thing to mention... i believe the editor is locked at 30fps. might be the reason it's ok in editor and your frame rate script may not be working at all. i'd double check it with some debugs to make sure it's giving you what you think it is.

 

Thanks pete,
apparently you have to just call Time.captureFramerate to lock your framerate. Am I missing something?
Thanks,

Eugenio

 

The editor is actually locked at 100fps. The real problem is that Time.captureFramerate doesn't really do what you want. I'm not entirely sure why it would have worked in the editor...just a coincidence? When you use it, real time doesn't influence time in the game anymore. The main purpose is to capture frames for playing back as a movie, like in this script. Capturing a screenshot and saving each frame as a PNG file isn't exactly fast, so real time can't affect game time or there's no way you'd be able to get something usable like a steady 25fps (except on very fast hardware). When you do that, your game will probably run really slow, but it will play back at 25fps at the correct speed. Conversely, if you're not doing anything intensive like that every frame, your game is going to appear to run really fast.

Of course, that means you need some other solution...unfortunately my brain isn't working at the moment; maybe somebody else has some functioning brain cells....

--Eric

 

Thanks very much Eric, now it make sense.
So no way to lock the framerate in unity?
That's too bad. We then could use triggers to sync frames to scripted events but that's really like shooting an ant with a cannon not to say that it might be inappropriate in some case. Any idea appreciated. Thanks,

Eugenio

 

A 60 second animation playing back in 14 seconds? File a bug report, right?

Am I wrong in thinking that animations should play back at a per-second rate, not a per-frame rate?

 

Not with captureFramerate set to true--as fast as possible would be intended behavior: http://unity3d.com/Documentation/ScriptReference/Time-captureFramerate.html

As mentioned, it's only intended for things like capturing video or other non-realtime uses.

 

Ok, I've found this simple solution. If anybody comes up with something better please let me know, in the meanwhile I share it for those interested.

1. Create an empty object in the scene.
2. Assign it the script that follows.

Code (csharp):

1.  
2. var frameRate: int = 30;
3.  
4. private var oldTime : float = 0.0;
5. private var deltaTime : float = 0.0;
6. private var curTime : float = 0.0;
7.  
8. function Start(){
9.     deltaTime = 1.0 / frameRate;
10.     oldTime = Time.realtimeSinceStartup;
11. }
12.  
13. function Update(){
14.     curTime = Time.realtimeSinceStartup;  
15.  
16.     while((curTime - oldTime) < deltaTime){
17.         curTime = Time.realtimeSinceStartup; // busy waiting        
18.     }
19.  
20.     oldTime = Time.realtimeSinceStartup;
21. }
22.  
23.  

Take care.

Eugenio

 

Seems like a very neat solution to me.

d.

 

I don't know if C# has them off-hand, but in Java you could schedule a timer to do this without using a "busy wait", perhaps you can use a lock or event based approach instead, this seems extremely wasteful.

A quick google shows: http://www.dotnetperls.com/timer

Give this a try, it is most likely a far better solution since it's likely using interrupts instead and not incurring such overhead.