Nibbla / jbullet-jme

Automatically exported from code.google.com/p/jbullet-jme
0 stars 0 forks source link

Debug view performance enhancement #42

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
Implement some form a caching so the line objects are not recreated every
frame.

Most sensible approach would be to use the id bullet assigned the object
being rendered.

Original issue reported on code.google.com by westcoas...@hotmail.co.uk on 11 Apr 2010 at 2:34

GoogleCodeExporter commented 8 years ago
Work has now begun

Original comment by westcoas...@hotmail.co.uk on 11 Apr 2010 at 2:39

GoogleCodeExporter commented 8 years ago
The caching of objects is completed, ending up using the reference to the
com.bulletphysics.collision.dispatch.CollisionObject

This did not provide the performance boost I was expecting for high poly count
objects, so I've also added VBO use, which did increase performance.
Even using VBO the rendering performance (of the lines) doesn't match that of 
the JME
wireframe state (on a TriMesh), so this'll be the next point of investigation -
creating a TriMesh with a wireframe state instead of line.

Original comment by westcoas...@hotmail.co.uk on 18 Apr 2010 at 9:11

GoogleCodeExporter commented 8 years ago
Excellent result!
I've now switched the rendering from using Line to TriMesh and there has been a
substantial gain in FPS. 
> 130K with Line ~ 40FPS
> 130K with TriMesh ~ 60FPS (this is the cap imposed by the game state, it 
managed
60FPS with 3 of the high poly objects!)

Still refactoring to perform (as it's looking like a mono-class), change colours
according to bullet state & cater for compound shape.

Original comment by westcoas...@hotmail.co.uk on 2 May 2010 at 10:02

GoogleCodeExporter commented 8 years ago
Major refactoring of the classes involved in the debug bounds rendering.

Brief overview: altered the structure to fit in a more OO style, using Command
pattern during creation and encapsulation of behaviour within the 
RigidBodyWireframe
classes. This is a prelude to implementing colour dependant on the object state
(asleep / awake / sleepy).

Original comment by westcoas...@hotmail.co.uk on 8 May 2010 at 5:31

GoogleCodeExporter commented 8 years ago
Completed the wireframe colours based on the object type and state

Original comment by westcoas...@hotmail.co.uk on 15 May 2010 at 5:25

GoogleCodeExporter commented 8 years ago

Original comment by westcoas...@hotmail.co.uk on 19 May 2010 at 9:09