[Steve Bentley]

You might be on the cusp there. I use 15.03 and I still have full access to the QT codecs, but when I went up to >15.1, they vanished. But I don’t know what point rev that was. So I backed off and went back to 15.03.
While Qt is only 8 bit it was such a sweet format for mattes etc because the Animation Best version was RLE and as such, tiny tiny tiny. It was also such a great format to throw around, edit, trim and export in the player, multiplatform compatible, scrubbable, loopable and cha cha in the player, had a good info dialog.

And now that I say all that, with QT being only 8 bit and RGB only (I believe) you might be seeing some LUT conversion from your much expanded and possibly log EXR’s. You just can’t represent all that was in the EXR’s in QT so something’s got to give. A good LUT can get you close but its’ never perfect, especially in the heel and toe of the blacks and whites curves.

[Steve Bentley]

Jim and Brian are correct. Remove this little tag (or change the values) and when you render (remember the view port preview may not look like a full render) your object will be faceted.

[Steve Bentley]

I’m not a fan of encoding from AE (and if I read the error wrong I’ll get to the opposite below). AE is a compositor, not an encoder: its best to send the output to something like Media Encoder. Not only will this help eliminate the problem but you get a better encode too. AE cannot (TTBOMK) do a 2 pass encode because once it renders one frame and lays it down it can’t go back and look at that frame. The best encoders run down the length of the movie and analyze the footage and then use elements (color, movement) from the whole movie to inform each frame’s compress on the second pass.
As AE opens and closes the file it writes to it can run into the same kinds of errors described below that also affect using footage that is compressed as your source. So when it opens the file to write another frame, it attaches that frame to the frame before that isn’t really there, or worse it has to write a frame that the codec would prefer didn’t really exist, or it renders a non keyframe frame where the codec wants a keyframe.

Codecs like H264 and wrappers like Mp4s have what amounts to ghost frames between real frames. (this is massively oversimplified). These ghost frames get their data from the frames around them on playback – it keeps the files small because of the original frames, perhaps only 2/3 are represented in the file and the ghost frames are made up on the fly during playback. But AE steps through each frame in a file when it uses that file as a source so when it comes upon a frame that isn’t really there, it can freak out. Not all codecs are like this. In fact, most footage these days (sadly) is compressed in some way and many work just fine as source for AE, so it’s not an across the board problem.

Even if what’s I’ve written above isn’t the problem, I’ll bet rendering out to another uncompressed format (or as David suggests, to stills) and then encoding in an external encoder should solve it.

[Steve Bentley]

I’m not sure I understand the problem By using the pan behind tool you are moving the anchor point. Usually after you have done that, you move or rotate the object’s position. Then the object will rotate with the new anchor point at the center.
What might be happening is that if you have a position or rotation keyframe already set and then you move the anchor point with the pan behind tool, you can get what can appear to be odd positioning effects.

If you move the anchor point with the values in the anchor point attributes, the object moves so that the anchor point stays in the original position relative to your comp. In other words the values of the position don’t change, why should they, you only changed the anchor point values.
But, when you move the anchor point with the pan behind tool, a little compensation goes on in the background. AE offsets the position values by the same amount so that nothing moves and you don’t have to reposition your footage. (you can do this by hand too using both position and anchor point values – the pan behind is just a single function to what is a dual operation). The problem is if you already have keyframes for position, set to the values before the pan behind compensation, now you will have new values keyframed where you used the pan behind tool and the object will now move over time and it will move over time around its anchor point.

A way around all this is to make the text circle a child of a null or another layer. Then you can move or rotate the child independently of the parent. You can have the parent look after one attribute (rotation say) and have the child do position. Or you can have the parent look after X position and the child look after Y. This is a great solution when have already animated something but now need it to have a different “center” or shift to a different position or scale.

[Steve Bentley]

If you are using 2018, can you really output to a Quicktime? Many of us are lamenting leaving those codecs behind with the latest rev of AE. Whats your secret? Or are you compressing the files out of AE – that could be part (but only part) of the problem.

