QuartzCrystal Rendering

I've heard of a similar issue (dropped out runs of pixels), but I've never been supplied with a composition that manifests this problem, so I've not been able to investigate it further.

Can you e-mail me a copy for testing?

There some some weird CoreImage bugs (which QC uses extensively) that cause recycled resources to sometimes get reused when they're still active. There are also some QC bugs that cause some patches to continue rendering, even when rendering is disabled. (For example, FPS and Video Input both 'leak' on to the preview when you start rendering, because they're sharing information that shouldn't be shared).

Spooky Send/Receive tend to trigger this a lot in QuartzCrystal, because the preview and the renderer operate in the same app, and thus the renderer and preview compositions cross-talk. QuartzCrystal 1.3 (still in final testing) solves this problem, which might fix what you're experiencing.

I wanted to see what Chris had to say on this one first :o)

I have noticed a couple of things that are inconsistent between the built in view mode in QC and pretty much anything outside of QC that is built to display or render comps. I almost think that the QC rendering display unduly fixes problems?

You should check the way you have clears set up on all levels and experiment with adding one at the base (layer1) of every macro. Another thing is checking depth read/write settings. Yet another is how you are actually toggling your patches off and on. Are you turning off the whole 3D transform, or just the renderer in it? There is a chance you could be toggling off just the billboard/sprite/whatever, but not the entire macro, which could or could not result in the clipping thing you are talking about.

Good callouts, I'll definitely check into those.

The macros are being entirely disabled, I made sure of that. I think it might be some sort of issue with the 3D transform patch and the sprites in it. I emailed a sample comp to Chris to get his input. I'd post it, but it's sort of sensitive.

I may try breaking each macro out and rendering them with QCrystal and see if the problem still occurs.

Thanks for those points though, it didn't occur to me to check those.

You might also want to drop the composition in Software mode to see if that's possibly a cause (hold down alt while opening QC preferences -- under the (Editor) tab, enable softwareCoreImage and softwareOpenGL, and restart QC. You'll probably not want to leave them enabled, but it'll give you an environment almost identical to the one QuartzCrystal uses.

(I don't know whether or not this applies, but after a few seconds of your sample video you mailed me, it brought up some memories of z-fighting roundoff issues)

Ok, did a few minutes of checkout -- basically, this is textbook z-fighting. For the depth Checking input, change it from Read-Only (which fails pixels that are too deep), to None (which never fails pixels). What's happening is your sprites are too close together, so when they're rotated at all, the roundoff introduced confuses the graphics card into not knowing what's in front. The QC Editor doesn't exhibit this because it uses fancy custom graphics contexts that don't usually occur in real life (in other apps, etc).

With None for the Depth Check, you have to make sure they're rendered in the correct layer order, otherwise stuff gets overdrawn (your composition looked ok, layer order wise -- just keep that in mind).

An alternative, if you want to keep depth testing, is to space them out more on the Z axis (a few thousandths of a unit, typically -- big enough that it won't get rounded off, small enough that users won't notice).