Bones - Skeletal and Pose animations for jPCT

[raft]

oops. there is a missing call to AnimatedGroup.applyAnimation() in ProceduralAnimationSample, it's working now. please re-download the zip. thanks for the reminder

for exporting: how many skeletons are there in your scene? there should be one. if there are more, try removing others and see if that helps. otherwise send me exported files and let me have a look

[gururise]

Thanks for the response! I have given up on trying to export models from Daz 3d, to trying to use the Collada Models in the Google 3d Warehouse; however, every time I try to load one of those collada models into Bones, I keep getting the following exception:

Code Select Expand

Exception in thread "main" java.lang.IllegalArgumentException: ColladaStorage contains no skins.
at raft.jpct.bones.BonesImporter.importCollada(BonesImporter.java:49)

I tried the following collada models from Googles 3d Database, and they all resulted in the same exception:
Collada Model 1
Collada Model 2
Collada Model 3

Can we not use the Google Collada models in Bones?

Thanks

[raft]

There are no skeleton and animation in these files. Hence they cannot be imported by Bones. Remember Bones is an animation library, not a collada scene importer.

[gururise]

Got it! I guess I need to import these collada models into a 3d program and work on creating a skeleton.

Thanks again for all your help!

[gururise]

Well, I have successfully loaded a collada model into the Desktop JPCT w/Bones. Everything is working great, and I am able to manipulate the skeleton procedurally.

Now, I want to load the same model into JPCT-AE (Android) w/Bones. I noticed, in the Android example with the ninja, you loaded a ninja.group.bones from the /raw/ directory.

In the desktop Jpct/Bones, I load my collada model, then use BonesIO.saveGroup(animatedGroup, output) to save my model to model.group.bones and then imported it into Android. The first time I did this, I got an out of memory error.  After spending hours reducing the number of polygons in the model, I was finally able to get it to load in Android, but with very little memory to spare.. and my model looks quite ugly now due to the low poly count.  I am wondering if the exported file is being serialized??

In Jpct-AE, it is recommended to first serialize the object on the desktop, then load the serialized object into Android.  When I call BonesIO.saveGroup, does it perform this serialization step?  Are there any other optimizations I should perform on the AnimatedGroup before I export it to the bones format to be loaded into Android?  

Thank You

[raft]

no, BonesIO.saveGroup/Object does not use jPCT's serialization. it's indeed slightly customized standard java serialization.

but this shouldn't effect memory usage. jPCT-AE recommends serialization mainly to speed up loading. it also reduces memory usage but only in loading. after loading all objects and making a garbage collection, there is no difference in memory usage.

how many polygons are your model? the ninja model is more than 500 polygons and 8 ninjas run without any memory problems. maybe there is some other thing that consumes memory, big textures maybe?

[gururise]

how many polygons are your model? the ninja model is more than 500 polygons and 8 ninjas run without any memory problems. maybe there is some other thing that consumes memory, big textures maybe?

I've got complex model.  I currently got it down to about 6000 polygons, and am now able to load it on my Nexus One.  When I had it at about 10,000 polys, it would crash upon loading.  
I also only have one texture at 512x512.  I tried making the texture larger, the desktop version seems to handle 1024x1024 w/o problems, but on Android, it crashed on loading the texture if I have it larger than 512x512, perhaps thats a limit.

Edit: I think I was bumping into the Android Java heap limit (16MB, and 24MB on some phones).  As it stands now, after loading (but before GC), I need about 18MB of heap, which is why it works on my nexus one. Would I be able to use the NDK to allocate space for the AnimatedGroup object to bypass the 16MB heap on older android phones?

[raft]

Would I be able to use the NDK to allocate space for the AnimatedGroup object to bypass the 16MB heap on older android phones?

i'm not aware of such a thing.

after loading AnimatedGroup try calling discardMeshData() on each of Animated3D's and make a GC before loading texture. this will slightly reduce memory usage. but dont expect miracles.

operating near limits of VM memory is not a good idea anyway. 6000 animated polygons sounds high to me. if you wont zoom in to the model very much, 256x256 texture may also look good.

[EgonOlsen]

Would I be able to use the NDK to allocate space for the AnimatedGroup object to bypass the 16MB heap on older android phones?

i'm not aware of such a thing.

There is no such thing. The limit is compiled into the VM by the phone's vendor. You can't even be sure that Android version x.y always supports the same limit...it depends on the vendor's choice.

[gururise]

Would I be able to use the NDK to allocate space for the AnimatedGroup object to bypass the 16MB heap on older android phones?

i'm not aware of such a thing.

There is no such thing. The limit is compiled into the VM by the phone's vendor. You can't even be sure that Android version x.y always supports the same limit...it depends on the vendor's choice.

I found an interesting blog post on how to work around the 24mb heap limit in Android by using the NDK.  Apparently, memory allocations in c/c++ via the NDK are not subject to the java heap limit.  There is also a great thread where one of the Google developers chimed in and basically said the same thing, but suggested not going over 32MB via the NDK.

I'm wondering if its possible to declare an AnimatedGroup on the java side, pass it over to the NDK via JNI and then allocate say 24MB via malloc (or new), and then pass it back to Java and instantiate the AnimatedGroup by loading the Bones file... Not sure if that would work or not.

[raft]

interesting blog and thread but that wont work for this case. native memory is outside of java heap, it does not matter how much native memory is allocated. java heap limit will remain the same.

[EgonOlsen]

However, it should be possible to load 10000 polygon object. The models i'm using in the benchmark are much larger. Is the additional skeleton so expensive?

[raft]

here is the math. all these arrays are copied during loading for ensuring encapsulation so x2 applies.

skin data for each vertice:
* short[4]: joint weights = 8 bytes
* float[4]: joint indices = 16 bytes

animated mesh data for each polygon
* source/dest mesh/normals: 4 x SimpleVector = 64 bytes (taken from IVertexController)

constructing mesh data (discarded after Animated3D.discardMeshData() is called)
* indices: int[vertex count] = 4 byte for each vertex
* vertex/uv coordinates 2 x float = number depends on geometry.

in total for a 10.000 object (maximum, assuming all vertices are distinct)
* 240k skin data
* 210k animated mesh data
* 120k constructing mesh data
sum: 470k x2 copying factor = 940k. less than 1m. not that much indeed

skeleton itself does not consume much memory assuming joint (bone) count is reasonable. 2x matrix, 2x int, 1x string for each joint

animation data should not also consume much but it depends on number of keyframes in animation.

edit: multiply with 3. calculated for 10.000 vertex object, not for 10.000 polygon object

[Alexey]

Hello!
I try build and install ninja demo on android, but when starting animation i get noSuchMethod exception when call normalTemp.rotate(currentPose.palette[jointIndex]);  - ( Animated3D.rotate(Matrix[]) )
I suspect that this is due to project setting (eclips) . Any one got this exception?

[raft]

seems as jPCT AE version does not have SimpleVector.rotate(Matrix) method. possibly forgotten. Egon can you please add it?
that part is recently added to Animeted3D to animate vertex normals too. since then i had never tested Android demo app.

@Alexey, meanwhile you can comment out the line 435 at Animated3D. the demo will run but normals will not be correct. does not matter if there is no light source in the scene.