Smoothing Fredo6 Animator Animation

I was wondering if anyone knows how to smooth out camera zoom in animator. I actually bought a new laptop with an RTX 2060 GPU thinking this would help but now it seems like the jerkiness is in Animator itself. I say this because the normal scene transitions in SketchUp are pretty smooth but when you try to zoom a camera it seems jerky to me. If an RTX 2060 will not fix this then it has to be something in the software itself.

I made a short video to show an example and it is here https://www.youtube.com/watch?v=CVCaFKglhJ8

Any help would be appreciated. If someone has experience with this and can advise a better animation extension, I am open to that also, Thanks!

Animator is designed to generate videos. This is what you deliver from the project and show to your clients. The interactive mode is provided for convenience, to get a preview of what you do while designing.

  1. You need to generate a video (mp4, gif, …) and it should not be jerky. Click on the button
    image

  2. In the interactive mode, toggle the timeline / palette visibility off. This should improve the smoothness of interactive animation. Click on the button with an horizontal line
    image
    image

3 Likes

Thanks! It takes too long to generate a video from inside animator. It wants 15 mins to render this 40 sec video. So I record my screen with OBS then edit the video created by OBS.

Maybe there are settings in the video rendering part that would speed that process?

I’d like to say to Fredo6, mate, you are a complete legend - a very generous and skilled person.
thanks for all you have done and do for SU Users world wide- I really appreciate your generosity.
cheers

4 Likes

I appreciate the work also but if you watch my video it was going take 15 mins to render a 40 second video clip. That is not sustainable. My instructional animation is like 15 mins long and at that rate it would all day to render the videos. So my question is; are there settings that can optimize the time to render the videos. I realize that what I am looking at is the preview of what will be rendered and not the video but if I am going to use this extension it has to be more efficient with time. If not I will try SU Animate or wait till SketchUp extension catch up to the 21st century. I mean my RTX 2060 GPU will render 15 min youtube videos in about a minute so it has to be a software or setting issue, not a hardware issue. Thanks

Verify that SketchUp is using your Nvidia GPU.
Open Window > Preferences > OpenGL > Graphics Card Details

The higher the anti-aliasing, the longer the render will take.
The lower the anti-aliasing the more jagged the edges will appear in the output.

The larger the output frame size, the longer the time it will take.

Also, if the screen view size differs from the output frame size, this will add time for each frame to be transformed. (There are freely available extensions to make it easier to resize SketchUp so that the model view matches the output frame size.)

Is the output a compressed format? Compression takes time. The more compression the more time it takes. (For example MPEG is compressed.)

Generally speaking, animation frames can be written out as individual uncompressed BMP files and later stitched together in a video using an external application or command line utility. (The latter could likely be called by a SketchUp extension to do this in it’s own process, so as to free up SketchUp for doing other work.)

SketchUp extensions can only use what the SketchUp API provides for native video export capability.
Or they might have to get a 3rd party video library and pass frames to this 3rd party library.

Please also understand that Ruby is an interpreted language and is much slower than compiled code.

Things that might slow down the drawing of the model view might also slow the video export. Close all inspector window trays and especially the Outliner and Instructor. Close any unneeded tollbars so their buttons need not be redrawn, etc.

SketchUp itself has an issue with very large video files. There is a bug that if the size of the file (in bytes) exceeds the largest integer that can be expressed with 32 bits (~4.2Gb) then the output video file is never copied from the TEMP folder to the disk location where the user asked it to be. This looks like a silent fail to the user. But the user can manually copy the “video.mpg” from the TEMP folder elsewhere giving it the proper filename.

15m * 60s = 900s
900s / 40s = 22.5sec per frame write time

assume 30fps for video: 900 * 30 = 27,000 frames
27k frames @ 22.5sec write time/frame
= 607,500secs = 10,125 mins
= 168.75 hours = a bit over 7 days

This is not criticism, it is a request for help. Will it really take over an hour to render a 12 second video clip?

Thanks, this is the kind of help I was looking for. I am a design-build contractor, not a doctor :slight_smile:

… I see that your output is really about 25.16 fps.
And the true write time is at 17.55 secs per frame.

I’ve never tried this extension by Fredo so I cannot say why each frame takes as long as it does.

Please post a link to the complete video, so we can see what it does.

There must be something wrong somewhere.

On my poor Intel integrated card, it takes around 6 minutes to generate 626 frames (25 seconds video), with a viewport resolution of 1524x740.

image

In general, it takes about 1 second to write out the viewport to a PNG file, and a 3-4 seconds to stictch these image files to a video MP4, MOV or GIF.

Do you have a super-large resolution.

At least the result is not jerky

1 Like

I have used @Fredo6’s Animator extension quite a lot in the last few years, on a 2014 iMac with 5K retina display. From memory, I think the time taken to render the individual frames (by watching the Video Generation dialog box) is up to 7 seconds (that number sticks in my head), with a reasonably complex model and animation sequence. Say a few million edges and faces, with up to a thousand components in a hierarchy 2-5 levels deep. I usually compose my videos in clips that are up to about 30 seconds long at 24 to 30 FPS, and that usually takes an hour or two to render the clip. The final FFMPEG conversion step (transforming the individual still frames generated by Animator into an MPEG file) takes only a few seconds for the entire clip.

