wonderfull the new update !!

Discuss any questions about BEPUphysics or problems encountered.
Post Reply
sueds
Posts: 43
Joined: Tue Feb 05, 2008 10:40 am

wonderfull the new update !!

Post by sueds »

hello,

I'm glad to see the new version coming out ! I've check the whole demo and red a bit the documentation but I didn't had the time play with the code. even so I have a few question about the speed issue ( always my problem).

I've switch off the instancing and it works better. Some demo remains slow ( the buoyancy for example). I noticed that you use the island to enable or disable entities, ( it's seems so but I'm not sure) so I do not know where the problem with some demo, remains under 15 fps.

Can you explain me how your island system is working ?

nice new features by the way,really happy you get through this!
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: wonderfull the new update !!

Post by Norbo »

Thinking about it a while, I'm almost positive most of the slowdowns you're experiencing are actually caused by the demos graphics system. Despite dropping down to CPU instancing, the engine still makes heavy use of per-pixel lighting and such, which can slow down some cards significantly. I suspect if you toggle the drawing of entities by pressing 'Y' your FPS on many simulations will jump up a huge amount.

I tried to verify this idea by using my old 1.6ghz laptop with integrated graphics (runs in CPU instancing mode by default). Buoyancy, for example, with all of the objects asleep (and so very few physics calculations going on) still causes a drop to ~20 fps at times while looking at the blocks. Since the cpu instancing mode has view frustum culling, looking away gives me 60 FPS and low CPU usage. Other simulations that really hurt the laptop bad are the terrain-using ones; they run at about 10-12 fps regardless of what's going on physically (turning off entity display brings it to 60 fps here too).

Some simulations, like Jenga mid-smash, are genuinely hard on the CPU due to physical calculations (got down to around 10-20 FPS on the laptop during the bad parts without rendering entities). I think you'll find that in most cases the graphics system is to blame.

Which brings me to a possible solution; since it is likely that overuse of fancy pixel shading is a large cause of the slowdowns, changing the draw system to not use per pixel lighting would probably provide significant performance benefits. Other changes, like disabling lighting in general, could further improve it. If the graphics still run slowly, then I will need to take a look at the structure of my drawing system to make sure something isn't horribly wrong.

So, overall, good news is that the physics are probably not the cause of the low FPS, bad news is my graphics system is probably harming me significantly marketing-wise. I've also discovered a little bug I hadn't noticed before with compound bodies drawing in CPU instancing mode on my laptop- or more precisely, not drawing at all. In an effort to fix these problems, I'll probably release a demos update in the relatively near future (depending on external workloads).

In regards to the physics part of the physics engine (:D), the simulation island system works by merging and splitting groups of entities as they come near each other or go away from each other. Being "near" is determined by intersection of the entities' surrounding bounding boxes. When all objects within an island become still, the island can be turned off immediately rather than periodically. The computational upkeep involved in checking the number of deactivation candidates within an island is essentially zero; the same computations were present in the old system. The only new overhead is the merging/splitting of islands performed when controllers are created/removed; this process is still rather cheap, composing a tiny blip on the profiling radar compared to collision detection, response, and many other routines. The main goal of the new system is to prevent the occasional 'jump' that occurred in the old periodic sleep system, where some objects might not be ready to sleep yet and cause a wave to propagate through a large structure (like the pyramid). There's still some possible improvements; in some situations where the periodic sleep system would have forced most objects to sleep, the islands will keep a large amount of objects awake because one involved box is sliding a little bit. I'd like to try and figure out a good compromise that takes the best of both; in most situations, though, the island system works a good bit better.

As always, thanks for trying it out!
Post Reply