As I've mentioned here before, I'm using Away3D to write some CAD/CAM software. All of my graphics are 3D wireframes consisting of Segments embedded in a Mesh. A relatively small file would have 30,000 segments or so. A large file has several hundred thousand Segments (hello, Molehill!).
Away3D does okay on the small files, but the big ones really drag it down. I have managed to get background processing working well with Away3D, so the user can continue to interact while waiting for their model to be built, but it's always nicer to make the building go faster. Hence, I got interested in whether some sort of batch operation on the Segments would be faster than just calling Mesh.addSegment repeatedly. It turns out not to be very hard to make it go twice as fast. Full details and source code are over on my programming blog: http://devluchadore.wordpress.com/2011/04/04/creating-meshes-faster-in-away3d-through-bulk-loading/ Basically, I created a subclass of Mesh called "MeshLoader." It has methods to "beginLoad", "addSegment", and "endLoad". It tries to improve performance by eliminating redundant tests and batching up as much as possible everything to do in one swell foop when "endLoad" is called. The end result is a 30,000 Segment model went from taking about 9.5 seconds to build and render to taking only 5.2 seconds. That's not quite 2x, so I was very pleased with the result. The actual framerates are unaffected because we wind up with the same Mesh data structure when done. Nevertheless, for my users, the time to visualizing their CAD drawing is dramatically reduced. I only focused on Segments, but I suspect similar optimization is possible for Faces and so on in a Mesh. Seems like something like this could make loading your models into your game go a lot faster, particularly on a device with limited power. While refactoring at this level is probably painful from a maintenance standpoint, I did take care to benchmark each part of the refactoring. It turns out the vast majority of savings comes from not having addMaterial test whether the Segment using the Material is in the data structures or not. With MeshLoader, we know they're in the data structures because its all being done as a batch. It would seem to me that some option to suppress that checking would not have a major maintenance hit but could unlock a lot of performance. The luminaries here behind Away3D may know of some reason why this is a bad idea, but it sure seems like it works with no drawbacks for my application. Note that this is all done in Away3D 3.5. Would love to try the equivalent in 3.6 but can't until I can get to the bottom of the camera problems I mentioned in the other post. Cheers, BW
