There are some aspects of Away3D that I don't see how molehill can help.

I have a peculiar app in that I mostly build meshs that are all segments and
no faces, but I have tons of segments.  These are used to create wireframes
of CAD/CAM objects for machining on CNC machines.  For my app, the cost of
building those wireframes seems to be very high relative to the cost of
rendering them.  I see how Molehill will make rendering much faster, but I
am less clear on how it reduces the cost to build the data structures that
are going to be rendered.  If there are silver bullets that improve that,
wonderful.  If not, eventually I'm going to want to figure out how to make
creating the data structures a lot faster.

I need to take a look at some of the importers and see if they have some
tricks I haven't figured out yet.  But, to the Away3D team, I hope you're
thinking about this end too.  After all, with the power to render more
complex scenes comes the desire to build more complex scenes and faster!

Cheers,

BW

On Tue, Mar 29, 2011 at 9:52 PM, Michael Iv <[email protected]> wrote:

> Wow man are you trying to say that Away framework slows down thinkgs so
> much? Interesting what the team can say about your findings.I still did not
> perform any speed tests with Away4 but I wrote some "pure" Molehill based
> app containing around 130000 triangles across 100 different objects in the
> state of constant transformation (rotation,scaling and spherical movement)
> and my FPS even didn't blink! However I should admit that I had no lights
> and no texture mapping,only vertex colored shaders/
>
>
> On Wed, Mar 30, 2011 at 1:29 AM, Dave <[email protected]> wrote:
>
>> I wanted to share some very basic performance numbers and get the team's
>> take on these.
>>
>>  First, some basic info:
>>
>>    - I have wmode=direct on (let's get that out of the way)
>>    - We have a 3952 poly character model.  We're using 8 different
>>    textures/materials.  7 are 512x512, and 1 is 256x256.
>>    - We have 2 lights in the scene.
>>    - I've added a basic "clone" keyboard event handler that clones the
>>    character mesh and adds the clone to the scene.
>>    - We're trying to simulate "unique" characters in the test.  Different
>>    textures, different geometry, etc.  We are trying not to take advantage of
>>    instancing, as our application eventually will have many unique characters
>>    in the scene.
>>    - At the moment, all geometry in the scene is within the camera view.
>>     Culling code is of course running, but everything is testing "in 
>> frustum".
>>    - Hardware: Core i7 Q740 1.73GHz with 8GB RAM.  NVidia Quadro FX 1800M
>>    GPU.
>>
>> The numbers:
>>
>>  *# Chars / # Polys / FPS Range*
>>     1  3952  52-62
>>     2  7904  41-47
>>     3  11856  38-41
>>     4  15508  32-34
>>     5  19760  27-29
>>     6  23712  21-27
>>     7  27664  21-25
>>     8  31616  18-22
>>     9  35568  17-19
>>    10  39520  15-18
>>
>> The questions:
>>
>>    1. The Mesh.clone() method - does this meet the "unique characters"
>>    requirement of my test above? Is there instancing going on underneath?  It
>>    looks like clones share geometry and textures, but I may not have dug deep
>>    enough - the renderer itself may still create unique vertex buffers/etc 
>> for
>>    this data when rendered.
>>    2. These numbers seem abysmal in comparison to what I've seen in some
>>    blog-posted molehill performance tests.  I have not looked far under the
>>    hood of these tests yet.  (a)
>>    http://iflash3d.com/performance/unity3d-vs-molehill/  (b)
>>    http://www.nulldesign.de/2011/03/02/molehill-demo/.
>>    3. Based on what you know about your own internal architecture, and
>>    limitations of molehill, is there anything obvious in what i'm doing above
>>    that would be causing the abysmal performance? Big textures?
>>
>> Any additional thoughts would be most welcome.
>>
>> -Dave
>>
>
>
>
> --
> Michael Ivanov ,Programmer
> Neurotech Solutions Ltd.
> Flex|Air |3D|Unity|
> www.neurotechresearch.com
> http://blog.alladvanced.net
> Tel:054-4962254
> [email protected]
> [email protected]
>
>

Reply via email to