Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411278 Posts in 69323 Topics- by 58380 Members - Latest Member: bob1029

March 28, 2024, 12:53:36 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)How do YOU implement Physics?
Pages: [1] 2
Print
Author Topic: How do YOU implement Physics?  (Read 2685 times)
Photon
Level 4
****


View Profile
« on: December 05, 2015, 04:40:13 PM »

I'm curious about this. I know there are a lot of different physics libraries out there but they can often carry unwanted "realistic physics" baggage (go figure) with them that you have to try so hard to step around. Do you prefer to try bending an established engine to your will or do you just like to write physics code from scratch? If you do use a physics engine, which do you prefer and why?
« Last Edit: December 05, 2015, 04:47:15 PM by Photon » Logged
Polly
Level 6
*



View Profile
« Reply #1 on: December 05, 2015, 05:22:35 PM »

Do you prefer to try bending an established engine to your will or do you just like to write physics code from scratch?

Tailor-made from scratch.
Logged
qMopey
Level 6
*


View Profile WWW
« Reply #2 on: December 05, 2015, 07:02:25 PM »

Personally I like to sweep things (like characters) and use a seidel plane solver to resolve time of impact (TOI) events. This gives a nice result, and to simplify things I usually forego dynamic rotation and only do linear casts. It's a pretty good general purpose solution for moving things vs the world. Movement itself would be fine-controlled by character/AI controllers on a specific case-by-case basis, done by directly setting velocity.

This is pretty much what would happen in older FPS games. However, older FPS games would always use a BSP to represent the world as planes, then shrink the player to a point and expand/bevel planes of the world. Nowadays this is pretty slow in terms of cache utilization and so doesn't really make sense anymore.

Nowadays it's good to use more brute-forcey approaches to gain good performance, with the use of SIMD + multithreading -- but this is just if you want to simulate a lot of stuff, most of the time just using raw floats on single core is still very fast.
Logged
Photon
Level 4
****


View Profile
« Reply #3 on: December 05, 2015, 07:11:47 PM »

Personally I like to sweep things (like characters) and use a seidel plane solver to resolve time of impact (TOI) events.
Undecided

Mind explaining (or at least pointing to a good reference?)
Logged
qMopey
Level 6
*


View Profile WWW
« Reply #4 on: December 05, 2015, 10:43:03 PM »

Personally I like to sweep things (like characters) and use a seidel plane solver to resolve time of impact (TOI) events.
Undecided

Mind explaining (or at least pointing to a good reference?)

Sure, here's pseudo code:

Quote
const factor = TUNING_PARAM_SCALAR
depth = -infinity

while 1
   for each plane p intersecting character c
      dist = p.Depth( c )
      depth = max( dist, depth )
      c.position += p.normal * dist * factor

   if ( depth < TOLERANCE )
      break;

If intersecting planes after sweep, find those planes, project character slightly above the plane (via tuning param), check if converge below tolerance and exit via convergence (or exit via failure with max iterations achieved (not shown in pseudo code)).

So overall we sweep player to plane surface, backup slightly along the normal to give some breathing room for the next sweep, and continue. When backing up along the normal to create breathing room for the next sweep it's possible to backup into another plane, especially if a character runs into corners with acute angles. So, if that happens, gently press the player out of all planes to create breathing room between all planes. When I say gently this means a tuning parameter is used to prevent overshoot (so like 0.2f or something). After this gentle press you may need to fixup velocity since a character was just moved on the position level (when I had originally assumed characters are controlled on a velocity level).
Edit:
Here's a little more info: http://www.gamedev.net/topic/669319-how-do-you-respond-to-collision-with-line-segments/
« Last Edit: December 05, 2015, 10:48:15 PM by qMopey » Logged
fractilegames
Level 1
*



View Profile WWW
« Reply #5 on: December 09, 2015, 12:30:15 AM »

Long time ago I used to write my own physics code for my fairly simple 2D games. At some point I needed more advanced stuff and simply didn't have the math skills needed to implement those, so I switched to a physics library (Newton dynamics at the time).

Since then I have switched to Bullet physics, which was a lot more stable (development-wise, less bugs and API breaks). Now I use it for even the simplest 2D games. It is just so much easier and I don't have to spend time writing and maintaining my own physics code. At times it might have been easier to have "less realistic" physics, but now that I have learnt to deal with this, I'm not going back.
Logged

Oats
Level 1
*


High starch content.


View Profile
« Reply #6 on: December 15, 2015, 06:24:29 PM »