But, on to your problem:
Check the color profile of the exr’s on their way out of C4D and check your project’s color profile in AE.
Its funny, I was going to post about this the other day (but never got around to it) after a reinstall of C4D, warning the members about EXR’s defaulting to sRGB in C4D’s render engine. Given EXR’s high color-spacey-goodness it seems silly to limit the files to a decades old and very limiting color space.

When you encode your files with a compressor two things are happening: you are clamping many of the colors with a codec (like H264), so that will often “up” the black levels and bring colors close to white right up to full white etc, and, you are no longer looking at the files in AE. With a color profile set in AE, your screen is being fed the files with the colors converted for that profile and may not be letting them through with their original gamut.

There have been some great posts on this forum about color profiles and file interpretation. It can be tedious reading, controversial, and a highly heated topic, but its worth the work so that you can feel confident that what you are seeing in AE is what you are outputting. Its always better to know that a color meets legal standards or is “right” on your system so that you can say to a client with confidence: “Those are the right levels, the other guys at the broadcast house are wrong”

[Steve Bentley]

Many times, purchased 3D assets will not be optimized for the fastest render times or for the package you have transcoded the file to, instead going for the best looking renders (often GI or using specific high-end render engines) and that can massively up the render times.
GI renders are truly stunning when done correctly but are not always needed

Materials included with these assets are often more complicated than they need to be (or have been made complicated because the originating package could pull off an effect natively while C4D can’t) or use displacement instead of geometry. It used to be that a texture was worth a thousand polygons, but these days with displacement shaders, a texture might just make 10,000 polygons during the render stage to gain the detail the material needs – and that tessellation of the geometry happens every single frame of the render – it’s quite time consuming.
While a frame is rendering, look at the bottom left of the picture viewer and see what the processors are crunching on the most.

Learn the basics of lighting and materials, then learn some tricks to fake GI. Things will render soooo much faster. There is nothing like a GI based render but I find it gets used as a big red single render-button crutch for those who want to go from 0 to 100 miles an hour in their learning cycle and skip all the hard work. If you know how something works, you can make it do much more than it was originally designed for.

[Steve Bentley]

David is correct. With one caveat. AE 2018 with any rev higher than 15.03 has many many problems and omissions that happened without warning.
However, after installing that version, we immediately reverted to 2018 R15.03 (or 15.00) – while still a little buggy it’s production stable and still has the codecs you are used to.
There are differences that you may need or want but you must balance that with nerve fraying issues.

[Steve Bentley]

Could it simply be the way your screen is displaying this? Your screen is probably 8 bit so you are missing all the 16 bit goodness that’s truly in the file. The screen’s toe and shoulder of its LUT may be wonky or the screen could have it’s black levels not set correctly.
It could also be color management in AE. (have we covered that yet in the thread?)
I’m not seeing huge issues with the roll off and that’s even after its been jpg’d.

[Steve Bentley]

I couldn’t see the image initially but now I can. Sorry about the obvious, but you never know skill level of the OP.
Do you have any blend functions on that layer? Things like SCREEN and MULTIPLY don’t comp properly over the base comp background. They need a layer down there to do the math with.

What bit depth are you at? Long feathers often have artifacts or banding at 8bit and it can look like an edge.

Is the layer with the mask scaled? You can often be fighting a large feather on large solid that’s been scaled down. A 1000 pixel feather might not be big enough even then.
Try making another solid the size of the comp and putting the mask on it, feather it and then pass the original through the new masked layer with a track matte set to alpha – does that fix it?

[Steve Bentley]

I wonder if its your graphics card that’s complaining and not the computer – as soon as you said raytracing, an alarm went off in my head.

The more ram the better – used to be AE would only use about 6 Gb no matter what you had on board. But now, finally, I can slam all my procs and all the ram. Who needs a furnace in their house when you have AE!