[Steve Bentley]

I think the problem is that the “visible” side cannot always face camera because it will always be on a perspective angle between the far circle and the front circle. The beam layer, made 3D, is just a flat plane that has been angled back, so its Z vector is pointing up (or down) and to the right or left. If if always faced camera it would never have any perspective – the planes “normal” would always point dead into the lens.
What’s happening in your case is classic gimbal lock – as an object rotates in two axis, at some point the angles add up to an angle AE will want to represent another way and the object will flip. And you can end up viewing that object edge on – which is why its disappearing (the Beam effect has no thickness)

Trapcode’s 3D stroke would solve this. TC3D strokes have thickness. You apply the strokes to a 2D plane and then the render engine puts them in as close to true 3D as you can get in AE. And you can connect the ends of the “beams” via expressions to the anchor points of any 3D planes and they obey both motion blur and DOF rules in AE. But it costs of course.

I just tested Video Copilots Saber plug in (its free). You can get it to do the same through toWorld expressions because the beam is only 2D (like the Beam effect) but with it being only 2D (but looks 3D) you can’t easily do the DOF.
What about using a DOF map generated by your scene but used in another comp to get the blur on just the beam itself?

I’m trying to think of a way to have the beam layer point at something else in the scene so that its face is always visible “face on” even though its on an angle to the camera. Think of a cone – the tip is connected to the front most circle and the back most circle is connected to the outer edge of the circular base of the cone. The beam plane would lay along the surface of the cone with the normal of the beam plane aligning the cone’s angled surface normal.
Since you are animating the two hero circles you could add a 3D null and have the beam plane point at that, and then just animate the null in 3D space at the same time you animate the circles (or the camera) to keep the plane’s face at a decent angle to the camera.

[Steve Bentley]

The SWF (shockwave) player is still downloadable – its no longer under development but it still works on the mac. You can also open the files in some browsers (but not usually chrome).
I wouldn’t be surprised to find the tutorials from that long ago now free on Andrews site and in an updated format.

[Steve Bentley]

My last post got delayed somehow but was composed before your last.
Re red and blue lights. Do you mean actually red and actually blue? or just their color temp (3500 k vs 6500k perhaps?)
The green screen looks good to me (save the uneven lighting, but often that is unavoidable, and easily dealt with as we have discussed, especially with no action at the edges and good garbage matte will fix the lighting flags etc).
Having more red on the talent is a good thing because that will increase the separation required from the green and also helps to offset the green spill from the screen itself. If the lights were used the other way around it might not turn out as well.
Double check for noise in the reflective surfaces like the photocopier on the left. Normally we would use the green sheen to push in color from the background but with the noise problem I would just crush the matte in these areas and let it be.
Large files are the cross we VFX types have to bear. The larger the file, the easier the key, so the time spent transferring files is saved in the composting.
The main issue is that compression. All other considerations seem to be well within specs for pulling a decent key.
More light though will reduce the voltage injected into the camera chip -which is what causes the noise – more light=less noise. Less noise coming from the camera also reduces the compression artifacts – the more noise the codec sees the more averaging it has to do.
But even though you might be able to get more lights, don’t overexpose – shoot for that color of green in camera – it’s pretty much spot on.
There are also some fallacies out there that the talent should be over or under exposed. Neither is true. The talent should be perfectly “exposed” as should the background screen. This old optical technician’s wife’s tale is probably from that optical era, when every step of the process added noise and contrast. (ah I remember it well – I love the smell of developer in the morning!)

[Steve Bentley]

Perhaps sony means that the bigger chip lets them get more tech in there, but on the surface: a bigger area to fill means you need more light to fill it (unless I missed the current administration cancelling the inverse square law).
If you shine a projector at the wall, the bigger you make the image, the dimmer that image gets.

