When rendering animations with motion blur, all is well for the first 90% of each frame. This is when UF is calculating the fractal and antialiasing. The four CPU cores are maxed out and the CPU is 0% idle, as shown below on Activity Monitor.

6371356a71a81.jpg

But then comes the final 10% of the frame, which is when motion blur is being calculated. UF suddenly gets a lot slower. The CPU is 70% idle. The two physical cores are about 50% idle and the other two cores are are not being used.

637134cc71f55.png

I’m using motion blur because it looks great in animations but it’s very slow. Renders which take hours without blur require days with blur. It’d be really great if motion blur used hyperthreading and ran at 100% speed instead of only 30%.

Thanks much.

When rendering animations with motion blur, all is well for the first 90% of each frame. This is when UF is calculating the fractal and antialiasing. The four CPU cores are maxed out and the CPU is 0% idle, as shown below on Activity Monitor. ![6371356a71a81.jpg](serve/attachment&path=6371356a71a81.jpg) But then comes the final 10% of the frame, which is when motion blur is being calculated. UF suddenly gets a lot slower. The CPU is 70% idle. The two physical cores are about 50% idle and the other two cores are are not being used. ![637134cc71f55.png](serve/attachment&path=637134cc71f55.png) I’m using motion blur because it looks great in animations but it’s very slow. Renders which take hours without blur require days with blur. It’d be really great if motion blur used hyperthreading and ran at 100% speed instead of only 30%. Thanks much.

http://www.youtube.com/fractalzooms

edited Nov 13 at 8:11 pm
 
0
reply

Can you test if this also happens when using non-adaptive AA?

Ultra Fractal's AA tries to be smart, which greatly reduces the rendering time in many cases (and can sometimes introduce other weird problems in turn). If your image has very small areas where UF deems AA to be necessary, then very few threads would be left processing just a bunch of nastily slow pixels.

However, motion blur could increase those areas by "smudging" them along the direction of motion but still within just a few threads or - from what it looks like in your example - even just one thread. If they are still small enough to not being broken into multiple threads, i.e. less than 16 pixels wide if I remember correctly, this could explain the behavior you are seeing here. Relatively fast motion along the x-axis of the screen space would do this.

If you force AA over the entire image, motion blur should have no effect on render time, hypothetically. I'd love for Frederik to clear it up if my assumptions are wrong.

Phillip

Can you test if this also happens when using non-adaptive AA? Ultra Fractal's AA tries to be smart, which greatly reduces the rendering time in many cases (and can sometimes introduce other weird problems in turn). If your image has very small areas where UF deems AA to be necessary, then very few threads would be left processing just a bunch of nastily slow pixels. However, motion blur could increase those areas by "smudging" them along the direction of motion but still within just a few threads or - from what it looks like in your example - even just one thread. If they are still small enough to not being broken into multiple threads, i.e. less than 16 pixels wide if I remember correctly, this could explain the behavior you are seeing here. Relatively fast motion along the x-axis of the screen space would do this. If you force AA over the entire image, motion blur should have no effect on render time, hypothetically. I'd love for Frederik to clear it up if my assumptions are wrong. Phillip
 
0
reply

Hi Phillip. Thanks for the suggestion and the tip about how UF does antialiasing.

I gave this a shot, but unfortunately I got the same results. The screenshot below is with nonadaptive AA and motion blur on. The CPU is 70% idle during motion blur. Half the CPU cores are idle. The rest of the CPU cores are only about 50% used.

6372a5e0604ac.png

For comparison, the screenshot below is also with nonadaptive AA but this time motion blur is off. All cores are now maxed and the CPU is 0% idle.

6372a55c6fd24.png

Hi Phillip. Thanks for the suggestion and the tip about how UF does antialiasing. I gave this a shot, but unfortunately I got the same results. The screenshot below is with nonadaptive AA and motion blur on. The CPU is 70% idle during motion blur. Half the CPU cores are idle. The rest of the CPU cores are only about 50% used. ![6372a5e0604ac.png](serve/attachment&path=6372a5e0604ac.png) For comparison, the screenshot below is also with nonadaptive AA but this time motion blur is off. All cores are now maxed and the CPU is 0% idle. ![6372a55c6fd24.png](serve/attachment&path=6372a55c6fd24.png)

