NPE at Object3D.animate(..)

Started by raft, March 04, 2010, 10:38:22 PM

Previous topic - Next topic

raft

java.lang.NullPointerException
   at com.threed.jpct.Animation.interpolateLinear(Unknown Source) (Animation.java:343 in first release)
   at com.threed.jpct.Animation.doAnimation(Unknown Source)
   at com.threed.jpct.Object3D.animate(Unknown Source)
        ..

my first experession is not that bad. karga boy (810 poly) renders 30+ fps in emulator without animation and background. your demo app run ~10 fps. however debugging kills performace, loading time increases and fps drops down to 8-10. i also get out of memory time to time while restarting the application. log says it cant find memory for bitmap

btw, my friend told eclipse can debug app in phone which sounds good..

EgonOlsen

I don't know, why the line numbers vanished in this release...i'll try to get them back in. Anyway, i don't see a reason for this exception at first glance. How are you loading the models/animations?

EgonOlsen

Maybe it's because the serializer (if you are using this) doesn't serialize animations right now...!?

EgonOlsen

An MD2 model that i'm using for testing works fine...apart from the fact, that frame rate drops into the single digit range when using animations. I have to improve the filling of the vertex arrays somehow...

raft

Quote from: EgonOlsen on March 04, 2010, 11:11:47 PM
How are you loading the models/animations?
via karga's loader. jpct animation class is pre-serialized and deserialized during load. i've checked all keyframes are present (non is null) and same size

Quote from: EgonOlsen on March 04, 2010, 11:24:38 PM
Maybe it's because the serializer (if you are using this) doesn't serialize animations right now...!?
no, not jPCT's serializer.

raft

animation meshes are serialized with desktop jPCT. maybe some internal structure is changed and hence is set to null during de-serialization.

content of a keyframe mesh in eclipse debug view. maybe helps:


EgonOlsen

Yes, they have changed a lot. They are much leaner now. You can't deserialize something in AE that has been written by jPCT, i'm afraid.

raft

ehm ::) ok, i can still serialize with jpct_ae in classpath, cant i ?

but for this specific case, is such a change really necessary ? AFAIK, the only information used from keyframe meshes are vertex coordinates and normals right ? if this is the case, preserving their names in desktop and ae versions will suffice

EgonOlsen

Actually, an Animation is a collection of Meshes. Mesh itself hasn't changed that much. Are you using that SERIALIZE_LOW_PRECISION thing or somthing like that? I've removed that, maybe that's the problem. I can put it back in, if it is.

EgonOlsen

Ok, it's back in. Please download the AE-jar again. Maybe this helps. This version also includes a change that speeds up animations up to 50%...i.e. from 4.5fps to 7fps... ;)

raft

yeah good catch, it's fixed now ;) but fps seriously drops with animation, 35+ to 5-10 ::) does real phone behave the same ?

EgonOlsen

Yes, the phone behaves the same. From ~25 down to 7 fps in my test app with animations enabled (was 4 before my first optimization approach). I think that this can be improved a little further. I'll try to use indexed geometry instead. I'm currently not doing this in AE, because it's slower (albeit it should be faster in theory), but for animations, it may be worth it. But i don't expect any miracles from that....maybe i can get it up to 10 fps.
However, i can't remember any 3d game on Android that uses animations of that kind. They all revert to static objects like balls, cars, flying robots...and even if there is animation (like in the Neocore demo, which is native), it seems to be done by rotating parts of the objects, not by playing around with the vertices. Must be a reason for this...


EgonOlsen

Opps...going for indexed geometry for animated objects (i.e. doing the exact opposite of what the desktop jPCT does), increased frame rate from 7 to 16 when playing animations. Obviously the filling of the vertex arrays with the animated vertices absolutely kills performance, i.e. you are rewarded greatly for each vertex that you don't touch.
Nice...i'll try to increase this further, if possible.

raft