[David Coiffier]

Hi Justin,

You’re doing nothing wrong. The jitter is from the way comp picture is sent to the Kona3.
At every frame, when ram previewing, AE sends a picture to the video board. This is not a movie file that it sent, but a single frame…every frame. This is something like trying to drive fast, but with a need to stop every 10 meters…Sending pictures the Kona board just breaks up the ram preview, causing sluggish frame rate.

The preview option is more something like a handy feature, when color timing, or anything that doesn’t require real time. Use Kona preview only when needed, or if you prefer : turn it off when you need real time preview.

[David Coiffier]

Tracking data is basically a 2 dimensions data. X & Y are anyway the only axis to be used on the flat 2D moving picture you’re tracking.

Your problem comes from the Z axis : the depth. Try to visualize your tracking path. It moves flat in the XY plane. Now, you attach this path to a 3D null, and push the null far away on the Z axis : Your tracking path is now also far away, and smaller than before, because of the fied of view (or perspective). It’s not related anymore with the path you’ve computed before, as the whole path has now moved in the distance, while the footage you’ve extracted tracking path from didn’t move accordingly.

To be simple, attaching a 3D layer to a tracking path only works if Zposition=0. You can still use 3D rotations, but not the Zposition. Try using scale parameter, as a Zpos alternative, since Zpos is essentially a scale factor.

Hope it helps

[David Coiffier]

Orientation is indeed one parameter for 3 axis, as well as position is…
Still, you can use individuals XYZ rotation parameters, instead orientation, but it doesn’t solve the position issue.

In AE, you can manage independently speed and path. In fact, this is what causes you troubles.
As speed and position are independent, the only way to relate one parameter to the other, is by defining speed as the kinetic movement of a trip onto the path (the positions).
Let’s take cars and roads : you can build whatever road you want, drive as fast as you wish, do whatever you could dream of with a car : you only have one speed parameter : the car speedometer.

So what you’re looking for, controlling independent speed params to achieve perfect movement, will not be found in the position f-curves, but in the spatial path…

Hope it helped…

[David Coiffier]

Does the jitter occur on video monitor or even on your computer screen ?
If that’s only on video monitor, it’s prolly related to interlace flicking, because of the thickness of your toon lines.
If it’s also on the computer screen, then it’s more something like too fast mvt, or 3D being rendered without any motion blur. Did you render motion blur in Maya ?
If you didn’t, and don’t have time to rerender, then you could use an intelligent motion blur plug, like Furnace motion blur (I’m not sure it is available for AE, as I use it from Shake), or equivalent…

[David Coiffier]

I’ve experienced such issue recently…
I’m running AE 8.02 on a brand new MacPro 8core, with a 10.5 OS
I’ve been running a quad G5 (10.4) for years and years, and I’m absolutely sure this bug never happened on my G5, on the very same 8.02 version. So it may have something to do with intel macs only.

Are you running mac ?
If answer is yes, you’re prolly on an intel one…
(and if answer is no, you’re also prolly running an intel chip!)

I think I managed to identify what makes AE becoming mad with DOF :
As soon as I use 3D layers, in a non trivial position (as soon as I my layers request 3D advanced renderer if I assume well), I get that issue, with small dots like sand particles, printed on one of my layers.

Adobe ? Someone ?

[David Coiffier]

Hi guys,

Here in Europe, I’ve experienced such problems.

This spring I had a project in DVCPROHD 1080, on FCP 5.11
I did export the whole sequence in a single file without recompressing, just flattening.

This summer I had another project in same format, and also same kind of export, but this time with FCP 6.01

When reimporting, file is interpreted as square 1920 pixels wide, and FCP asks for rerendering. I tried to reimport my first export (came out of FCP5) and this one is correctly interpreted as a 1440 with a 1.33 aspect ratio. FCP6 just plays it smoothly, and my Kona3 is also able to downconvert it in real time.

So my understanding is that something is going wrong when exporting from FCP6 or with QT 7.2 (where support for non interlaced DVCPROHD has been added)

When opening both files in QT player they strictly look the same, and all info I can get are equivalent. But when importing in AE7 for ex, one is 1440 1.33 aspect, and the other 1920 square aspect. So it seems it’s definitely a pb with tags contained in the quicktime file itself.
As DVCPROHD CANNOT be a 1920 wide file, but only 1440 (at 25FPS) something is badly reported to the QT file, and FCP or any QT compatible application freaks out when using such file…

I guess it should be reported to Apple, as they are the only ones able to fix this…

[David Coiffier]

It sounds like a low sampling/filtering quality on color channels.
It is surely because of the DV codec, as all DV codec are YUV, and 4:1:1 sampled, meaning you have only 1/4 of the data used to code color infos.
DV is well suited for real life shooting, where nothing is deeply saturated, and where you have no uniform color BG.
About filtering, it really depends of your codec. Some always filter color channels, some never do, and some others allow you to activate filtering or not.

Try an uncompressed, or a RGB compressed (jpg for ex) codec to see if problem is resolved.

I guess there is no turnaround to get a clean CG picture with colored BG with a DV codec…