Rubik's Cube - 3D is rendering by layer order instead of Z space and it's ruining my life

[lizs10642229]

Hello friends. I have an issue that I have seen discussed before, but none of the solutions proposed have worked for me. I'm up on a client deadline and have put in a shameful amount of hours trying and failing to resolve this. SOS.

I am animating a functional Rubik's cube rig in After Effects. It works perfectly, except that I am getting edges clipping because After Effects is rendering the "cubelets" that make up the rubik's cube in layer order instead of Z-space. So, AE doesn't treat the things in front as if they are actually in front.

I tried to find an elegant solution - looked in every precomp for a single 2d layer that could be throwing it off, and found none.  Looked for layer styles, found none. Couldn't find anything that was known to cause this issue.

Tried to force an inelegant solution by simply chaining together a bunch of different composition duplicates which each have the layer order rearranged based on what causes the least clipping... but since all of these sides are constantly turning, rotating, etc, there is no way for this solution to actually work unless the layer order was changed every 2-3 frames.

I have attached two screenshots that show how the issue manifests, four screenshots that should provide a general sense of how the Rubik's cube / project is built, and one guide to the naming conventions I used to keep track of which cubelet was where (which is based on the final Solved position of the Rubik's cube).

On a Macbook Pro, OS Ventura 13.2.1,  After Effects Version 23.5.0

Thank you to anyone who puts any time into helping me resolve this 🙏

[Mylenium]

It pretty certainly has to do with your multiple cyclic uses of continuous rasterization for a) the AI artwork and b) the nested 3D comps. I'm quite sure it messes with the Rubik fakery and was never meant to be used this way. you will likely need to forego the CR on the AI artwork ands simply have to use larger pre-comps.

Mylenium

[lizs10642229]

Could you explain what you mean by larger precomps, and how it affects the issue? Do you mean that if I pull the layers up to one main composition level rather than divvying it out based on the cubes? Thank you for your help, saved a new version I'm about to go in hacking and slashing lol

[Rick Gerard]

If I were setting up this kind of project, I would offset the Anchor point of each surface by half the width of the surface in Z space. If the surface is 200 X 200 pixels, then the anchor point would be 100, 100, 100 if the face layer was an AI file or 0, 0, 100 if it were a shape layer. 

Then you start rotating the layer two through four to 90, 180, and 270º in Y, then the fifth and sixth layers 90 and 180º in X. You now have a cube at Comp Center. You can add a 3D null, parent the six surface layers to the null, shy the surface layers, then lock them. Now you only have to deal with a null for Cube 1, and you can do the same for the other 27 cubes you need to create. You don't heed a cube for the center. You can just use a null. 

You can Pre-compose all of the cubes you create, or you can pre-compose the group of nine virtual cubes, but you will need to add additional nulls to rotate each of the six faces of the finished cube that are linked by expressions in the main comp to the controller nulls in the nested comps. If you try making the nested comps 3D layers and rotating them in the main comp, even with Collapse Transformations turned on, you will end up with the problems you are experiencing. 

There are a total of six nulls required to rotate each of the six faces of the big cube around the center, and there are also a set of nine nulls at the center of the main cube required to control the other movements. The rig gets complicated very quickly and will require expressions. 

I have an old AEP with a Rubik's cube somewhere. If I find it, I'll share the project.