Thank you everybody! I hope with collective efforts we'll solve the problem. I'm very grateful to you all.
Li, your suggestion about Renderer.CORRECT_Z_ORDER did change the situation, but not entirely. Applying this (in cycle to all rotating cubes): (currentAnimatedSide[j] as Cube).renderer = Renderer.CORRECT_Z_ORDER as IPrimitiveConsumer; (currentAnimatedSide[j] as Cube).ownCanvas = false; Did fix the issue, but(!) those artefacs dissappered only while looking from top. While rotating it looks like this from the bottom: [image: cube.jpg] «with owncanvas enabled, what about tricking the z sorting with the screenZOffset property ?» Julien I didn't quite understand how this should work. I tried to apply different zOffsets to cubes, in cycle before applying the animation. Like this: (currentAnimatedSide[j] as Cube).screenZOffset = j; and this (currentAnimatedSide[j] as Cube).screenZOffset = Math.abs(0 - j); But in every case everything looks broken and full of black planes. «If you are switching containers for these cubes at run time, that "should" happen, I guess, because you are trying to sort a container with the other cubes.» @Peter, well I have only one container, which has 26 cubes inside, which form this rubik's cube. Puting those cubes which form a rotating side, before applying the rotation tween, into a separate container — guided to a real mess. I think the best way to rotate just the cubes within. But if I don't find any other solution, may be I'll have to remake everything. «A: Place all the cubes containers, into another container. On this main container, try the ownCanvas=true; instead of the individual cubes.» Well, all cubes don't have containers. They are placed into a single container. Setting this main container ownCanvas = true — didn't help, unfortunately.