[Edited to add that the interactive “preview” mode in Animator is almost unusable with a model of this complexity. Scrolling the interactive timeline and watching the video-preview takes one to three seconds per frame, which makes scrolling in the timeline quite difficult and frustrating. Fortunately not all the video clips that I generate use my full model. A model with only a few hundred thousand edges and faces and a hundred or so components behaves more smoothly in the interactive mode - a few frames per second, say, which is usable.]

I haven’t tried it in a while, but I occasionally use SketchUp’s native video-export capability and as I recall the native video-export (creating a same-resolution MPEG file) is much faster than Animator’s frame-by-frame video generation. At least 10X faster, probably closer to 100X faster than Animator. Of course, the native video-export is not doing any of the model-transformation steps that Animator does for every frame. Even so, I wonder if the native video-export capability has some frame-generation advantage that is not available via Ruby?

2 Likes

Let me try removing objects for the drawing that are in layers that have been turned off. I did this because I thought it would not consider these objects when rendering but I suppose it makes sense that they are part of the data of the drawing anyway?

I had set up different layer states for the different scenes. It is sad though because now I will have to create like 20 drawing files just to render the video but of that works, then it will be worth it. I’ll do this then post a new video link. Thanks for the help guys. I’ll get this done today.

Just in case, I made a change in the strict case where you generate the video at the SAME resolution as the viewport.

It should go faster for the generation (probably a factor of 3 to 5).

However, if the width or the height of the viewport are an odd number of pixels, then the stitching by FFmpeg will take longer (this because the codec used requires even dimensions and it has now to slightly rescale the image dimensions to an even number of pixels before the generation).

Just download and install LibFredo6 v11.2b, just published.

2 Likes

I don’t think it will make any difference. If an object is not visible, it won’t eat time for the display, whether in interactive mode or when generating the video.

The performance is driven by the Ruby method to transfer the view to a PNG file, which is based

  • Sketchup recalculating the view at required resolution
  • generating the image file
    This can be speedup if you just dump the viewport (i.e. same resolution).
    The time to move of objects and camera is negligible.
1 Like

Wow, I just noticed that toggling off the animator pallet during preview actually helps a lot by itself. If it remains consistent, I can keep recording my screen with OBS which is really fast because OBS creates an mp4 which is what I am using in my video editor and I will not have to separate out all of the other hidden objects. I am still trying to removal of objects and will post a video on this.

Thanks Fredo6 and all for the help. I had such good luck I went ahead an rendered the longest portion of the animation to date and it was around 1,000 frames completed in about 47 mins. I was looking at days before the fixes :slight_smile:

What I did;

  1. Being a new laptop, I optimized the power and video settings for performance. See computer specs below.
  2. I toggled off the Animator Pallet while rendering the video which really seemed to be the key.
  3. I created a separate SketchUp file with only the objects I was rendering. I had many layers with objects because I was saving different layer states/scenes to save views for rendering different scenes which cause the SketchUp file to be very large.
  4. I made sure ffmpeg was located, this is for others who might read this.

In the name of science I know I should have tried each of these one at a time but I am behind on this project so I went for all at the same time :slight_smile: I did see an improvement in previewing the video immediately when toggling off the Animator Pallet when viewing the preview animation.

Anyway, thanks again to all and I hope to continue getting better at animation now :slight_smile:

The computer is an MSI GS75 laptop with an RTX 2060 GPU. My old laptop was the same but with a GTX 1080.

2 Likes

You should reply to the thread in general (button at the bottom of topic) or the original poster if your question is directed at them (ie, using the phrase “your issues”.)

I don’t think you are really paying attention to what was said by the original poster in this thread.

He has said that (screen capture) is exactly what he was and is doing, but using OBS, which is also free and open source.

One last question. Does anyone have any experience configuring ffmpeg? I noticed that even though I just clicked .mp4 in the Animator options, ffmped still rendered a .mov file also. I would think if I could get t to just render the .mp4 that it would be quicker?

I googled this but most of what I found was for the server version where you have to use putty to configure ffmpeg.

MOV is a container format, so is MP4 (although there is also an MPEG-4 video codec, that you not want to use).

Most likely the MOV uses H.264 for the video track compression. Most places that you would send an MP4 H.264 file to will also take an MOV file. You might even get away with renaming the file for programs that understand .mp4 but not .mov.

It’s not FFmpeg generating the MOV file, but your settings in Animator.

There may be a bug in the dialog box for video generation. I will check.

Note that you can modify this even after the generation.

By the way, the MOV file does not take long to generate as this is purely a redecoration of the MP4 file, as Colin said.

EDIT: I found the bug and fixed it. Will go in a next release of LibFredo6. Thanks for signaling.

1 Like