Destructible terrain question...

Topics: Developer Forum, User Forum
Jan 4, 2011 at 3:06 PM


We are currently having some problems creating a 2d worms-style game with destructible terrain and realistic fluid simulation.

We were hoping to leverage the Farseer library to perform most of the game-specific physics collisions for us (player movement, raycast projectiles, thrown/fired projectiles like grenades/missiles + interaction). It seems crazy for us to re-invent the wheel when farseer can already handle this efficiently and elegantly, so we really dont want to write a cusstom physics solution.

However As far as the destructible terrain and fluid simulation, we currently have a custom working solution (not using farseer). we can click anywhere on the 2d terrain and 'dig' /'grow' it using a brush, and the fluids will act appropriately and flow around the terrain. (IF anyone has seen 'PixelJunk shooter' a PSN game you will have a VERY good idea of how our current terrain + fluids look + feel).The working code we have uses a clever spatial partitioning system much like a quad tree to allow us to quickly interact with terrain and store which 'quads' are solid terrain and which are air. We also have working edge detection algorithms to detect which quads border air etc. For now, we are not really worried abotu fluid interaction with farseer, as at this stage in the prototype, the fluids are more visual candy than gameplay affecting, and so dont need to collide with anything other than terrain (which is complete and functional).


The problem now comes when we come to gel the two solutions (farseer and our custom terrain/fluid sim) together. Essentially we need to take our terrain representation (which reflects any real-time addition + removal  that has occured.) and create a representation that farseer can understand and interact with. We seem to have come up with several possible solutions (each of which have positives and negatives), but we seem to have gotten stuck deciding how to proceed. (we have tried several methods and encountered problems).

1) Create the initial terrain representation using Farseer's Texture to vertices functionality (using a texture accurately representing the starting terrain) Then INDEPENDENTLY upate the farseer terrain representation to our game terrain/fluid representation when destruction is applied, or new terrain is added and jsut hope they stay in sync.... (dont like this idea!). This would also depend on 'cutting' into a large terrain polygon to create damage (easy enough when a large circular explosion is applied) but may get more intensive if MANY smaller circular cutouts are applied (e.g. small bullet blasts). We have tried this and seem to run into occasional crashes when cutting / adding terrain, and also have the problem of accurately representing say a circular blast, when the 'cut' that is made in the terrain may actually 'cut' using a more basic hexagon / simplified cutting shape.  Also we arent too sure if having fairly large complex shapes (imagine a high vertex terrain poly after many many bullet impacts etc) is a good idea, as it may put alot of strain on farseer. We were tempted to split all terrain polys into max size polys (e.g. grid the world into 4*4 grid, and split any terrain polys crossing those boundaries). This again seemed to cause some problems...

2) Since our spatial representation used for the terrain/fluid sim essentially can be analysed to give a list of quad building blocks, we could mirror this data to create many small rectangles for terrain edges and larger rectangles used for the undamaged 'inner' terrain. Our existing solution naturally supports this 'level of detail' system , so only terrain edges are built from small building block to represent detail, whereas large areas of unbroken terrain are represented by larger quads. This would help prevent us from creating many unecessary farseer rectangle polys. However we then have the problem that we essentially dont have smooth gradient surfaces, we have 'staircased' edges consisting of many horizontal and vertical surfaces. This may affect the bounce trajectory of say grenades / prevent smooth rolling / player terrain traversal. Theoretically if these staircases were fine enough (e.g. a grenade itself was BIGGER than the staircase blocks and couldnt fit within the gaps) this MAY not matter. However we attempted this and it could occasionally produce strange results. On a positive note, it woudl be fairly trivial to react to the creation / destruction of the terrain by pairing the quads in the custom terrain representation to their farseer counterparts.Theoretically, since we can detect edges in our customn solution, we could generate a polygone based on this, but that takes us back to the problems associated with solution (1) above.

3) We have already generated a signed distance field in our custom terrain solution, used to interact with the fluid particles. Is there any way we can convert this into/ inject this in a format Farseer can work with?

4) Another suggestion was to only add physics objects for say, player, projectiles , dynamic objects etc but NOT terrain.  Then somehow (please let me know how!!) manually detect collisions with our terrain representation ourselves, and then apply forces etc to push objects out of terrain (this sounds kinda fudgey....).


Any comments / suggestions PLEASE let me know. We can post screenshots / more info if necessary.





Jan 5, 2011 at 9:27 AM

Just a thought...


Is there a way we can manually create a list of contact points and simply tell a physics body that it needs to resolve them?. Almost like creating a phantom collision... This way we could manually tell a physics body its colliding with our terrain when we detect it,

passing the correct normal, friction, restitution, mass etc.

Jan 6, 2011 at 10:51 PM

Huge post you got there....

1. This method seem rather redundant, but in theory it should world.

2. With FPE 3.2 you can create a chain of edge shapes that outline the terrain. Edge shapes differ from polygons in that they support edge adjacency and thus provide you with seamless/smooth collisions.

3. Depends on what you are trying to achieve.

4. We expose the whole collision detection API inside the static Collision class. You can indeed create contacts yourself, but they need to be associated with fixtures inside the world. If you don't need friction, restitution or realistic collision response, you could simply check for a collision between your object and the terrain and apply the necessary response.


Now, I have some notes on the subject. We include a YuPeng Clipper you can use it to subtract polygons from each other and it works perfectly with the Vertices collection from FPE. That being said, I think FPE can provide you with everything you need, but the fluids. As you fluids solution works with a SDF algorithm, you could easily run algorithm on the terrain polygon and update the distance field once the terrain changes. This cooks the problem down to making fluids work on terrain that FPE handles.

If that is not an option, you can simply generate an outline of your terrain and a) use edge shapes with adjacency information or b) supply it as a triangulated polygon.

Jan 7, 2011 at 2:44 PM
Edited Jan 7, 2011 at 2:49 PM

Thanks for the reply !! much appreciated.

Sorry about the wall of text!!

We are currently looking at options 3 and 4. Option 2 is definitely a possibility, but at present not all developers have access to FPE 3.2 and are stuck on older versions ( for various extremely frustrating reasons ).

3) - We essentially want to use the distance field to produce the same effect we'd get if we had a collision body matching the contours of our terrain, that other regular farseer bodies will collide with.

4) - We have been playing around with this option as per your suggestion. We currently have a test object that has a large quad physics body that acts like a sensor. We implement the custom OnCollision override. When an object enters this large sensor, we test the intruding object aginst some smaller independent 'test case' polygon shape (e.g. a smaller rectangle at the centre of the test object),  use the static collision class CollidePolygons() functionality to generate a contact manifold. This seems to work correctly and produce the correct contact points / normals etc. So in that sense we know we can do collision detection with our custom terrain solution to produce the correct accurate contact points + normals. However we dont seem to be able to able to use farseer to resolve the collision for us. This is the most crucial part we need. Is there a way we can essentially use FPE to perform collision resolution for a particular body, given some artificial contact points (which we can now generate). The test object has a fixture that has all the appropriate properties e.g. restitution / friction etc.




Jan 7, 2011 at 7:31 PM

3. I'm not sure how you use the distance field. Farseer uses polygons and the SAT algorithm for collisions. If you need something to collide in FPE, you will need to use a polygon shape and the Collision class or add the shape to the engine and let it handle the rest. Else I'm not sure what you need.

4. The ContactSolver is responsible for the collision response, but I've never had the case of solving contacts outside the engine itself. While we do support manual use of the internals of the engine, it is not everything that can be used in that manner. I would suggest you look around the ContactManager and see if you can work out something. Another solution is to inject the artificial contacts into the Body contactlist.