But the problem remains: using that DSLR for regular shooting may be fine, but when it comes to FX work, often you need a better solution. Even in the film world we use a special stock (different from what they used in principle photog) when doing fx work to reduce grain so we can pull out the details we need. And when budget allows, even a special camera that lets us have a larger film frame, and therefore a smaller grain structure per square inch of image area when transferred to digital.

Then there’s the file fomat the camera spits out. I don’t think the camera noise is killing you (and we have noise killers that can overcome that), its the compression artifacts. When you get right down to it, compression artifacts are little areas of the image that are approximations of what should be there. If you can get that compression “block” small enough you end up with pixels: as close as you can get to an accurate rendering of the original. But as the blocks get bigger (and to keep bandwidth low the blocks are always bigger) they just average what they think is important. And that averaging happens every frame (or worse every, keyframe). The idea is: don’t change the pixels between keyframes if nothing in that area is moving. This is a great way to save drive space but a lousy way to have a clean image. So you end up with details jumping around as the system re averages what its seeing.
Often these cameras will have a digital out: you can plug in your computer or drive and capture or record a higher bandwidth master for VFX work. Even the big sony cameras compress the image to a tape. But the feed off the back is a glorious, nearly uncompressed, 10-16 bit version, far superior to what’s on the tape from the very same camera.
Rule of thumb: don’t digitize after the fact; capture live as uncompressed as you can.

[Steve Bentley]

You may need to turn on the continually rasterise button (the sun icon) on the precomp layer to make it calculate every frame of the outer comp and not just the keyframes of the inner comp.

[Steve Bentley]

Here’s a go at it with native effects.
First, in this image you can see the problem with lighting. There is a halo where the keyer has been tuned to the color right around the head but then another key must be done for the area near the frame edges where the green is darker. I have not bothered to do that in this comp and will leave that for you.

We’ve tried all sorts of tricks but it comes down to simply crushing the matte to get rid of the of the jittering edges. Noise is noise (especially compression noise). As helmet heads go this one’s not too bad, but its not quite there in my books.
Here’s the comp (AE2017)and a final output of 5 seconds worth.

The other issues with crushing the key are that you get what we call keyholes: areas where two objects come close together and the matte tends to close up before they actually touch (his hand on the photocopier for instance) or you get rounded corners instead of sharp ones (his armpit). This is solved by doing one key for the head that gets crushed as I’ve done here, and then another for areas that are not as noisy but with less key crushing, and then another key for the outer darker screen areas.

12398_cowgreenscreenproblem.aep.zip

12399_test2264.mov.zip

[Steve Bentley]

If you don’t need the final at 50fps (which I doubt you do) bringing it down to 25fps will half the “boiling” of the hair (yes, that is the technical term for the problem, really!)
Still playing

[Steve Bentley]

Been looking at the footage.

I think you are suffering from the quality of the camera and the low bandwidth of the codec.
Even though the footage appears to be 50fps progressive, there seems to be an interlace “cover up” going on there. Some cameras only shoot interlaced video or a goofy pulldown to give it more of a cinema look, and then do a wonky pulldown maneuver to simulate progressive. If you watch the highlights in the eyeballs they are clean for a few frames and then there is this duplication that happens for a few frames (the highlight suddenly has two iterations of itself in two slightly different positions) and then the pattern repeats. So even before you get your file out of the camera, the camera is already mangling the image. To be fair, if this is whats happening, its a pretty good conversion, but its going to be part of the jitter problem along the hair. It would have been better though to shoot with pulldown, take the pulldown out manually, do the key and then put the pulldown back in if needed.

The footage is pretty noisy too, there’s the sensor noise but there is also the codec noise which makes details kind of jump around (the noisy matte along the hair line).

Still playing with it here.

[Steve Bentley]

Will the background be white as in your original sample? If not can you supply a frame of the BG? What it’s like determines much of what the key must accomplish.

[Steve Bentley]

If its the Princess Leia type hologram you are trying to do, you can just shoot that element on black and then use a Screen or Add blend mode onto your background footage. Holograms are just light so they can just be superimposed over the background element without need for keying or green screen.