This project has moved and is read-only. For the latest updates, please go here.

Clipper is slow...

Jan 31, 2011 at 4:13 AM

I am creating a bomb survival game and am using the clipper that comes with the farseer system. I have finished the game ( it rocks, will post link soon ) and am working on the perf aspect. It uses destructable terrain with the clipper, but is waaaaayyy to slow after I deconstruct several times. I already use the AABB system to only difference and deconstruct the polygons that are effected by my explosion, but I am still having perf problems.

I know that the MarchingSquares algorithm is the correct one to use in the future, but I am wanting to post my app sooner than when the squares system will be operational. What I want to know is 1. is their some tips or tricks to speed up the clipper and 2. do you have suggestions for making a stripped down version of my own and 3. when can I get my hands on the MarchingSquares system?

By the way, you guys rock! The fact that a physics engine of this rank is amazing. Keep up the good work!

Jan 31, 2011 at 1:08 PM

There probably isn't too much you can do about it. I have some small optimizations but it won't make such a big difference. The clipper is better suited for combining 2 objects at runtime... in the sense of welding to objects together or performing other small boolean operations between 2 objects. For a completly destructable terrain I'd rather wait until Matt has finished the marching squares thingy :/

There might be lots of room for more optimizations in the YuPeng clipper, but the math behind it is fairly complex. If you want to take a shot at it anyway: Here you can find the paper which describes how it works

Jan 31, 2011 at 9:08 PM

How did the old clipper perform when subtracting, did you ever test that Elsch? Just wondering.

Feb 1, 2011 at 12:11 PM

The old clipper didn't produced correct results in many not so common cases. I just worked reliable with two convex objects with partial overlap and wasn't very robust in most cases. The kind of operation doesn't make any difference with the current clipper though. I just meant to say it is complicated to use with more than a few objects.

The problem is if an operation generates holes or several polygons you need to keep track of it. And additional operations have to be applied pairwise to all polygons at least... so some partition which keeps you from rebuilding the whole geometry for every operation is needed to make that feasible. Since marching squares seems to provide that innately it is probably more suited for destructible terrain.

I'd like to enhance the clipper in a way that it takes several polygons at once and performs an operation on all of them... but the algorithm is quite complicated and I'm not sure if it is possible at all. Will look into it however if I find the time. I should be done with the work on the samples by the end of the week... hopefully :)