INSERTED...
Responding to your question... iClone will not lie to you. If an action (running, lifting a prop, falling down, etc.) takes 2 seconds on the timeline, it will take you 2 seconds to watch it if you are in "realtime" mode.
Ah... I got distracted while writing my previous little post, which gave Rampa time to cross-posted a very similar message. "Hi, Rampa." <waves>
Oh well... on with the real message...
REALTIME...It's sort of weird, because you're monitor also refreshes at a certain rate (typically 60 Hz, or 60 fps). A game or iClone might "compute" an image faster or slower than that. So the "realtime fps" reported by iClone is simply telling you how quickly your system is able to process your scene. In a way, it's sort of meaningless.
If you have a really slow scene, it will look choppy. I had a very complex scene that crushed my computer, and it ran as slow as 3 fps. Ugh. It was hard to even edit. But if something was supposed to happen a 37-seconds, that's when it happened.
In an effort to display events at the right TIME, iClone may skip some frames. So it will only take you one minute to watch a one-minute animation, but iClone might have to "compute" only 60% of the frames in order to show that one-minute animation in one minute. Otherwise it might take a minute-and-a-half to watch your one-minute video. In that case, it would be really hard to animate motions that don't turn out to be too slow or too fast. So once again, focus on the "time," not the fps.
WHAT'S WRONG WITH REALTIME?People have mentioned "physics." Suppose a ball is supposed to bounce on the floor. If iClone skips (avoids computing) several frames in a valiant effort to play your animation at the proper speed, the ball might "fall through the floor" during the skipped frames. At frame 110 it's above the floor, and at frame 115 it's below the floor. It doesn't bounce, and you scratch your head wondering what went wrong.
BY-FRAME TO THE RESCUE...If you switch to "By Frame" rendering, it will take as much time as needed to fully compute each-and-every frame. So in the case of the bouncing ball, the ball will properly bounce because the collision between the ball and the floor will not be skipped.
As has been pointed out already, when you render your output (either to video or to a sequence of images), it will use a "by frame" method anyway. So again, it doesn't really matter.
(In that system-crushing project I mentioned, it took me about 25 seconds to render each frame. Don't worry, that is abnormal, and I was purposely doing a stress-test. But the point is the resulting animation played at the proper speed.)
HOW TO USE "BY-FRAME"...The term is "baking" physics.
I'll skip a couple of details, but if you have physics turned on (such as between the ball and the floor), you can play the scene "by frame" to ensure the bounce happens. Then you turn physics off (on the ball), and iClone "remembers" the path that was computed when physics was active. Now you can switch back to realtime display, and the ball will bounce even if a lot of frames get skipped.
Whether you "bake" physics or not, you'll still get the correct result when you produce your final animation.
CLOSING...I hope this addition helped more than it hurt. Be persistent, continue to ask questions, good luck, and have fun.
iClone 7... Character Creator... Substance Designer/Painter... Blender... Audacity...
Desktop (homebuilt) - Windows 10, Ryzen 9 3900x CPU, GTX 1080 GPU (8GB), 32GB RAM, Asus X570 Pro motherboard, 2TB SSD, terabytes of disk space, dual monitors.
Laptop - Windows 10, MSI GS63VR STEALTH-252, 16GB RAM, GTX 1060 (6GB), 256GB SSD and 1TB HDD
Edited
9 Years Ago by
justaviking