Karma Mass Test [2006.07.23]

Preface
Introduction
New equations
Experiment 1 - DrawScale dependency
Experiment 2 - Volume dependency
Experiment 3 - Finding α /β
Experiment 4 - Finding α and β
Conclusion

Preface

In this report I assumed that g= 9.8 m/s^2 and that the logged falling time is measured in seconds. Unfortunately both these assumptions are wrong. In "The scale between Unreal world and Karma physical world" report, Jijun Wang found that:

• g=19m/s^2
• the game time is different from real time by a factor of 1.1 (see his paper for details).

Experiments 1 and 2 are still valid. However, experiments 3 and 4, which are based on the previous assumptions, lead to erroneous conclusions.

Introduction

The results of this report are:

• a new uu/m scale.
• a new KActorGravScale compensation factor.
• mass scale
• force scale

If you want to see them quickly scroll down this page until you find 3 yellow equations.

Finding the right mass scale is not an easy task and it will reveal some surprise in the experiment 4.
The first thing we need to do is to find how mass depends on object volume and DrawScale parameters. Unreal Developer Network states that KMass is a density and not a mass. If it's so, the object mass should be proportional to its volume. To find if this is true, I will reuse the gravity test map. I changed the Bullet script so that it can accept an external force but it still logs the travel time when it reaches Z=0. I cannot give you this script because I use a LeggedSim extension to modulate the force with the mouse wheel.
After we have found how DrawScale and volume change an object mass we will try to find the correct mass (and force) scale.

Experiments 1, 2 and 3 will use KActorGravScale = 0 so that the only force acting on the object will be the custom external force. Experiment 4 will use KActorGravScale = 1.

New equations

M is the object mass, F is the applied force, s is the space traveled by the object. We need to find α and β, that is the mass scale factor and the force scale factor. The main equation I will be using during the tests is:

The Unreal Engine will scale M and F, so the final equation is:

Experiment 1 - DrawScale dependency

In the following tests I will apply a force F to a 128 x 128 x 64 uu box. Its volume is 1048576 uu^3. I'm not interested in α and β but only in travel time differences, so I don't need to use any equation.

Test A

KMass = 1
DrawScale = 0.2 (object volume = 209715.2 uu^3)
s = 8192uu (102.8m)
F = 1 uu

Test B

KMass = 1
DrawScale = 0.4 (object volume = 419430.4 uu^3)
s = 8192uu (102.8m)
F = 1 uu

Test C

KMass = 1
DrawScale = 0.1 (object volume = 104857.6 uu^3)
s = 8192uu (102.8m)
F = 1 uu

As the travel time is always the same the obvious conclusion is that:

DrawScale does not influences the mass of the object.

This means that I can change the object size with DrawScale at will, without scaling its mass.

If you think that α and β could be = 1, let's substitute the last table values into the equation:

This means that we have really to find these scale factors.

Experiment 2 - Volume dependency

Now I will use a 32 x 32 x 16 uu box. Its volume is 16384 uu^3.

Test D

KMass = 1
DrawScale = 1 (object volume = 16384 uu^3)
s = 8192uu (102.8m)
F = 1 uu

If you compare these results with the previous ones (the average time is almost equal), you'll discover that Unreal Developer Network is wrong. KMass is really the object mass and not its density or something like that:

KMass is the object mass.

Experiment 3 - Finding α / β

Let's write the equation using the average time we found in the above test:

Before we can determine alfa and beta, I think we have to be sure that this fraction is really constant.

Test E

KMass = 1
s = 8192uu (102.8m)
F = 2 uu

Test F

KMass = 1
s = 8192uu (102.8m)
F = 5 uu

Test G

KMass = 3
s = 8192uu (102.8m)
F = 5 uu

OK, now we're sure that the relationship between α and β is truly constant.

Experiment 4 - Finding α and β

This is the hard thing to do. My first idea was to make the following experiment:

I balanced (manually with mouse wheel) the force F so that the Bullet velocity equals zero. This is the video:
Balance.mpg

What can I deduce from this test? Well, I found that with KMass = 1 the balancing force is F = 19 uu, so:

Exactly the same constant. In fact all the experiments that contains both α and β will generate linearly dependent equations that cannot be used to solve the problem. This means that those values must be determined independently. If you find α you can calculate β, if you find β you can calculate α, the difficult thing is to find one of them :-)

However there's another thing hidden in this experiment.. I can state:

because this equation should be valid in Karma space. What's wrong? 2 things are wrong:

1. This equation suggests that α / β = 1!
2. As I set KMass = 1 and I found F = 19, how can be 1*g = 1*9.8 =19?

Curious questions indeed... OK, let's start answering to the second question.

Obviously appears that:

This is a problem as I assumed that g=9.8 for the gravity test. However 19 is really a strange value, can we confirm this value with some experiment? I thought a lot about it and remembered the PhysicsVolume, a box that you can put in Unreal Editor to change physics in its volume. So, I put one of them in the map:

wow! There's a gravity field, it contains -950. This is the default gravity. I found that with this value the Bullet behaves exactly the same, as if there was no PhysicsVolume. But what is it -950? Do you remember that 1 karma unit = 50 unreal units? What happens if I divide 950 by 50?

Let's assume that g is really 19, for now. With this value the correct scale is:

If I use the new equivalence 8192 uu = 199.3 m and I substitute this value in the equation I used so extensively in this report (let's use Test E), I discover that:

Yes, this answers the first question. With g = 19 we have a coherent world.

Is this the end of the story? Obviously not :-) How can the gravity be 19? It's too much! After several hours of search, I found only these two references:

• UnrealWiki (PhysicsVolume page) : "I was told that gravity is applied only each second frame and so this value is at least twice as high as the "real" gravity".
• Unreal Developer Network (EmittersReference): "For example if Acceleration has Z = -950 (close to the gravity on Earth), and StartVelocityRange has..."

Gravity is not applied every second frame, otherwise I would not have been able to balance the Bullet with F = 19 (applied at every frame). However it's interesting that gravity could be twice as high as the real gravity. The second reference says that the -950 value is close to the gravity on Earth. Putting together these informations I believe that:

My theory is that 950 is not divided by 100, but by 50, as stated before. The differential equations are solved numerically, you start determining forces and torques, then you calculate acceleration and angular acceleration for every body and finally integrate numerically to find actual position and orientation. I think that all the forces are divided by 2, even if I don't know why. This way the gravity force becomes:

There's another reason why I think that the forces are divided by 2, the following equation:

If only the gravity was divided by 2 why don't use simply the value -475? Furthermore, if the gravity is halved then we can write (from the balance test):

that is obviously impossible. But if we divide the forces we have:

So the real force we're exerting on the object is 19/2. OK, now we have all the elements to find α and β, however, as the g value has changed, we must recalculate the scale and the α / β constant:

[WRONG]

[WRONG]

From Test E, with the correct space (99.6m):

α / β = 2 because we have divided gravity in the first yellow equation and we have not divided the force in the last equation. In fact the force balance suggest that α / β = 1. So the constant 2 is the force division factor, that means:

and, finally:

[WRONG]

Conclusion

The correct results of this report are:

• DrawScale does not influences the mass of the object.
• KMass is the object mass

The other results are not completely correct, you can read the Jijun Wang's report to find the right scales. His report also includes torque scale.