Well, if I understand correctly, threads do not add speed on devices, but only transfer work to the background.

I'm not entirely sure about this...
I believe you could off-load some heavy physics calculations on a seperate thread than the GL-thread.
When heavy calculations are done in the GL-thread, you might suffer from lower FPS due to reduced draw(...) call rates.
I think this might especially give speed boosts on multi-core processor devices (nearly all devices nowadays) which would handle multithreading better.
Though, making sure the threads are synced and working well together might be more complex...
jPCT(-AE)/OpenGL(ES) isn't entirely multi-thread friendly as far as I know.

Maybe @EgonOlsen knows more about this...

Quote from: Thomas. on February 23, 2013, 02:28:42 pm

Sources in first post was updated. Zip contains optimized jBullet lib (thanks EgonOlsen for tips! ), adjusted vecmath lib and sources of PhysicsTest app. On my SGS3 physics calculations of 9 boxes take about 37ms with original libs and 29ms with optimized ones. It is almost 30% speed up, it is not much for my app, but maybe it can help to someone.

Hello Thomas,give please link of source code jpct-ae+jbullet,link in top not work.

I believe the Dropbox links have died since the post is from years ago.
I once experimented with jBullet too... but the performance was too poor for my likings I believe.
Though, I might still have the jBullet version that was originally posted here somewhere on my computer.
I can try to look for it if you're really interested...

Otherwise, maybe this will help:
https://www.jpct.net/forum2/index.php?topic=1509.0

Shader example: https://www.jpct.net/wiki/index.php/Shaders
Scroll to last images/code for specular lighting implementation that might be interesting for you.
You can use this to load shader textfiles (both vertex shader and fragment shader) to String variables: https://www.jpct.net/jpct-ae/doc/com/threed/jpct/Loader.html#loadTextFile-java.io.InputStream-
You can use this to create your own GLSLShader: https://www.jpct.net/jpct-ae/doc/com/threed/jpct/GLSLShader.html#GLSLShader-java.lang.String-java.lang.String-
And finally you can use this to apply a GLSLShader to your Object3D: https://www.jpct.net/jpct-ae/doc/com/threed/jpct/Object3D.html#setShader-com.threed.jpct.GLSLShader-

About the gap in graphical output:

OpenGL implementations differ per device model.

This means that one device might have a worse compiler (for the (default) shaders) than another device.
This will lead to artifacts in the graphical/rendered output.

OpenGL implementations differ per device model.
For myself, I have found that emulators actually produce most consistently good results (maybe this was different in the past but it seems fine for me).
I believe the specular lighting doesn't seem to work properly for you on one of both (I'm not sure which screenshot is tied to which device).
You can reduce the sun intensity values to reduce the 'mirror'-like reflections. (Specular lighting).

PS: do you have another phone/tablet you can test on?

The Android live wallpaper on a PC emulator:
https://imgur.com/a/LUkHPCj

with gif files, i can show you more interesting things.
this one shows the vehicle drifting, when rear tyres have much lower friction coefficient, any vehicle can do this.


the colored polylines is a tool for testing purpose.

with jpct-ae engine i can easily control the render order of multiple Worlds, very flexible - my app uses dozens of RenderScene calls to render the whole scene. i have to thank Egon for providing this engine and his much support.

Needs https://www.youtube.com/watch?v=dv13gl0a-FA as background music just for the meme, hehe

Nice work though!
Does it also take into account that the friction coefficient could be different for surfaces? (road vs. grass for instance)
Or is that to be planned?

Personally not a big fan of using IDE's on a small device but it's nice and cool to see that it is possible

I'm not sure what you entirely mean...
I think it wouldn't be necessary as the engine doesn't create RenderTextures on its own that are bound to the FrameBuffer.
The only RenderTextures that the FrameBuffer uses are made by you, so you should have control over these RenderTexture instances..?
If no RenderTexture is set, "null" is used.