Away3Dlite animation rendering speed

[Riccardo]

Hello,
first of all thank you for Away3D, it's a very advanced and useful
library, and very well developed.

At the moment I'm comparing the rendering speed of Away3Dlite against
Away3D.
My first test was just a sphere, and actually the lite version of the
library is 30% faster.

But then I tried the animated Marios example and to display just one
of them.
Then I converted the same application to Away3Dlite, basically
switching from the away3d.animators.SkinAnimation class to the
away3dlite.animators.BonesAnimator.

What I got is that Mario runs at 40 fps with Away3D on my machine, but
it runs at 24 with Away3Dlite.
But Away3Dlite should be supposed to be faster (or at least not
slower), shouldn't it?

What's going on? Am I doing anything wrong?

Thank you

[katopz]

Hey Riccardo

We did notice huge speed drop via collada animation too.
It's under investigate for fps leak somewhere...

I think it should be uvt calculate with nested Object3d transform
cuase this issue
Object3D in lite extends Sprite, pros for this is transfrom calculate internal
but cons is it also got plenty of Sprite property that never use after extends
(e.g filters, soundtransform,mouse,....)

I'm start thinking that it's maybe better to redo Object3D extends
Object instead
and let's hope that will increase fome fps after that

In case i'm got long todo list already, if someone sound this should be fun
plz do try and yelling for result ;)

Cheers

--
katopz
http://www.sleepydesign.com

[Ken Railey]

So I mentioned once before on this list, but it probably bears repeating that I found a significant amount of skin animation time in my case was spent applying weights multiple to times to a given vertex position. I am seeing even worse performance than the numbers posted below, though.

I just checked out and built the 2282 revision from svn, and I get about 10-12 fps in the unchanged Advanced_MultiMarios example according to the built in display.  After applying a patch to remove duplicate weighting operations I get 16-18 fps, which is much better, but still far below the 24 posted below. The impact varies by Collada model, of course.  In my project here, the mesh animation fps nearly doubled, so YYMV.

In any case, I am not sure whether this list allows attachments so I, but I have attached a patch against r2282 if anyone wants to try it.  I put it on pastebin just in case as well: http://pastebin.com/LZgatVL0

It just de-duplicates the vertex skin vertex indices per mesh based on position, which could potentially result in problems if a mesh is designed with duplicated vertex positions intentionally for some reason.  Also, this is creating a memory leak when destroying a mesh, since there is a static list of SkinVertex instances used for duplication checking.  This is probably not the ideal way to approach the issue, but if you just want to try it for now to see if you get a performance boost, I would be curious to see your results.

-Ken

[katopz]

Hey Ken

Thanks for sharing, I'll take a look, any other comment/suggestion is welcome :)

Cheers

--
katopz
http://www.sleepydesign.com

[Ken Railey]

No problem at all.  After re-reading the thread, I realized that the original email states only one mesh was being animated, which accounts for the performance discrepancy.  I should probably also have mentioned for context that these frame rate numbers were on a last gen Mac Book Pro.

-Ken

[Riccardo]

Thank you for the answers!
Ok, so if it's a known issue, I will keep on using Away3D for now.

And yes, Ken is right, I just took the Mario model off the original
example and put it in another empty one in which I just display a
single animated Mario on a blank background.
I'm making my tests on a Pentium D 3.20 Ghz with 2 GB of RAM on
WindowsXP. I know, not a next generation machine :P

Thanks again for the support

Riccardo

On Mar 4, 6:24 pm, Ken Railey <ken.rai...@gmail.com> wrote:
> No problem at all.  After re-reading the thread, I realized that the
> original email states only one mesh was being animated, which accounts for
> the performance discrepancy.  I should probably also have mentioned for
> context that these frame rate numbers were on a last gen Mac Book Pro.
>
> -Ken
>
> On Thu, Mar 4, 2010 at 12:01 PM, katopz <kat...@gmail.com> wrote:
> > Hey Ken
>
> > Thanks for sharing, I'll take a look, any other comment/suggestion is
> > welcome :)
>
> > Cheers
>