Oh... good one Pete! On Thu, Jan 22, 2009 at 4:28 PM, Peter Kapelyan <[email protected]> wrote:
> 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 >
