Scale in centimeters, need clarification

[tp]

I'm trying to get Bullet working for a simulation where my real life object counterparts are measured in centimeters, and the issue with 0.2 (meter) unit precision is giving me major pains.

In trying to work out a solution, I've found some mixed advice:

A) The article at http://www.continuousphysics.com/mediaw ... _The_World lists the various aspects of scaling, but it does not mention anything about stability.

B) The thread http://www.bulletphysics.com/Bullet/php ... f=9&t=2638 talks about stability, and mentions increasing the simulation frequency to address the stability issue.

I'd love to get some more information on a couple of questions:

1) Am I correct in assuming that document A should also mention the instability, and the requirement for a higher simulation frequency? Is there something you can do to run at 60 Hz, scale up to centimeters and get a stable simulation?

2) I did not get decent results using a frequency of 240 Hz. It seemed like I needed to make it almost 100 times as much to get decent results, which is not feasible for real time simulation, obviously. How does one determine the needed frequency for a given scaling?

3) Document A mentions scaling the linear sleep threshold. I didn't get reasonable results using a uniform scaling factor (in my case 100). Is this advice based on a guesstimate or is there some actual math behind it?

4) I can understand limiting details to 0.2 meters for simulations that have a typical "playing field" size of hundreds of meters. The situation seems to me to indicate that it's impossible to do something that would look good at the scale of something like a chess board. With all that bullet has going for it (the reason I've got this far), this seems like a huge, major issue. Is there a reason for it being there? Despite my basic questions, I'm actually pretty well educated in engineering and computer science, so having an explanation on this might help me wrap my brain around the problem . Is there a fix planned, or better yet, details about what needs to be done and whether it might be ready before I go to a different physics library or if I should just wait it out for now?

Thanks for any answers.

[peltonen]

I'm facing the same problem, too. I haven't yet found a series of parameter values that work.

Does it make sense to build a demo so that we can all have a shared starting point for this?

[spitfire2005]

[...]

posting removed by moderator

[tp]

spitfire2005, I don't think your post addresses my questions. I don't wish to turn this thread into another physics theory lesson, so I'd like to limit this to a couple of brief replies and then get back to the simulation problems.

When you scale things up, you're not simply affecting object sizes, you're also affecting the distances between objects. Gravity is no different from any other force, and the effect on the perceived acceleration in the simulation is significant. It's obvious you haven't tried to do this yourself, as the effect is quite easily noticeable.

My CPU isn't slow, and that's not relevant here. In my original message, I was saying the simulation loses real time applicability when I need to run it at 6000 Hz to obtain stability.

a.)
you SHOULD use METERS as distance units

b.)
smallest shape SHOULD be 0.2 METERS

The whole topic is about a simulation where the objects are small, such as pieces on a chess board where the largest shape is about 0.05 meters.

[Erwin Coumans]

We'll try to provide a sample for upcoming 2.73 release, and document all the changes required. (some internal settings need to be scaled).

You can track the status here:
http://code.google.com/p/bullet/issues/detail?id=45

Typically we have monthly releases, so please stay tuned,
Thanks,
Erwin

[tp]

Thank you, Erwin, for the info and the work being done.

[sparkprime]

Even if Bullet understood <0.2 bodies, you would still need to increase the simulation frequency in order to get realistic results with such a stretched size:gravity ratio. The reason is that you do not want bodies falling (from rest) by a long distance between each simulation tick. This has nothing to do with scaling, as the size:gravity ratio stays the same whether each are expressed in m, cm, etc. If you mistakenly scale the world without also scaling gravity, you will see an improvement, but everything will be in "slow motion". This is not what you want.

Scaling the world is only to bring the system in general back to the 'window' of values that Bullet has been tested and tuned for. It has nothing to do with the above problem and other related problems such as tunneling.

When scaling the world, the units of each quantity tell you whether it should be changed. E.g. gravity (m/s/s) contains one distance 'm' so gets scaled up once. Linear sleep threshold (m/s) also contains one 'm' so gets scaled once. Angular sleep threshold (1/s) has no distance unit so stays the same. You can search the web for the units of other quantities.

The list on the wiki page is probably not complete, e.g. as Erwin suggests there are probably internal parameters that need to be scaled, but such parameters are probably quite well-hidden. Last time I looked, there were some global variables kicking around. Ideally everything should be exposed neatly and documented, but this hasn't happened yet.