Long time ago I used to write my own physics code for my fairly simple 2D games. At some point I needed more advanced stuff and simply didn't have the math skills needed to implement those, so I switched to a physics library (Newton dynamics at the time).

Since then I have switched to Bullet physics, which was a lot more stable (development-wise, less bugs and API breaks). Now I use it for even the simplest 2D games. It is just so much easier and I don't have to spend time writing and maintaining my own physics code. At times it might have been easier to have "less realistic" physics, but now that I have learnt to deal with this, I'm not going back.

It's weird you're saying this, because I started with bullet recently and it just tired me out more then necessary, and I found most my time with it was just figuring out how to remove unwanted features. In key I don't think quaternion and matrix transformation is actually very useful, at least for the kinds of games I make having things move and collide semi-realistically just makes figuring out game logic a pain in the ass. So I'm currently writing my own open source game physics engine called fluffy physics, which will be designed to be more easily modifiable, and like it's name suggests it will use non-realistic physics, but still have deterministic semi-fixed time step, and be very thread safe (and very fast  Well, hello there!), the only default collision shape I'm implementing is AABB (but more shapes can be added user side as a customisable narrow phase, and I'm writing an included optional narrow phase myself with raycasting and spheres and other simple stuff). 
Logged

eh
J-Snake
Level 10
*****


A fool with a tool is still a fool.


View Profile WWW
« Reply #7 on: December 15, 2015, 06:35:53 PM »

That's not a bad start:
http://www.amazon.de/Game-Physics-Engine-Development-Commercial-Grade/dp/0123819768

Logged

Independent game developer with an elaborate focus on interesting gameplay, rewarding depth of play and technical quality.<br /><br />Trap Them: http://store.steampowered.com/app/375930
oahda
Level 10
*****



View Profile
« Reply #8 on: December 16, 2015, 06:30:57 AM »

I thought Bullet was 3D.
Logged

Cheesegrater
Level 1
*



View Profile
« Reply #9 on: December 16, 2015, 06:51:26 AM »

It is, but you can put constraints on your bodies to keep them moving in a 2D plane.
Logged
oahda
Level 10
*****



View Profile
« Reply #10 on: December 16, 2015, 08:59:30 AM »

Sounds like there would still be some overhead with unnecessary 3D data and stuff. But I guess if a 3D game can run fine actually using Bullet in 3D...

Seems weird to pick Bullet for a 2D engine anyway, since there's Box2D and other engines out there.
Logged

fractilegames
Level 1
*



View Profile WWW
« Reply #11 on: December 17, 2015, 03:04:13 AM »

Long time ago I used to write my own physics code for my fairly simple 2D games. At some point I needed more advanced stuff and simply didn't have the math skills needed to implement those, so I switched to a physics library (Newton dynamics at the time).

Since then I have switched to Bullet physics, which was a lot more stable (development-wise, less bugs and API breaks). Now I use it for even the simplest 2D games. It is just so much easier and I don't have to spend time writing and maintaining my own physics code. At times it might have been easier to have "less realistic" physics, but now that I have learnt to deal with this, I'm not going back.

It's weird you're saying this, because I started with bullet recently and it just tired me out more then necessary, and I found most my time with it was just figuring out how to remove unwanted features. In key I don't think quaternion and matrix transformation is actually very useful, at least for the kinds of games I make having things move and collide semi-realistically just makes figuring out game logic a pain in the ass. So I'm currently writing my own open source game physics engine called fluffy physics, which will be designed to be more easily modifiable, and like it's name suggests it will use non-realistic physics, but still have deterministic semi-fixed time step, and be very thread safe (and very fast  Well, hello there!), the only default collision shape I'm implementing is AABB (but more shapes can be added user side as a customisable narrow phase, and I'm writing an included optional narrow phase myself with raycasting and spheres and other simple stuff). 

The games where I have used Bullet so far are actually 2.5D games. Everything is internally 3D with motion just limited to two dimensional plane. I usually even have some objects that can move in 3D. I admit that my situation isn't really comparable to working with a "real 2D" game.

Bullet is now the easier option for me simply because I have already learnt to deal with the "unwanted features" and other problems with using it in a 2D game. I have also written quite a bit of wrappers and other reusable code that depends on Bullet.

If I would start a 2D game from a complete scratch now, I would probably look into Box2D or some other more 2D-oriented physics engine.
Logged

phosphorous
Level 0
**



View Profile WWW
« Reply #12 on: December 18, 2015, 06:31:47 AM »

I prefer using existing engines because:
- I usually want to focus making a game, not a physics engine (I have made one proper before, a 2D euler-integrator, do recommend as learning exercise if learning is your goal),
- it is faster to use existing one, unless you have very simple requirements
- they most likely can do exactly what you want if you choose the right one and know how to use them,
- you build up experience using them that helps you the next time,
- they are in most likely better made and maintained than what you could whip up, unless you already have experience and expertise in making physics-engines.
Logged
buto
Level 0
***



View Profile WWW
« Reply #13 on: December 28, 2015, 02:01:58 PM »

I've been working with my own (2d) physics library for quite some time now. It's a little bit special since it is based on soft-bodies, i.e., on particles that are interconnected by springs. Each particle has a velocity and a specific mass, each spring has a predefined equilibrium length and a spring constant. By choosing the equilibrium length of each spring such that the particles rest in some desired shape, one can build abstract characters and simple shapes (e.g. a sphere, a rectangle with sharp or rounded corners, etc). I then pin a triangular net to those particles and apply textures to that net to create deformable, soft sprites.

Throughout the game I advance the system with a fixed time-step using numerical integration. External forces can be applied to each particle or the velocity of a particle can be set to a specific value. The rest of the soft-body reacts in some meaningful way (not necessarily realistic). I use this approach both for characters and fluids.

The surrounding world is represented by a 2d unstructured triangle grid. I perform collision detection of each particle with the edges of that grid. If a particle moves across an edge, I mirror it's direction and velocity. The rest of the soft-body will automatically adjust accordingly.

If bodies collide I simply push the particles of each body behind a virtual separating plane. At this point one can adjust velocities based on different friction parameters etc.

This approach has its benefits, since it allows for highly dynamic game-play with fluid motions that give a good sense of inertia and force. If a character hits a wall, it deforms before being pushed back. With a more rigid approach one would have to simulate this with special animations, which would of course result in a higher burden on the artist.

The approach has drawbacks too, of course. I think the types of games that can be created with such an engine are restricted. Since most bodies we in interact with in real life are rather solid, using a purely soft-body physics-engine may not be a good idea for realistic games. It can furthermore be a little hard to get a soft-body to behave exactly the way one wants him to. E.g. max-jump-height etc. Furthermore, there is no clearly defined up or down of such bodies. This makes it a little hard to use it for classical platformers or similar games.

Nevertheless, I think it has a rather unique feeling to it and it allows for some nice interaction between the different entities in a game.

Regards,
Sebastian
Logged

buto
Level 0
***



View Profile WWW
« Reply #14 on: December 29, 2015, 05:30:30 AM »

I attached a small gif to better illustrate what I was talking about.

Logged

Layl
Level 3
***

professional jerkface


View Profile WWW
« Reply #15 on: December 29, 2015, 08:22:07 AM »

I attached a small gif to better illustrate what I was talking about.
<snip>

I was skeptical but that gif instantly convinced me, that looks really good
Logged
Oats
Level 1
*


High starch content.


View Profile
« Reply #16 on: December 29, 2015, 09:29:27 PM »

alright well I was implementing my idea for a fluffy physics engine today, and I realised that just constraining things to AABB wasn't actually fluffy enough, in fact I found myself dealing with some really fidgety bits of code, where having objects find resting positions in order to be set comfortably to inactive was really awkward, where things would be comfy most the time but occasionally things would flicker between tiny differences in floating point numbers. So I was thinking about how to have a really comfy and perfectly predictable fluffy physics engine, and decided the problem was in floating point numbers.
I was encountering the problem, where the global position of an AABB's face was the objects position + an offset, when intersection was detected, the boxs' position would be moved so they weren't colliding, then the faces would be moved by the same offset, and low and behold there would still be a tiny amount of intersection, or otherwise they weren't quite touching and the next step one would fall some more, get pushed back up etc. This was really annoying, when a = b - c, having b != a + c defies usefulness (and yes I know why it has to have finite precision, I just wish it didn't).
So I thought, what about integers? I could have object's position being stored as large integers (I'm thinking maybe something like 256 per metre?), then do a little floating point interpolation to provide smooth movement. So I was wandering if anyone has any experience using integer 3D physics, and thought I'd ask here since it already has the attention of a bunch of physics peeps, and fighting thread pollution I guess.
Logged

eh
buto
Level 0
***



View Profile WWW
« Reply #17 on: December 30, 2015, 05:15:42 AM »

@Layl, thanks for the kind words!

@Oats, I think it might be a better idea to stick with floats and to use some tricks to handle rounding issues. To this end it is often useful to define a constant SMALL (e.g. 'const float SMALL = 1.e-6'). Instead of checking for equality you can then check whether two values are nearly equal. I.e., instead of checking
Code:
if(a == b)...
you'd regard values as equal if they are close to each other:
Code:
if(fabs(b-a) < SMALL)...

Similarily if 'float c = a - b' and you want to make sure that 'b + c >= a', you'd add SMALL to the left side:
Code:
b + c + SMALL >= a

Here it may even be a good idea to add 0.5 * SMALL instead of SMALL, since this yields:
Code:
float c = a - b;
float d = b + c + 0.5 * SMALL;
// => fabs(a - d) == fabs(a - b - c - 0.5*SMALL) < SMALL

Using the 'SMALL-arithmetic' 'a' and 'd' would thus be equal.

The important thing here is that SMALL (and 0.5*SMALL in the last example) have to be bigger than the precision at which rounding-errors occur. This, however, depends on the absolute value of your variables. If you need values > 1000 (approx.) you should probably choose a higher SMALL (e.g. 1.e-4). A really (really!) in-depth discussion on floating-point issues can be found here: https://randomascii.wordpress.com/2012/09/09/game-developer-magazine-floating-point/
However, comparision with a fixed epsilon (SMALL) should be enough in many applications.

The problem I see with mixing integer and floating point operations is that you have to round at some point. Small inaccuracies can then decide whether you're rounding to the higher or to the lower integer.
Furthermore, unless your game-design is already completed, restricting your self to integers may cause trouble later on.

I hope the stuff above made sense to you!
Regards,
Sebastian
Logged

Oats
Level 1
*


High starch content.


View Profile
« Reply #18 on: January 20, 2016, 10:09:22 PM »

Welp I just went ahead and wrote an integer AAB exclusive physics engine, and it is actually pretty goddamn fine, in the test project I'm working on I have 128 units representing a metre, and since velocities are high there isn't any noticeable effect. I've implemented raycasting and I've setting myself the challenge of designing a full 3d game with nothing but AAB and rays. An added bonus to my implementation is that because AAB tests are so quick, the engine scans ahead of moving objects to figure out whether they are on obstructed paths, and then smoothly plops the object where it would land. There are no cases where two objects intersect each other, fast things never phase through walls (my game uses 1 unit thick walls with no problem, in a stress test a tiny object moving 1000s of units per second found it's spot perfectly), there are no cases where objects behave jittery and everything is feeling good Smiley

@buto that's my definition of finicky code, I'm not gonna say fixed precision is the way of the future, or that it fits every purpose, but I think it has an undeserved bad rap amongst some physics buffs. Simple solutions work for simple problems, 3d projects don't have to be a nightmare Hand Thumbs Up Right (I goddamn hope! I'll tell when this game is further through...)


edit: ok screw it, I'm making my physics simpler, no more ray casting, thought about the game I'm making and realised it was pointless, also no more floating point interpolation, the scale of my game (3km cubed each metre 128 units)  was causing some wacky floating point errors, everything is now fully integer until it reaches OpenGL. Take that Institute of Electrical and Electronics Engineers!
« Last Edit: January 22, 2016, 09:30:58 PM by Oats » Logged

eh
djr
Level 0
***


Smith and Winston Coder


View Profile WWW
« Reply #19 on: January 21, 2016, 01:14:36 PM »

About 15 years ago I wrote a physics engine. I started with the tutorials online, Computational Geometry in C and the Eberly game dev books. It was pretty good but never solid enough to be triple A. About 4 years ago I started using Bullet. It's way more stable, way more powerful and significantly faster.

Granted Bullet can be a real PITA to use after the initial pretty easy integration in to your codebase. There are a shit load a tweaks that I've made to the code (especially the character controller) based on code and comments in random forum posts. So many that I'm not really sure what's mine, original or copy and pasted. There is also some uncertainty as to when the 2.8 codebase is going to die and the 3.0 code rise to the top. Since dev moved to git hub it seems to have become a bit more opaque (or maybe I'm just not a github kind if guy).

Despite all this I really appreciate Bullet for it's speed and robustness. If I wanted anything near it I'd have to pay for Havok tbh.
Logged

Pages: [1] 2
Print
Jump to:  

Theme orange-lt created by panic