http://www.youtube.com/fractalzooms

 
0
reply

I just tested this on my latest anim and here's the CPU load while rendering the first frame, those drops happen every few seconds and my load drops down a lot more. I have 24 threads, so it would make sense if some single core stuff is happening:
6372dd3db0a6f.png
So it's not the AA then, which begs the question: what is going on?

I'd be surprised to learn that UF does the motion blur in some kind of post-render step because the information for it needs to come from rendering pixels that are offset in time rather than space. How does UF sample in time, if at all? Lycium taught me some anti aliasing stuff over this year and one of the things he mentioned is that motion blur is essentially just AA along the time coordinate. Not sure how this would slow down rendering to single core though.

Here's the view per logical CPU core, it's a 4s drop every 12s roughly:
6372df88a5203.png

Here's what it looks like with no motion blur, I still get a 1s drop on all cores every 10s:
6372dee44d9e3.png

Just to dig a bit more, I tried the following things:
Make a non-animated still of the same fractal -> lots of similar drops in CPU load
Increase iterations from 54 to 5444 -> drops get significantly smaller
Zoom into this last one to eliminate any cheap outside pixels -> drops disappear

This last results holds even if I go back to my animation with motion blur, but zoom in so it's 100% inside and then increase the iterations. So this seems to be related to overhead while calculating pixels that don't require lots of iterations, maybe it's when UF redistributes the pixels among threads when one of them finishes or something of that sort. I can only guess here.

I just tested this on my latest anim and here's the CPU load while rendering the first frame, those drops happen every few seconds and my load drops down a lot more. I have 24 threads, so it would make sense if some single core stuff is happening: ![6372dd3db0a6f.png](serve/attachment&path=6372dd3db0a6f.png) So it's not the AA then, which begs the question: what is going on? I'd be surprised to learn that UF does the motion blur in some kind of post-render step because the information for it needs to come from rendering pixels that are offset in time rather than space. How does UF sample in time, if at all? Lycium taught me some anti aliasing stuff over this year and one of the things he mentioned is that motion blur is essentially just AA along the time coordinate. Not sure how this would slow down rendering to single core though. Here's the view per logical CPU core, it's a 4s drop every 12s roughly: ![6372df88a5203.png](serve/attachment&path=6372df88a5203.png) Here's what it looks like with no motion blur, I still get a 1s drop on all cores every 10s: ![6372dee44d9e3.png](serve/attachment&path=6372dee44d9e3.png) Just to dig a bit more, I tried the following things: Make a non-animated still of the same fractal -> lots of similar drops in CPU load Increase iterations from 54 to 5444 -> drops get significantly smaller **Zoom into this last one to eliminate any cheap outside pixels -> drops disappear** **This last results holds even if I go back to my animation with motion blur, but zoom in so it's 100% inside and then increase the iterations**. So this seems to be related to overhead while calculating pixels that don't require lots of iterations, maybe it's when UF redistributes the pixels among threads when one of them finishes or something of that sort. I can only guess here.
edited Nov 15 at 12:57 am
 
0
reply

24 threads. I’m drooling over here. Kind of you to suppress any get-a-real-computer snark.

I’m still rereading your reply and pondering the implications but the main thing I notice is that your virtual cores are actually being used. That doesn’t seem to be happening for me, so I thought the problem was basically lack of hyperthreading. And I hoped it could be fixed by just changing the “use hyperthreading” variable in the code.

Your cores are also at 100% most of the time. For me, the cores in use average 50% and don’t seem to get above 60%. We’re using different monitoring apps but this is still weird.

I have another Intel Mac with a faster CPU arriving this week which I can test later. My only other Mac now is an M2 which doesn’t have virtual cores.

