This is what Rob wrote in an older e-mail (to turn off the TC): I should mention that if you ever want to turn OFF triangle caching (maybe because of some unforseen problem apparent in your application), you can set the forceUpdate property to true in the view.
-Pete On Thu, Jan 22, 2009 at 1:26 PM, tain <[email protected]> wrote: > > why didnt he just disable triangle cache? > > On Jan 22, 6:33 pm, Li <[email protected]> wrote: > > Im glad your problem is solved... however, it means there is a little bug > > with triangle caching in the engine. It should be solved soon so that > > enterFrame or moving the camera wont be necessary. > > > > =) > > > > On Thu, Jan 22, 2009 at 1:33 PM, SB <[email protected]> > wrote: > > > > > 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/> <http://away3d.com/> > > > > > > > > -- > > > > > > ___________________ > > > > > > > > Actionscript 3.0 Flash 3D Graphics Engine > > > > > > > > HTTP://AWAY3D.COM <http://away3d.com/> > -- ___________________ Actionscript 3.0 Flash 3D Graphics Engine HTTP://AWAY3D.COM
