Page 1 of 1
Reducing the complexity of SphereShapes
Posted: Wed Sep 05, 2012 10:16 am
by zygmuntix
Hi all,
I am now making a game in which you control a character made of balls. You can shoot many balls at the same time (max is now about 200) and of course it is very time-consuming for the engine. That is why I would like to reduce the complexity of the SphereShapes - but I don't see the code in the BEPU Physics engine where I can change it (reducing the number of vertices for SphereShape is I think the best idea, am I right?).
Can someone help me with this? Thanks in advance.
Re: Reducing the complexity of SphereShapes
Posted: Wed Sep 05, 2012 4:50 pm
by Norbo
The SphereShape itself has no vertices; its shape is defined by a very cheap function. Is the slowdown actually related to the physics time? I would recommend grabbing a profiler to see where time is actually being spent. It's almost universally a waste of time to merely guess what is slowing things down without measurements.
If it's a graphical issue and you're using the BEPUphysicsDrawer, note that the BEPUphysicsDrawer is designed for the demos and debug visualization. It should not be used as a game's primary renderer. BEPUphysics itself has no concept of graphics; any graphics system can be used to represent the physics.
Re: Reducing the complexity of SphereShapes
Posted: Wed Sep 05, 2012 8:13 pm
by zygmuntix
The FPS decrease much when I shoot many balls from my character (not in all cases... but mostly when I shoot this balls on trees which collision shapes are bounding boxes). I think this is because of number of collisions BEPU has to resolve during such process (many balls can collide with each other in such case).
Re: Reducing the complexity of SphereShapes
Posted: Wed Sep 05, 2012 8:57 pm
by Norbo
I'm afraid I can't offer much advice without more information. Anything you can give me could help. As always, the most helpful thing would be an isolated, runnable project with source (perhaps a modified demo in the BEPUphysicsDemos) that I can examine more closely to see what could be improved.
Guessing the source of a performance problem without sufficient data is inefficient enough; attempting to remotely guess the source of a performance problem without even seeing the simulation is even worse
