The lower the better of course but you can choke the player with less than 500 if you do not master both flash and Away.
However for most projects a rule of thumb of 2000/3000 rendered faces in Away is perfectly doable at acceptable frame rate multiply that by 3 in awaylite. I have done quite a few loops in Away and total faces (rendered & non rendered) varies depending on how they are managed examples: done in 2.0 like green planet, the demo holds 20k polys, the railaway demo over 100k while they both manage to run at very descent speeds. There are many rules you can apply where same content can be displayed more efficiently. like try set maps size based on how the model will be displayed... that house in faraway land doesn't need a 512x512. use power of 2 sizes, avoid sprites overlays with enterfames or timeline running, use models that were specifically made for flash use use Weld, Merge statics to avoid objects checks...etc point is that experience, talent combined with a good project specific analyse before build are key factors. Fabrice On May 19, 2010, at 2:31 PM, savagelook wrote: > no takers? > > On May 18, 2:24 pm, savagelook <[email protected]> wrote: >> In terms of performance, how much of an impact is total elements? I >> know, its hard to quantify or even ballpark. If I remember correctly, >> about 10,000 elements is considered the feasible max for away3d, but >> is that rendered elements or total elements? If it is rendered >> elements, is there such a max for total elements? >> >> I ask this because I'm struggling with some transitions between scenes >> on my away3d app using greensock timelines, as well as having lots and >> lots of fun trying to track down and release memory. My thinking was >> that if total elements wasn't really a concern, I would just create >> all my objects right at the beginning (rather than when they are >> needed) and just use visibility to make them appear and disappear, not >> remove/addChild(). This seems like it would by nature make memory >> management easier. It would use more up front, but I would get less >> surprises in terms of memory being chewed up as the application >> continues to run. >> >> Thoughts?
