Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I am making a 3D physics engine for throwing dice. Up until now a dice has been 1x1x1m and gravity has been 9.82 m/s^2. This of course does not look realistic as the dice will respond to everything in a way that looks a little bit slow.

To fix this I tried to just change all sizes to make a dice be about 0.02m along a side. This in turn made my inverse masses and inverse inertia matrices get very large values which lead to numerical instability.

What is the best route to handle this? Can I keep the scale up so that a dice is 1x1x1 and just change mass or size of acting forces? Or should I tweak something else?

I guess the same problem could turn up if you made a game with very large physical bodies like spaceships or something so I hope that someone has run into something similar before.

share|improve this question
    
I'm no expert here, but, without any code, how can we know what's the problem? I'm probably wrong, though, as Box2D has the same issues. –  akled Jul 19 '12 at 13:54
1  
(Seeing all the upvotes, there must be a conventional way of coding these things, and people seem to know what's you problem. I guess I was wrong.) –  akled Jul 19 '12 at 13:55
1  
Yes I thought there might be a conventional way to handle it. As I see it this is not a code problem but rather an issue with numerical precision. What I am after is not a code snippet to solve my problem but rather an explanation of an approach to the issue. –  Mikael Högström Jul 19 '12 at 14:29
    
Do you mean floating point precision? –  akled Jul 19 '12 at 14:30
    
In a sense yes. The inverse of the inertia matrix which I use in the collision handling gets very large values. It is not actually ill conditioned as the pivot-elements get large values and there is not a lot of addition going on but somehow there must be a problem with numerical precision as the simulation quickly spins out of control. –  Mikael Högström Jul 20 '12 at 8:43
add comment

4 Answers

up vote 1 down vote accepted

You could

  • increase the gravity constant? Games often use 2 * 9.81 m/s^2. Can't remember where I read this, but games usally use none-sensical units. Whatever constants feel right (make the game fun). Using a realistic constant makes the physics seem slow and floaty.
  • run the simulation at a faster rate. If you're using a fixed timestep, this will increase the rate of animation.
  • use higher precision floats?
share|improve this answer
    
The second point wont do anything but make the simulation smoother, or maybe even break it if the simulation is ran too fast (I'm not sure if this is a realistic problem, but if the world steps before a millisecond has passed, the time difference would always be 0, and nothing would work). He might not want to waste memory on higher precision floats, either. –  akled Jul 19 '12 at 17:00
1  
Games often use double gravity? Says who? –  GameDev-er Jul 19 '12 at 17:29
    
I can't change rate or accuracy but I'll try changing gravity. –  Mikael Högström Jul 20 '12 at 9:05
    
Changing gravity constant makes the dice generally move faster, giving the impression that everything is in a smaller scale. This makes the behaviour more jittery though even with microcollisions to handle between-frame acceleration. I guess I'll just have to tweak it :) –  Mikael Högström Jul 23 '12 at 12:48
add comment

In case you are having troubles with small numerical values, I suggest that you simply scale everything down. You might even not use "real" measurment units, but just some "generic" units that only make sense inside the engine.

The first option, scaling down, would require that you use millimeters or centimeters as a base measurement unit. Your cube's dimensions wouldn't suffer from loss of precision, then.

The second solution is basically the same thing, but then you wouldn't need to think about the actual units.

Also, why don't you just change the cube's mass?

share|improve this answer
    
Since the only force generators I have are gravity/accelerometer based changing mass does not change behaviour. Your suggestion could be used in the other way around though (maybe that's what you meant) giving small objects bigger mass, making their inverse masses closer to one and thus reducing numerical instability. This gives the same issues as just increasing the gravity constant though. –  Mikael Högström Jul 23 '12 at 12:51
add comment

Bullet Physics library has a wiki page about scaling the physics world. This information is probably useful with other physics engines as well.

share|improve this answer
    
Thanks, good stuff! –  Mikael Högström Aug 17 '12 at 8:40
add comment

I thought I should share my final solution to the problem. Increasing the gravity constant as suggested did indeed make the dice move faster thus giving the impression of correct scale. This, however, increased issues of microbouncing. I added microcollisions which mitigated the problem although did not solve it perfectly. Note that this becomes a problem only for "small" objects, if you are having the reverse issue and want to simulate very large objects (spaceships or something like that) then you won't be getting any microbouncing problems at all and can contend with that solution.

So I found the highest level of gravity I could have without getting way too much "microbouncing". Then I used a simple shake-detection on the phone which responded to large changes from the accelerometer readings and applied impulses to all the objects when such shakes are detected. It isn't perfect but as it will set the dice moving fast when phone is shaken it will give an impression of "tiny" dice. It's a bit of a hack but it will have to do :) Here's a clip of the engine in action.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.