Hey SB yes, this looks to be a triangle caching problem. I would suggest using camera.forceUpdate = true rather than wobbling the camera as it's a little less annoying as a hack ;)
Strange one to see though - i'll try and find the cause of the problem. In the meantime, would you be able to log a bug in the issues tracker? http://code.google.com/p/away3d/issues/list cheers Rob On Thu, Jan 22, 2009 at 6:36 PM, Li <[email protected]> wrote: > 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 >> > > -- Rob Bateman Flash Development & Consultancy [email protected] www.infiniteturtles.co.uk www.away3d.com
