>   Hence, I got interested in whether some sort of batch
> operation on the Segments would be faster than just calling
> Mesh.addSegment repeatedly.  
That's more or less how the new version works.

Segements/Lines are on hold till we know/find a good way to implement curves.

Fabrice


On Apr 4, 2011, at 10:47 PM, BobWarfield wrote:

> 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

Reply via email to