Great idea Li. Thanks!
I'll eventually have bitmap images involved and want to prevent pixel
shifting with the camera constantly moving, but using a smaller value
(.000001) and "wobbling" the camera each frame seems to have done the
trick. So far there hasn't been any noticeable difference in
performance either.

In case anyone else is trying to solve a similar problem - here's the
EnterFrame event handler. Just set a private var called "_camWobble"
in your class.
public function renderView(e:Event):void {
        _view.render();
        if(_camWobble == .000001) {
                _cam.z += _camWobble;
                _camWobble = -.000001;
        } else {
                _cam.x += _camWobble;
                _camWobble = .000001;
        }

}


On Jan 21, 5:34 pm, Li <[email protected]> wrote:
> Try setting a bit of camera motion on enterframe like:
>
> this.addEventListener(Event.ENTER_FRAME, enterFrameHandler);
>
> private function enterFrameHandler(evt:Event):void
> {
>      camera.z += 0.01;
>
> }
>
> If the problem dissapears there might be a little bug with tri-caching.
>
> If not, ignore me :D
>
> On Wed, Jan 21, 2009 at 6:59 PM, SB <[email protected]> wrote:
>
> > All the boxes have the same depth (1). With a depth of 1 and moving
> > the object from z=0 to z=-30000 I think it's safe to say it's not an
> > issue with intersecting shapes.
> > Here's two swf's:
> > In the first one all the boxes have ownCanvas=true (so they can have
> > drop shadow filters applied)
> > The second one all the boxes have ownCanvas=false.
> >http://www.sic-culture.com/z-sort/
>
> > On Jan 21, 1:00 pm, Peter Kapelyan <[email protected]> wrote:
> > > Sorry, hard to tell whats going on from those pictures.
>
> > > Try messing with the depths of the boxes. I'm figuring one is taking over
> > > the other because its dimensions (depth) is larger than the other, so in
> > > your case make the orange one really thin, or the blue ones really deep
> > and
> > > further back, if possible.
> > > Hope it helps
> > > -Pete
>
> > > On Wed, Jan 21, 2009 at 2:50 PM, SB <[email protected]>
> > wrote:
>
> > > > I think you got it backwards Pete. The "orange box" is actually in
> > > > front of all the others (closer to the camera) yet it renders behind
> > > > them.
> > > > Let me see if I can restate my original post a bit...
> > > > The "blue boxes" are all at the same z coordinate (0). When you click
> > > > on one of them, it "zooms" forward towards the camera along the z axis
> > > > - so it it's in front of the other boxes (it also turns orange but
> > > > thats beside the point). The "orange box" should then render in front
> > > > of the "blue boxes". When each box has ownCanvas set to the default
> > > > (false) they will properly render in front of the others when they are
> > > > closer to the camera. It's only when ownCanvas is set to true that
> > > > they won't render correctly. Incidentally, I know that the "orange
> > > > box" is in front of the the other boxes because it obscures the blue-
> > > > boxes from receiving mouse events.
>
> > > > Thanks
>
> > > > On Jan 21, 11:47 am, Peter Kapelyan <[email protected]> wrote:
> > > > > That's because that's the way it works, basically. I'm not quite sure
> > > > what
> > > > > you are trying to do but I'll try to answer :)
>
> > > > > What effect are you trying to achieve? That all the blue boxes come
> > out
> > > > of
> > > > > the big orange one?
> > > > > Or that orange one is always in back? If the orange one is always in
> > > > back,
> > > > > you can add the orange one to another view , and force it to always
> > be
> > > > > behind.
>
> > > > > Also you can try to make your orange box not go too far back in
> > depth, so
> > > > > that it doesn't take over the other boxes in the same view, if that's
> > > > what's
> > > > > happening.
>
> > > > > Let me know
>
> > > > > -Pete
>
> > > >  > On Wed, Jan 21, 2009 at 12:55 PM, SB <[email protected]>
> > > > wrote:
>
> > > > > > I have a z-sorting issue related to setting ownCanvas=true on a
> > group
> > > > > > of objects that I haven't found an answer for (despite there being
> > a
> > > > > > number of topics on the issue).
>
> > > > > > I have a scene with multiple cubes that are set at different x and
> > y
> > > > > > coordinates but all at the same z coordinate - 0. When a cube is
> > > > > > clicked it moves forward in the scene (towards the camera) and thus
> > > > > > "covers" the other cubes. In order to apply filters (specifically a
> > > > > > drop shadow filter) to each cube, the ownCanvas property is set to
> > > > > > true. However, when ownCanvas is set to true the cubes no longer
> > > > > > render correctly - cubes that are further back (at z=0) will appear
> > in
> > > > > > front of the cube that is closer to the camera.
>
> > > > > > Here are a few screens showing the issue:
> > > > > > <a href="http://www.sic-culture.com/z-sort/z-sort_1.jpg";>Cubes
> > before
> > > > > > sorting</a>
> > > > > > <a href="http://www.sic-culture.com/z-sort/z-sort_2.jpg";>Lower
> > left
> > > > > > cube moved towards camera</a>
> > > > > > <a href="http://www.sic-culture.com/z-sort/z-sort_2.jpg";>Another
> > cube
> > > > > > moved towards camera</a>
>
> > > > > > I've tried alternating between Renderer.BASIC and
> > > > > > Renderer.CORRECT_Z_ORDER.
> > > > > > I've tried pushfront (even though the issue is not intra-object
> > > > > > specific).
> > > > > > I've tried putting all the cubes into an ObjectContainer3D that
> > also
> > > > > > has ownCanvas set to true.
>
> > > > > > Seems like a relatively simple problem. Any suggestions?
>
> > > > > --
> > > > > ___________________
>
> > > > > Actionscript 3.0 Flash 3D Graphics Engine
>
> > > > > HTTP://AWAY3D.COM <http://away3d.com/>
>
> > > --
> > > ___________________
>
> > > Actionscript 3.0 Flash 3D Graphics Engine
>
> > > HTTP://AWAY3D.COM

Reply via email to