Moho Forum

Check out these two testrenders (go to youtube and use HD mode and full screen to see more clearly what's happening).

The background is a jpg-image, the rectangles are vector shapes.

When rendered in multithreaded mode it looks like this.
Look closely and you can see that the background image is vibrating, making
the exported clip totally useless for HD production.
(you need to open the clip full screen to be able to see the vibration)



When multithreaded mode is off, the render works OK.
Like this:



Does anyone know if there is a way to avoid this problem - without having to
switch multithread rendering off?

I can't see the problem. Both clips appear identical to me. I even got up real close to the full screen monitor and hit play over and over. No vibrations I can see at all.

-vern

heyvern wrote:I can't see the problem. Both clips appear identical to me. I even got up real close to the full screen monitor and hit play over and over. No vibrations I can see at all.

Really?

It's small, but it's there, in the first clip.
(the second clip is as it should be, no distorision)

If you look at the white fence in the middle of the screen you should see
a pulsating motion, the backgorund image oscillating sideways 2 or 3 times
every second, only 1 or 2 pixels - but that's enough to be disturbing.

Ok, I see it now. I had to stand with my face up against the screen and hit play over and over. It was not obvious but there is some subtle movement. It's not over the entire fence, only a small section in the middle correct? It could be that Youtube isn't the best way to see this bug.

Yeah, well, as I said you need to look in high resolution to really notice it.
But it looks really terrible on an HD screen...

And I would like to be able to render in multithreaded mode.......

I sent a support ticket to SM about this. Hope they'll figure it out for ASP9.

Sorry I didn't post before, I only just saw the topic.
This has been a great problem for me, I can see it clearly , it stick's out like a sore thumb.
I had to do a piece for a cinematic release that was terribly plagued by this problem and believe me at high res on a big screen it is really REALLY obvious.
You can cut out multi-threading but that isn't the only contributor,that can occur with z depthed layers and or particles and or layer blending modes it is a complex problem that SM are very aware of and to their credit have tried very hard to find a solution.
It does not happen for most situations but if the scene starts getting very complex, it will rear its very ugly head, it is totally weird and even though I was playing in the firing line of this issue for many months I could not predict exactly when it would occur or find an infallible method to avoid it.

I am sure there will be a solution one day but for now it is a really scary problem especially if your work is professional and high resolution.
The only way to sure avoid it is to keep everything as flat as possible and avoid z depth and images altogether which unfortunately does make many of AS most interesting features all but redundant.... Oh how I wish I had no reason to say that .
That or just be really lucky.

chucky wrote: You can cut out multi-threading but that isn't the only contributor,that can occur with z depthed layers and or particles and or layer blending modes it is a complex problem that SM are very aware of and to their credit have tried very hard to find a solution.
It does not happen for most situations but if the scene starts getting very complex, it will rear its very ugly head, it is totally weird and even though I was playing in the firing line of this issue for many months I could not predict exactly when it would occur or find an infallible method to avoid it.

.../ The only way to sure avoid it is to keep everything as flat as possible and avoid z depth and images altogether which unfortunately does make many of AS most interesting features all but redundant....

Oh shit.

This is bad news. I'm in an HD production right now and this kind of problems I didn't expect... I really hope that Mike and the guys at SM sort this one out.

But big thanks for the info, Chucky !
It's always good to be aware of the limitations of any tool.

I ran into this error when rendering Particles with the "play random" option. This looks nice in the timeline, but when rendered with the multithread option, the particle animation jitters badly. It seems to pick random timeline values for each frame. Luckily, this can be avoided by deselecting multithread.

This should be fixed obviously, but for those in production who need a solution, could this be overcome somewhat by using instances of AS running on different processors and doing long sequences of frames? Like instance 1 does frames 1-100, 2 does frames 101-200, etc. Then the jitter would not occur "all the time" only every set number of frames, and you could still use multiple processors to speed up renders.

-vern

So are you saying, Vern that it's the length of the render/animation that bogs down AS and causes the wiggle?. Does this mean that breaking into batches might also work?

No chucky,

My thought was the wiggle doesn't happen if you use ONE PROCESSOR during rendering. So, obviously something is changing in the data when it's every other frame is sent to another processor. One proc gets frame 1 the next one gets frame 2 the next 3 etc etc.

So, with instances of AS, a block of frames all go to the same processor which would be like rendering WITHOUT multiprocessor for that larger block of frames. Then if there is a data change that "wiggle" will only show on one frame between the blocks and might not be as bad.

Of course this technique would require exporting to images or stitching together movies later plus all the aggravation of having multiple instances of AS open using all the ram.

-vern

I know this an older thread...but I am in a bit of a crunch.

Did this ever get resolved yet? I think this a BIG issue.

If I disable multi-threaded rendering by unchecking the "enable" check box, I still get the shivering effect. I also tried exporting to version 9.5 and rendering it in that version and the shivering is still there.

I tried rendering as a series of images and it appears that every few images there is one that is slightly shifted and really pixelated. Even the "normal" images are slightly pixelated. If I render the jittering frame using Ctrl + R, it renders normally...

Apparently it renders perfectly on my windows 8 machine... That's a relief. But also not going to be a viable workaround for everyone.