physics test help

[Thomas.]

I created simple application with using jPCT-AE and jBullet, before implementation physics into my game. But it is very, very slow on my Galaxy S calculations only 6 boxes take 11ms. I wonder how fast it runs on other devices. Could you send me your result?




You can download test app here.

results:
Hummingbird - 11.3ms (Galaxy S 4.0.3)
Ti Omap 4430 - 8.5ms (? 2.3.x)
Nvidia Tegra 2 - 9.6ms (? 3.x)
Qualcomm MSM8255 - 12.5ms (Xperia Neo 2.3.4), 12.4ms (Xperia Neo ?)
Qualcomm QSD8250 - 16.8ms (Desire 2.2.x)
Qualcomm MSM8260 - 14.7ms (Sensation 2.3.x)
Qualcomm MSM7227 - 28.5ms (Galaxy Mini 2.2), 23.4 ms (? ?)
Exynos 4210 - 9.1ms (Galaxy S2 ?)
Nvidia Tegra 3 - 8.6ms (Transformer Prime 3.x)
Qualcomm MSM8260 - 15.2ms (Evo 3D 2.3.x), 13ms (Evo 3D ?)

[K24A3]

8.5ms on an Omap 4430 with gingerbread
9.6ms on a Tegra2 with honeycomb

[EgonOlsen]

But 11ms still mean around 100fps....which the device can't even display, because it's limited to 57. I wouldn't call this very very slow...

[Thomas.]

8.5ms on an Omap 4430 with gingerbread
9.6ms on a Tegra2 with honeycomb

Thanks for your results so dual core does not play a big role.
On my sisters xperia neo it is 12,5ms

But 11ms still mean around 100fps....which the device can't even display, because it's limited to 57. I wouldn't call this very very slow...

But it is just calculation physics with 6 boxes and one ground, in every frame is also needed render scene (10ms), check player collision (6ms),  collision for sun effects (4ms not in every frame) ... next shooting, AI in future... now my game running 55 frame per second, but theoretically when I add just 6 boxes and one ground,  number of frames drop down to 36. Perhaps I was expecting miracles from mobile device

[EgonOlsen]

36fps is still pretty good IMHO.

[Thomas.]

I modified the first post and add all result that I have and updated version of app. I got mail from developer of jBullet, multithreading not in the plan and he recommend use original native Bullet on Android.

[K24A3]

11ms for 6 boxes does seem a bit too much in my opinion. It all adds up when there are many other systems running in the background.
Even when idle, the physics were taking up around 3-4ms which seems a bit odd. You would think that if the objects were in an idle state it would be less than 1ms. Perhaps the engine is constantly checking for terrain collision or something.. My own physics engine only uses around 4-7ms on 60+ objects (however it's not quite as fancy as jBullet, it only controls xyz movement, direction based rotation, boundary avoidance, and directional path finding. No Havok-style effects yet :p ).

But as Egon said, 36FPS is not bad for a mobile device. I'm happy with 20FPS+ myself. Anything lower causes noticeable jittering.

You could probably add your own multithreading. Create a separate thread to process the physics (jBullet) and use serialization to make both threads interact in a timely fashion. But that may be too much effort to justify the extra complexity depending on your needs.

[Thomas.]

Was uploaded new version "for fun". By tap is fired sphere, by long tap you can move with object
Egon: have you planning add ShadowHelper and ReflectionHelper also to jPCT-AE?

[EgonOlsen]

Egon: have you planning add ShadowHelper and ReflectionHelper also to jPCT-AE?

Both would be ES 2.0 only anyway. I'm not sure about the reflection thing, but i'll add shadow support in the future, i just don't know when. In fact, you could already do shadows...the option to render a depth map is already present. You "just" would have to write a shader to do the projective texturing and the unpacking/depth comparison of/with that depth map.

[Thomas.]

Ok, I looking forwart to next update

[kburden000]

Egon

With your hints I got shadows working in jPCT with ShaowHelper as per post http://www.jpct.net/forum2/index.php/topic,2626.0.html
Now I too need shadows on jPCT-AE.

I see that you've "promised" to implement ShadowHelper in AE "someday". Maybe this week? 

Anyway I'll go back to my shaders and try making a projective shader again.
I see the overall schema in jpct-ae/examples/HelloShader

You said in your replay above "just".
This indicates to me that this will be non-trivial so any additional hints or samples you could throw my way?

Also I'd like to develop the shader on my desktop using non-Android environment as this goes faster and then port/test in Android.
Do you have any warnings about developing with jPCT this way, above and beyond the usual package restrictions?

Thanks in advance

[EgonOlsen]

No...certainly not this week or month or...I have at least two other major things to do before this and time is rather limited ATM. So don't count on it.

What is already present (as written above), is the option to render into a depth map. You can do this by calling setAsShadowMap(true) on a texture and assign this texture as render target. But because i wasn't able to get rendering into a depth texture working on Android, it renders the actual depth values in a color map in bitpacked format. So your shader has to take this color information, unpack it to a depth value and do the projection/depth comparison thing.

The unpacking code isn't currently in jPCT-AE...i can post a GLSL-snippet that should do the trick later. Please remember me in case i forget this...

Another problem with making this an oficial engine feature is that it would make the number of shaders explode, because i would at least have to duplicate every default shader. However, if you limit yourself to your own stuff, you don't have to do this.

[EgonOlsen]

This is the unpacking code:

Code Select Expand


vec4 SHIFTY= vec4(1.0 / (256.0 * 256.0 * 256.0), 1.0 / (256.0 * 256.0), 1.0 / 256.0, 1);
float depth= dot(valueFromDepthTexture, SHIFTY);
...


[kburden000]

Danke