[Steve Bentley]

Actually I hadn’t thought of that (deformer). Good idea. I’ll just stick a script in there that I can turn on and off all of them with a single button.
Cheers

[Steve Bentley]

Right.
I think I see the problem. I’ve got some fairly high poly geom inside the cloner that I thought would be visually tesselated down by a LOD tag on the child iteself. And I was also disapointed that the global LOD turned off entire clone chains instead reducing individual object complexity etc.
What I’ve only now thought to try is to check to see if the project level LOD works on my base geometry – it does not. So what exacly is the criteria for detail reduction in the LOD function? Does it only work on parametrics? (my stuff is mix of poly and “live” parametric objects but I’m not seeing a reduction in detail in either.)
If not number of poly’s in the view port, what “detail” is actually being reduced? Is it only able to reduce the number of objects?
I would have thought a great use for the LOD is to speed up interaction in the viewport and to do that the system would only display ever nth poly or vertex – that sort of approach. I didn’t think it would work by displaying every nth object.
Have I just been thinking about this wrong? I’m just looking to speed up the redraw as I need to scrub to check interactions etc but I end up getting a blank viewport until I stop moving the playhead.

[Steve Bentley]

Hi Brian,
Thanks for that. I did try a display tag on the child inside the cloner without reasonable results and a display tag on the cloner itself. I do want simpler clones with all the clones showing. But I’ve been unable to find the right combo to get that done.
Is there another way besides the display tag?
I figured the level of detail would reduce the geometry shown, not eliminate entire objects.

[Steve Bentley]

True but that depends on the type of file you render out – EXR’s for instance package all the passes into one file and they can be buried and need to be extracted even with a saved AEC.
We’ve also found that sometimes we get lazy and don’t specify an RGB pass but it renders anyway. Then, of course, as deadlines loom, but after not specifying has become habit, we’ll have gotten used to this and render only to find that the RGB pass isn’t there. So there is still some flakeyness on how cinema packages all that up.

Glad that worked out.

[Steve Bentley]

So you can tell premiere to ignore the alpha and that should do it

[Steve Bentley]

Woops – that should have been vs the viewport in C4d.
That render you have on the right looks perfect (reflection and phone in one). If you “screen” your content right on top of that it will look right.

[Steve Bentley]

Don’t use “add” by the way as that that can produce results above 100 percent white and the you get clipping.

[Steve Bentley]

Depending on how you rendered your multi pass the reflections might be buried in the file. You can down load the free extractor plugin for AE and pull the different passes from that.

But really, just render the phone with a black screen and reflections in one pass and then “screen” the screen image you want on top in AE.
There is definitely something off with how cinema makes reflections look in a multi pass vs how you can make it look in AE vs how it looks in the viewport of AE. Some of it has to do with the color space of the view port and some has to do with how c4d combines highlights vs how you can do that in AE.

[Steve Bentley]

H264 is old and buggy? Since when? Sure its been superseded by 265 for HD but I guess you better tell youtube they better stop what they are doing because thats pretty much the most prevalent codec going. (remember mp4s are just a 264 in a wrapper as are flv and fv4s)
It’s not a great idea to edit with 264s but it’s less about the codec and more about the “B” frames that aren’t the discrete frames AE likes. This is the case with any compressed footage not just H264.

But you are right, it is not a good idea to render your compressed codec out of AE. To get the best out of a codec like 264 you should do a 2 pass compress where the codec goes and looks at all the footage and the decides how best to crunch it. The codec cant’ do that in AE because it renders one frame and then moves on and never goes back.
So render out of AE in some uncompressed format – either stills like tiffs or pngs or in AVI or Quicktime uncompressed. Then pass them through an encoder like adobe encoder or windows Expression encoder or even export from Quicktime pro and there you can do your H264 or WMV format output for compressed viewing.

But on to the main question: When you compress you are loosing colors (Ok you experts, i know this isn’t exactly true but for this purpose, just go with it). So the higher the compression on the file (and the smaller the file size) the more the codec has approximate the colors you intended.
Inversely, the higher you put the bandwidth setting the closer you will get to your colors.
The more motion you have in your animation the more that uses up bandwidth you could otherwise be using for accurate colors. The same goes with frame rates. You can get more out of your colors with the same bandwith but with fewer frames per second. In some compressors you can say favour motion or favour colors. But again you cannot do this straight out of AE.
Baseline codec throughputs for H264:
1000kb per second (thats kilobits) Pretty crappy Good for slow internet connections and actually not bad for running live footage but graphics-only really suffer.
5000kb Pretty good average across the board for web graphics etc – banding will occur but it’s not too bad (blues band the worst)
10,000kb. Really good. At the limit of some media players and probably to big for the web. Some banding and artifacting depending on motion and complexity.
25,000kb-29,000kb This is what blue rays are compressed at. But keep in mind that often when they master these they will compress each edit separately so that they get the best “color pallet” for each edit. If you went from a very blue scene to a very yellow scene and compressed them both in one movie you split the colors available across both scenes thereby reducing the color accuracy overall.
(Again, for you nitpickers, I know this isn’t how it works but I think it’s a pretty good metafor for this particular case)

So if you let an encoder compress this after AE and there is a background color that has to match something else, because there is so much of it the encoder will run down the length of the file and see how much there is and it will decide that color is pretty important and weight what gets the color appropriately.

[Steve Bentley]

Probably the best way is to do a multi pass render. that way the reflections (the only thing that will be “above” the screen image, will be a separate layer you can screen over your image in your 2D app.
The screen area should be black in your 2D app.

The other way is to just render a black screen with reflections. Then use a screen blend or transfer function to put the screen image in. Reflections are all ways additive so it doesn’t matter if the image is above the reflection or visa versa – as long as the base color is black.