I believe I have discovered that using a strange UINT for material dramatically decreases efficiency.  I couldn’t figure out why simply adding a little cube made the physics go from blaring fast to slow as a snail.  Later something about “numbers” came to me, and I experimented by turning an orange 0xEB9D21 (for exmaple) into a 0xEE9922, and suddenly the performance went back up to speed!

Is this persistent throughout Flash in general or is this an AwayPhysics thing?  It doesn’t seem prevalent in AS3 normally based on my searches.

Also is it possible that x,y,z locations of things and/or the number of the w,h,d of object can effect performance?

Do you have general tips to simply speed things up, even if it means cutting corners in graphics quality or other?

Changing the colors of the material shouldn’t affect the performance.
Also the material isn’t related to physics.

General optimizing tips: if you have lots of statics objects merge them (reduce the drawcalls), don’t use realtime shadow but baked use as little lights as needed etc. But it’s all pretty general maybe if you can post the code we could help.

Good luck.

Thank you Ringo.

I compile frequently after just about every little change so that I can see the differences and/or possible bugs clearly.  I don’t know why the one time all I did was change the color of a ColorMaterial and and the speed increased dramatically, perhaps a subtle problem with my hard/software set up, or perhaps I did change something else.

Regardless, it seems my situation has greatly improved by playing with the scale of everything.  In another thread someone suggested:

physicsWorld.scaling = some_number;

And that did help a bit with speed, but also caused weird behavior such as the ball going through the wall.  I assume this scaling has to do with the number of nodes in the mesh?  which is why the ball would pass through a gap?

So I created a test scenario and added different objects one a time to see the problem.  The biggest problem was with complex imported 3DS meshes, but problem was not consistent still.

Trial and error finally led me to find that the SIZE of the object was of great importance.  I was loading meshes and scaling them by 500, which brought the actual size up in the thousands, and other numbers were all in the thousands as well.  When I scaled things down to the hundreds all of my problems went away.

I still have to be very careful with the efficiency of things, but that was a huge help.

I did test on both Windows and Linux, so I think the problem might be universal in that regard.  I’m running a quad core 2.6 Ghz per core CPU, I don’t know GPU specs but the machine was specifically bought for modern day gaming so I’m sure it’s just as good.  I play games and do 3D work with this machine all the time.

This is all FYI because I’m not sure if the examples are optimized for lower specs, and since we’re making Flash docs here I assume we would like to see them work on netbooks as much as power machines.

Are there any unexpected side effects to lowering the scale of things like this?