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

Modifying Geometries on the fly

Dec 19, 2008 at 10:38 AM
Edited Dec 19, 2008 at 10:40 AM
I'm pretty new to this physics engine but it all it's capabilities are really exicting. 

So far I have a working prototype of deformable terrian. You click and a bomb spawns, it falls down, explodes and makes a dent in the surface of the terrain. I used extensions I think were made by Dr. Deth using the subtract verticies method. Then once the verts have been subtracted I rebuild my terrain geometry. This is all fine and dandy, but the problem is in creating a new geometry to update the terrain every time a bomb goes off. The game stutters for a split-second and it would be annoying during gameplay.

After some more playing around I came across the geom.SetVertices(verts). So now instead of deleting and respawning a geometry, I tried to use the setVerts. In the debug view when I do this the changes are immediate and clearly visable. But the problem is that the collision doesn't seem to be updated along with the verticies. I tried geom.ComputeCollisionGrid() but then my verticies disapear off the screen, same happens thing when I try and do geom.SetBody().

What I am asking for is a way to modify/deform the geometry itself without rebuilding it or if there is any other way to update the terrain geometry that wouldn't make the game stutter.
Dec 19, 2008 at 12:48 PM
When you create a new geometry in Farseer Physics, it needs to calculate what is called a distance grid. The grid takes some time to calculate, but once that is done, the collision detection will be quicker. The time it takes to calculate the grid depends on the "collision grid cell size" that is set before creating the grid.

You might want to try and change the collision grid cell size value. You can read about this in our manual Farseer Physics 2.0 manual
You might also want to chunk up your landscape. A small geometry will be quicker to calculate than a larger geometry.

We are working on an alternative to the distance grid in 2.1.
Dec 19, 2008 at 9:40 PM
As Ian said this is currently impossible. I will be working on a new type of geometry that can be used the same way as it currently is just with no initialization needed other then a decomposition if it is concave. Also I will be looking at implementing boolean capable geometries. This would allow a box to have a hole by using a square geometry and a subtracted circular geometry. You can read more on my goals in the 2.1 engine discussion.
Dec 23, 2008 at 1:41 AM
Thanks for your responses I got everything working pretty much just the way I want it.

Now I have a question about joints and springs.

I'm trying to make like a real tank with the main body, the roller wheels, the driver wheels etc... So I'm starting with the roller wheels under then tank and I have linear springs that connect straight up and down between each wheel and the tank so that they are kinda like pistons, but now I'm trying to figure out what to do about rotations. I tried to make an angle spring between each roller wheel and the main tank body and set different target angles but they don't really do anything. When I set different target angles for the angle springs the roller wheels just spin like crazy but do not move anywhere. Is there a way I can just limit the rotation and just have a linear spring? I read the manual a few times but I didn't really see how I would do it. Maybe another way would be to make linear springs between each of the wheels and then to the driver wheels at each end but that seems overly complicated for what I want to do.
Dec 23, 2008 at 2:42 AM
I've actually made a complete M1A2 tank awhile back. The main thing is making sure your collision groups are set up properly. For my road wheels I used a revolute joint to connect the road wheel arm to the hull of the tank and another revolute joint to connect the road wheel itself to the arm. I tried using angle springs on the arms, but that required to much force (torque) to hold the tank hull up. I ended up using springs connected from the end of the arm straight up to the middle of the hull. I don't have the code anymore, but I will gladly draw you up a picture if you need additional help. Also remember you can make the track using the Path class and the ComplexFactory.

On another note I have been wanting to make a geometry creation helper to help make geometry's like gears and other shapes (sorry can't think of any right now lol). If you end up making anything like that be sure to donate it to the engine. (The drive sprocket was the only think I was missing)
Dec 23, 2008 at 3:08 AM
I'm not quite sure what you are referring to by the arm. A drawing would be much appreciated, thanks!

Hmm a geometry helper eh? I'll have to try something out.
Dec 24, 2008 at 12:41 AM
No problem, give me about a day to get you a diagram as it is Christmas, I have a ton of other stuff going on, but I should have one for you by tomorrow night at the latest.
Dec 24, 2008 at 1:17 AM
Edited Dec 24, 2008 at 1:18 AM
Alright thanks!

I have one more question. How would I go about placing characters in my game? I want to check for collision with terrian but I dont want them to go rotating around and stuff. I mean as far as collisions go I know I can just put them in specific groups but it wont help them from tipping over on an un-even static surface. Maybe using body's and geometries isn't the best idea for things like players and AI but I want to be able to check collision with the terrian mesh (my other alternative is per pixel collision).
Dec 24, 2008 at 4:17 PM
I saw a YouTube video of someone using an ellipse to define their character. It seemed to work great and I think the same method could be used in Farseer. To keep the body from rotating you would need to use a FixedAngleJoint on it if I am not mistaken (I don't have any code in front of me right now). Using impulses is the best method for the physics engine to handle your character, however using impulses can cause difficultly in getting your character to move as expected. You could also move your characters Position manually every frame, but you would have to due a lot of work to make sure it only affected the simulation as expected. 

Character control is one of the most important aspects of any game so be sure to get as much feedback as possible and don't be afraid to take criticism on how you have implemented it wrong. In the end there will always be someone that doesn't like how your character is controlled. I know myself and Ian (genbox) will always gladly review prototypes and give any advice we can.

Also, I'm working on that diagram right now.
Dec 26, 2008 at 5:47 PM
Here is the diagram. I hope this makes sense now.
Dec 31, 2008 at 4:49 PM
I would be very interested in an alternative to distance grids too. So I am glad it is being considered.