Posts Tagged ‘performance’

3DS in Away3D

I’m starting to cook up a few game ideas with some friends of mine and I wanted to get a sense of what Away3D could really do.  To start, I made this very basic example of Away3D loading a fairly high poly 3DS file with minimal animation.  More specifically, it’s a rotating, 2880 poly, torus knot with a wire frame material.  While Away3D isn’t really made to handle models with this many polys, it gives me an idea of how it will handle a total polycount of about 3000.

Featured Away3D code: Max3DS.load() and WireColorMaterial

Click the image above to access the example.  You can right click on the example and click “view source” to,  you guessed it, view the source.

Away3D: 1.0

Originally this project was the main page for, but I decided it to shuffle to “projects” on my blog.  While it is was a very cool showcase of the things I had learned so far using Away3D, Flint particles, FLARToolkit, FLARManager, TweenMax & TimelineMax, its not really practical for a main interface… yet.  Here’s the things I learned in this initial undertaking that I plan to apply to all future projects involving Away3D(Lite), particularly when the average user is the target audience:

  • Performance ALWAYS has to be on your mind.  There’s nothing more annoying to users than low frame rates.  Many of my next points relate directly to this.
  • Use Renderer.BASIC as your view’s renderer whenever feasible.  You will take an immediate performance hit trying to use the smarter z-sorting renderers (CORRECT_Z_ORDER or INTERSECTING_OBJECTS)
  • Control the size of the view.  While a resizeable view that fills the browser seem great, you can take a nasty performance hit on high resolutions.  For example, this project runs like a champ with a standard 800×600 or 1024×768 resolution.  When I jump it up to  1680×1050, though, things start to get a little choppy.
  • 3D particles are a whore on resources.  Fake 3D effects with 2D whenever possible.  You can literally get 100x (or more) particles in 2D and maintain the same frame rate as 3D.
  • Use simultaneous tweens judiciously.  There were noticeable slow downs in my intro animations when more than one tween was operating at a time.
  • Learn your z-sorting and plan it from the beginning.  I can’t tell you how much time I wasted restructuring my scene and code because I didn’t take the time to learn Frustum clipping, ownCanvas, pushback, pushfront, and screenZoffset before starting.
  • Interactivity and camera motion impacts performance. Static scenes will allow for far more polys at a good frame rate than dynamic ones.  Keeping the camera static or using mouseEnabled = false on your objects may help.
  • Users expect 2D dialogs and text. Use them whenever feasible to convey information to the user.
  • Make sure you clean up your unused objects.  ”scene.removeChild(obj)” and “obj = null” should become your best friend.
  • Reuse objects and materials whenever possible.  Its a lot easier and less expensive to toggle the visibility of a relatively simple object rather than destroy and recreate it every time.
  • Only render when you need to.  When I use 2D layout for the “Bio” section, I stop rendering the covered 3D scene to help performance.
  • Use texture baking or similar techniques to fake lighting.  Real-time lighting, while cool, chews up a lot of resources.  If it isn’t critical, fake it.
  • Materials with alphas process slower.
  • When all else fails, hit the . It may not have the fastest responses, but there’s no better place to get help and guidance.

I’m sure there’s lots more I picked up in the process, but that’s a pretty good assessment.  Hopefully this helps anyone getting started on their own Away3D projects.

I don’t have any specific plans to make version 2.0 of the 3D interface, but I’ve got a few ideas rolling around in my head.  The key factors will be simplicity, speed, more pseudo-3D effects using 2D, and use of Away3DLite.  I’m hoping to really represent Away3D next time.