Bullet with HeightMipTerrain runs slow?

Return to Scripting Issues

Bullet with HeightMipTerrain runs slow?

Postby drahun » Tue Apr 24, 2012 11:26 pm

I tried bullet heightfield example from the manual with my own heightmap image. but it runs slow. why?
drahun
 
Posts: 26
Joined: Wed Jul 06, 2011 4:12 am
Location: Indonesia

Postby enn0x » Wed Apr 25, 2012 4:09 am

Don't know.
Maybe because you are using a heighfield of 70000000 x 80000000 pixel?
Or because you forgot to turn of the debug renderer?
Maybe your 12MHz i368DX processor (hit the markt in 1985) needs to be upgraded?
It also might be that your expectations are simply too high?

Seriously, how should I provide an answer to such a question?
enn0x
 
Posts: 1266
Joined: Wed Nov 08, 2006 1:39 am
Location: Germany, Munich

Postby drahun » Wed Apr 25, 2012 4:38 am

thanks for the answer :lol: .
My processor is old actually. But roaming Ralph runs well with it. I don't know if it's different. The original image of the example use 33X33 image. I can run it well. I try 129X129 image but it became slow. I change nothing but the image. Okay. What make it slow?
drahun
 
Posts: 26
Joined: Wed Jul 06, 2011 4:12 am
Location: Indonesia

Postby powerpup118 » Wed Apr 25, 2012 4:51 am

Changing the size of the image will (obviously) make it slower. The bigger the image is, the slower it will be.

Also, Roaming Ralph has no physics. Roaming Ralph only has collision detection.

Perhaps you're making an horrible mistake with your code, which is seeping out performance juice as well.

Anywho, if it was me, I'd try using the 33x33 image and see how fast it runs, compared to the Roaming Ralph sample (taking into account that Roaming Ralph only uses collision detection, so it should naturally be faster) and then compare it with the 129x129 image.

Hope this helps,
~powerpup118
User avatar
powerpup118
 
Posts: 325
Joined: Sat Apr 17, 2010 11:59 pm

Postby enn0x » Wed Apr 25, 2012 5:43 am

128x128 pixel image size is not the problem. The heightfield collision should run smooth at 512x512 or 1024x1024 even on older hardware.

Drahun says that he didn't change anything in the sample, just a different heightmap. The sample has - by default - the debug renderer on. Even worse, the heighfield normals are drawn in the debug renderer. It is expected that with realistic heighfields the debug renderer will be terrible slow. This is ok, since the debug renderer is just an aid for debugging.

So turn off the debug renderer, and see if you still have low performance.
and look at the toggleHeightfield function within the sample - it shows how to disable the debug rendering only for individual bodies (the heightfield in this case, since debug rendering the heighfield is expensive with respect to performance)!
enn0x
 
Posts: 1266
Joined: Wed Nov 08, 2006 1:39 am
Location: Germany, Munich

Postby drahun » Wed Apr 25, 2012 7:09 am

Thanks. I just don't know if debug renderer make much slower.
<SOLVED>
drahun
 
Posts: 26
Joined: Wed Jul 06, 2011 4:12 am
Location: Indonesia


Return to Scripting Issues

Who is online

Users browsing this forum: Google [Bot] and 1 guest