Lycium. I remember that guy. Talked with him when I was on the UF mailing list like 15 years ago. Good animator. “Motion blur is essentially just AA along the time coordinate” is now something I will probably spend the next 24 hours trying unsuccessfully to get my head around.

24 threads. I’m drooling over here. Kind of you to suppress any get-a-real-computer snark. I’m still rereading your reply and pondering the implications but the main thing I notice is that your virtual cores are actually being used. That doesn’t seem to be happening for me, so I thought the problem was basically lack of hyperthreading. And I hoped it could be fixed by just changing the “use hyperthreading” variable in the code. Your cores are also at 100% most of the time. For me, the cores in use average 50% and don’t seem to get above 60%. We’re using different monitoring apps but this is still weird. I have another Intel Mac with a faster CPU arriving this week which I can test later. My only other Mac now is an M2 which doesn’t have virtual cores. Lycium. I remember that guy. Talked with him when I was on the UF mailing list like 15 years ago. Good animator. “Motion blur is essentially just AA along the time coordinate” is now something I will probably spend the next 24 hours trying unsuccessfully to get my head around.

http://www.youtube.com/fractalzooms

 
0
reply

24 threads. I’m drooling over here. Kind of you to suppress any get-a-real-computer snark.

I worked on 4c/8t for ages and only upgraded to such a beast because I won some money, but always glad to see a not-so-subtle flex land. smile

Jokes aside, I don't think there's anything wrong with your setup or CPU or even your fractal. Try the following:

  1. open a normal mandelbrot set
  2. activate some kind of inside coloring
  3. set iterations to 5000
  4. turn of periodicity checking
  5. zoom in so all pixels are inside.
  6. render the image and look at your CPU load

I would just give you params to paste but I'm at work. If my suspicions are correct, your CPU load should be a lot more consistent.

> 24 threads. I’m drooling over here. Kind of you to suppress any get-a-real-computer snark. I worked on 4c/8t for ages and only upgraded to such a beast because I won some money, but always glad to see a not-so-subtle flex land. :D Jokes aside, I don't think there's anything wrong with your setup or CPU or even your fractal. Try the following: 1. open a normal mandelbrot set 2. activate some kind of inside coloring 3. set iterations to 5000 4. turn of periodicity checking 5. zoom in so all pixels are inside. 6. render the image and look at your CPU load I would just give you params to paste but I'm at work. If my suspicions are correct, your CPU load should be a lot more consistent.
edited Nov 15 at 2:41 pm
 
0
reply

Yesterday was new computer day. Still setting it up but I tried the test in your reply on the same old MacBook I’ve been using in this thread. Same results as before.

637561780c1fe.png

63756198439a2.png

phillipThreadsTest {
fractal:
  title="phillip threads test" width=1000 height=1000 layers=1
  frames=10 frame=10 fps=1 credits=""
layer:
  caption="Background" opacity=100 transparent=yes
mapping:
  center="-0.0968944101/0.0223602484@#0SS-0.08612189457/-0.00328998451\
  @#43200" magn="2@#0SS8@#43200E"
formula:
  maxiter=5000 percheck=off filename="Standard.ufm" entry="Mandelbrot"
  p_start=0/0 p_power=2/0 p_bailout=128
inside:
  transfer=linear filename="Standard.ucl" entry="DirectOrbitTraps"
  p_trapshape=point p_diameter=1.0 p_traporder=4.0 p_trapfreq=1.0
  p_trapcolor=distance p_threshold=0.25 p_startcolor=4278190080
  f_trapmergemode=normal p_trapmergemodifier=none
  p_trapmergeopacity=0.2 p_trapmergeorder=bottom-up p_trapcenter=0/0
  p_aspect=1.0 p_angle=0.0 p_solidcolor=no
outside:
  transfer=linear filename="Standard.ucl" entry="Smooth" p_power=2/0
  p_bailout=128.0
gradient:
  smooth=yes rotation=1 index=0 color=6555392 index=64 color=13331232
  index=168 color=16777197 index=257 color=43775 index=343 color=512
opacity:
  smooth=no index=0 opacity=255
}

