First alpha version released

[EgonOlsen]

Finally, after a long time of struggling with the platform and its shortcomings, i've decided to release the current version to the public. It's still in its infancy, so bear with it.
I've created a fancy webpage for it:

http://www.jpct.net/jpct-ae

... You should get everything from there to get you started. If not, please let me know.

About the version itself: It's a port, not just a normal jPCT version with a different renderer. It will help tremendously if you are already familiar with the normal version of jPCT if you are going to use this one. If you are not, it might be a bit harder, because all the jPCT related resources in the forum and the wiki have been created for the normal version and even if both are very similar, there are some differences here and there.

This board is meant to be used for feedback, bug reports, support questions, projects until further notice.

Have fun!

[zammbi]

That's great.
Now I want to get an android to test this. I might import one for my network as I can't get one local. Though if I do get one over Windows Mobile, I hope JavaFX comes out soon for it.

[raft]

ah, it's the big day

[EgonOlsen]

About the version number: This version identifies itself as 1.19. I decided to keep the version numbering consistent between the two branches. However, 1.19 isn't really correct in this case. It more like a 1.21 minus something.

[raft]

btw, desktop 1.21 alpha link is broken. since it still is downloadable via directory listing 

[EgonOlsen]

btw, desktop 1.21 alpha link is broken. since it still is downloadable via directory listing 

Thanks. It's fixed now.

[raft]

i've asked my friend to run demo app on his phones:

* HTC Tattoo (android 1.6) demo runs at max 10fps, while moving around fps drops down to 7. seems as hw acceleration is not present
* G1 (android 1.6-2.0 hybrid community version): fps up to 24-25, while moving around drops down to 15

he also said, G1 is sensitive to orientation change (restarts app lifecycle) and some times app chrashes on orientation change

fyi

[EgonOlsen]

Information on the MSM7225 (the chipset of the Tattoo) is, as usual, sparse. But from what i've found, it seems that it doesn't include a GPU, which would explain the low frame rate.
G1 performance is similar to my phone, it's fine. The orientation change thing was to be expected. Changing the orientation destroys the GL context, which makes me upload all textures again. The demo application is simple...it just discards everything and starts from scratch when changing orientation. This can be changed in the demo, it's not a fault of the engine. I've experienced that crash problem myself with this demo as well as with other OpenGL apps. I blame it to the native implementation for now.

[EgonOlsen]

I've updated the jar and the demo's source. The version number is correct now (1.21) and i changed some internal stuff dealing with freeing resources.

[raft]

i've just saw demo app running on my friend's G1 and i loved it, it looks very nice

[EgonOlsen]

Thank you. It was just a test case based on some shadow mapping test case that i'm using for the desktop version.

I've updated both, the AE jar and the 1.21 one. They can (de-)serialize animations now and the AE version includes the animation optimizations. Performance in my test case increased from 4 to 18, which is a nice boost. I've extended Mesh's strip()-method to remove more data that isn't needed for animations IMHO. However, it seems a bit strange that i haven't removed those parts before, so maybe it's not such a good idea as i thought...so if something fails now that worked before, this might be the reason. In that case, please let me know.

For now, i haven't added the option to (de-)serialize Mesh or Animation as stand-alone. I might add it later, but one can only do so much...

Android is strange...obviously, you can't load any single file larger than 1 MB even if it's from an InputStream. It throws an IOException in that case. So in case your serialized animations are bigger, just zip them. The loader doesn't unzip it itself, but you can simply wrap the inputstream.

[raft]

great thanks i really appreciate your efforts and support for this engine if has any meaning

i've managed to run facial animation demo in emulator. it has ~3000 polygons. without animation it was running at ~11 fps, with new release it runs at ~14 fps.

however with animation, both versions drops down to ~2 fps. so i guess your optimization only applies to built-in mesh animations ?

[EgonOlsen]

No, it applies to all meshes that can be modified. However, some "if" depended solely on animation and didn't take vertex controllers into account. This is changed now, i've updated the jar. Depending on how you created the Animation-instance, make sure that Animation.setCaching(true); has been called. If all goes well, the log should read like:

Code: [Select]

Remapping xxx animation indices!
Creating animation cache (yyyy bytes)!

If that doesn't happen, something is still fishy...if it happens, and it's still slow...well...

[raft]

i couldnt get it. that facial animation does not create an Animation instance. it just depends on vertex controller do you mean, i should create a regular jpct animation via my vertex controller animation ?

[EgonOlsen]

Shoudn't matter...it should print out that messages anyway. They don't appear? Strange....i'll write myself a simple test case and see what happens then.