You'd have to explain the kinds of instability you are seeing and describe the situation you're trying to simulate. Chess should be OK as it is basically snooker-scale. If you add jupiter gravity into the mix then you'll need to spend a lot of cpu cycles if you want realism.

[tp]

Even if Bullet understood <0.2 bodies, you would still need to increase the simulation frequency in order to get realistic results with such a stretched size:gravity ratio. The reason is that you do not want bodies falling (from rest) by a long distance between each simulation tick. This has nothing to do with scaling, as the size:gravity ratio stays the same whether each are expressed in m, cm, etc. If you mistakenly scale the world without also scaling gravity, you will see an improvement, but everything will be in "slow motion". This is not what you want.

So we're just talking about size:acceleration ratios really.

Basically, what you are saying is that a system scaled to 1 bullet unit = 1 cm, gravity = 1000 bullet units, would correspond to a situation where you had the standard scale of 1 meter, but used accelerations in the order of 1000 m/s^2 to shoot the 1 meter bricks around, which would lead to the problems mentioned, such as tunneling.

If I understand it correctly, you're saying that no matter what, current computer power is not sufficient to run things at this scale at 60 Hz due to hard facts from physical laws. I got the impression from Erwin that it might work. Which way is it?

When scaling the world, the units of each quantity tell you whether it should be changed. E.g. gravity (m/s/s) contains one distance 'm' so gets scaled up once. Linear sleep threshold (m/s) also contains one 'm' so gets scaled once. Angular sleep threshold (1/s) has no distance unit so stays the same. You can search the web for the units of other quantities.

Thank you for this information.

Chess should be OK as it is basically snooker-scale. If you add jupiter gravity into the mix then you'll need to spend a lot of cpu cycles if you want realism.

I didn't quite understand this. A snooker game has been reported to be problematic. If you scale it up by 10, which would bring the smaller pieces to around 0.2 units, you end up with jupiter gravity (way over that in fact). If you want objects that are 1 cm in size, you'd have to scale by 20, corresponding to shooting a 1 meter block at 200 m/s^2, which, at 20G, I think is outside the bullet "window".

[sparkprime]

Forgetting the scales for a minute; if you have blocks that are 1 unit wide, clock at 60hz, with gravity of 1000, those blocks will fall 1000(1/60)(1/60)/2 = 0.13 units every internal step. While this isn't enough to cause tunneling I expect it would produce an unrealistic simulation with objects dancing around as they react to this deep penetration. If you use 200hz they fall 1000(1/200)(1/200)/2 = 0.02 units which is a much more subtle penetration and will result in less weirdness.

Note that if we scale everything the above calculations will scale too, but the blocks will still penetrate by the same fraction of their own size. In this case, scaling doesn't matter, i.e. even if you scale appropriately you will still stress the simulation if you have unusually high gravity compared to your object size, causing objects to penetrate a lot when they fall from rest.

Also note that stacking compounds this problem as the top block in a stack of 3 will penetrate 3x as far before it gets bounced back up by the box below it.

When I said "add jupiter gravity" I meant chucking chess pieces around on jupiter, e.g. taking metres as the unit: chess pieces are approx 0.03 units wide, jupiter gravity is about 25, so 25(1/60)(1/60)/2 = 0.0034 which is about as bad as the example you gave (the chess piece will penetrate 11% of its size).

With centimetres instead of metres the penetration would still be 11%.

Since you mentioned snooker, I'll do that one too. With metres as the unit: snooker balls are about 0.04 wide, and earth gravity is 10 so 10/60/60/2 = 0.013 or in other words a snooker ball falling from rest will penetrate 3.4% of its own width. When I played with a snooker simultion I was able to get a realistic simulation at 60hz for the reason that 3.4% is still quite small, and spheres behave very well under quite deep penetration (because their collision margin goes all the way to the centre of the sphere). This is perhaps why snooker is probably the oldest rigid body simulation used in a computer game When I added cubes into the simulation, it really became necessary to increase from 60hz. There are other problems unrelated to this size:gravity thing, that can be solved either by tweaking internal parameters (that was what my post was about) or scaling the world. When you heard that snooker was problematic, it was probably not size:gravity that was the problem.