I want to see what happens on the new Mac but I’m wondering whether this works for you because you've got the Windows version.

Yesterday was new computer day. Still setting it up but I tried the test in your reply on the same old MacBook I’ve been using in this thread. Same results as before. ![637561780c1fe.png](serve/attachment&path=637561780c1fe.png) ![63756198439a2.png](serve/attachment&path=63756198439a2.png) ```` phillipThreadsTest { fractal: title="phillip threads test" width=1000 height=1000 layers=1 frames=10 frame=10 fps=1 credits="" layer: caption="Background" opacity=100 transparent=yes mapping: center="-0.0968944101/0.0223602484@#0SS-0.08612189457/-0.00328998451\ @#43200" magn="2@#0SS8@#43200E" formula: maxiter=5000 percheck=off filename="Standard.ufm" entry="Mandelbrot" p_start=0/0 p_power=2/0 p_bailout=128 inside: transfer=linear filename="Standard.ucl" entry="DirectOrbitTraps" p_trapshape=point p_diameter=1.0 p_traporder=4.0 p_trapfreq=1.0 p_trapcolor=distance p_threshold=0.25 p_startcolor=4278190080 f_trapmergemode=normal p_trapmergemodifier=none p_trapmergeopacity=0.2 p_trapmergeorder=bottom-up p_trapcenter=0/0 p_aspect=1.0 p_angle=0.0 p_solidcolor=no outside: transfer=linear filename="Standard.ucl" entry="Smooth" p_power=2/0 p_bailout=128.0 gradient: smooth=yes rotation=1 index=0 color=6555392 index=64 color=13331232 index=168 color=16777197 index=257 color=43775 index=343 color=512 opacity: smooth=no index=0 opacity=255 } ```` I want to see what happens on the new Mac but I’m wondering whether this works for you because you've got the Windows version.

http://www.youtube.com/fractalzooms

 
0
reply

And it just gets worse. The new Mac is almost 90% idle during blur and the virtual cores are still unused. This is an i7 Mac mini. The previous tests were with an i5 MacBook.

63757e869e567.png

63757e954e522.png

And it just gets worse. The new Mac is almost 90% idle during blur and the virtual cores are still unused. This is an i7 Mac mini. The previous tests were with an i5 MacBook. ![63757e869e567.png](serve/attachment&path=63757e869e567.png) ![63757e954e522.png](serve/attachment&path=63757e954e522.png)

http://www.youtube.com/fractalzooms

 
0
reply

At the risk of asking a dumb question: how do you know this is "during motion blur"? I can't find anything indicating which part of the calculation was being done.

At the risk of asking a dumb question: how do you know this is "during motion blur"? I can't find anything indicating which part of the calculation was being done.
 
0
reply

Good question, actually. I should’ve provided a reference for that.

Ultra Fractal performs motion blur when rendering (a part of) an animation. The last 10% of the progress is reserved for motion blur

https://www.ultrafractal.com/forum/index.php?u=/topic/564/rendering-single-frame-of-animation/post-1612#post-1612

This is why I keep putting the UF Render window in my screenshots. When UF slows down and the virtual cores go idle, it’s during that 90%-100% part of the frame.

Good question, actually. I should’ve provided a reference for that. >Ultra Fractal performs motion blur when rendering (a part of) an animation. The last 10% of the progress is reserved for motion blur https://www.ultrafractal.com/forum/index.php?u=/topic/564/rendering-single-frame-of-animation/post-1612#post-1612 This is why I keep putting the UF Render window in my screenshots. When UF slows down and the virtual cores go idle, it’s during that 90%-100% part of the frame.

http://www.youtube.com/fractalzooms

 
0
reply

Oh... then the problem is a lot worse than I thought. It means that motion blur is applied in a separate step instead of during the render.

Oh... then the problem is a lot worse than I thought. It means that motion blur is applied in a separate step instead of during the render.
 
0
reply
96
views
10
replies
2
followers
live preview
Enter at least 10 characters.
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
All posts under this topic will be deleted ?
Pending draft ... Click to resume editing
Discard draft