Sorry your browser is not supported!

I’m trying to wrap my head around the scaleFactor part of Create3DPhysicsWorld( scaleFactor )

The documentation gives me this:



In other words, if I create a game where every character is 0.5 meter in height, then it will alter the laws of physics and make everything fall super fast.

However, we live in a cold, uncaring universe. The laws of physics does not care about your height. At all. So this “character” the documentation talk about must represents something other than an ordinary fellow. Here I got sidetracked trying to figure out the height of Jesus Christ. But whatever his height, there doesn't seem to be anyone who claim that this number somehow influences the forces of nature.

Then, there’s those AppGameKit units. Appearently, a “character”, whatever it is, have a height of 72 “AGK units”, whatever that is. The number 72 happens to be the same as the traditional DPI of a monitor, but this is hopefully a coincidence? I'm not sure of anything at this stage.

From a practical perspective, I need to figure out the right scaleFactor from the start. If I end up needing to change the scale factor later, it will screw up all the physic calculations.
A lower scale factor makes the world move at a slower pace, like if every object is a giant building.
A higher scale factor makes the world move faster, like if every object is a small toy ball.
Also, a lower scale factor will make the physic able to deal with smaller objects without misbehaving. (or is it a higher scale factor?)

I can't help but feel that whatever this scaleFactor is, it is just fundamentally wacky. It seems weird that in order to make a 1x1 cm dice land on a table without falling through it, I have to alter the size of a the "character" in the simulation to the size of towering giants, and as a weird side effect, slow down the entire simulation.

Also, I'm doing virtual reality, so I can't just cheat and make the dice 1x1 meter. Because, then the dice will be 1x1 meter.

72 / 12 = 6
72 Inches... 12 Inches Per Foot... thus 6 Foot or 1.83 (1.8288) Meters
Standard Desktop DPI is actually 96 for Modern Displays.

All this is saying is that the AppGameKit Physic System uses Imperial Measurements., while it's more common to use Metric in Development Applications or Science; so you have to be sure to convert all of your Units from Metric to Imperial to ensure that acceleration is being calculated correctly.
As while Gravity is 9.81m/s it's 32.185ft/s .. which does make a big difference in regards to calculations.
Of course the Help could likely be more clear about this, as I'd argue there are various elements of the Help Files that don't really do a particularly good job of properly explaining clearly enough WHY something is designed to work the way it is.

An excellent example is the Mesh Memblock, which hasn't really changed from DBC or DBP... but the AppGameKit Help is a Wall-of-Text that's not just difficult to follow due to Formatting but isn't exactly concise; where-as the older versions of said same Help were much more clear about how they were structured.

The bottom line is that in order for physics to work at it's default value your models have to be HUGE. In my kart physics example the arena was so large it would break the limits of my 3D proggy.
So if i changed the model i would have to scale it down by 10, make my changes and then scale it up by 10 to export it.
If you download the source you will can see where i've made a scale factor and used that to scale all my physics forces. (I'm not sure i scaled absolutely EVERY physics value but you will get the idea)

Thanks, I gotten a bit further. Still crazy confused about the whole thing, though. Throwing Imperial into the mix did not help, but I guess I must go there if I want to the bottom of things.

AppGameKit Official Tutorial Guide Vol 2.pdf:
“This figure [scaleFactor] represents how many 3D world units equals one metre.”

Is the quote correct? That is, that a scaleFactor of 40.0 means that there are 40.0 AppGameKit units per meter?

If so, then I can just set scaleValue to however many AppGameKit units I wish per meter, right?

The documentation says:
"At the default scale factor of 40 the smallest dimension that the solver can handle is about 3.5 AppGameKit unit"

Can anyone figure out where this number comes from? Or is it just an estimate found through trial and error?

72 units is the height of the game guru character and is the accepted default size.



This is wrong. The author who wrote the book never researched how the bullet physics engine works.

basicFanatic
This was already explained to you in your other thread.
https://forum.thegamecreators.com/thread/221249

So, okay, have I gotten this right?

Bullets calculation are in meters. The scaleFactor determines how much 1 meter in your game is scaled for the bullet calculation meters.

• The bullet physics will work with a max size of 10.0 meters (ten meters, size of a truck)
• The bullet physics will work with a min size of 0.05 meters ( 5 centimeters, size of a fist)

So if your objects are somewhere between 5 cm and 10 meters in size, you can safely stick to the vanilla scaleFactor of 1.0, where 1 meter in your game translates directly to 1 meter in the physic calculation.

However, if you need to create a soldier which is 72.0 meters tall then he will be outside the max scale of 10.0, so you need to set the scaleFactor to 40.0 to make the bullets behave.

Uh ... is nobody gonna correct me? Does this mean that what I said is kinda like things are?

I guess, if you have a big soldier the question would be, what you want to get from that.

I guess, you can't have a 72 m giant and a tiny ant at the same moment. But what if, your 72 m giant has a fist out of a truck? like these Power Ranger Megazord's

Also your 72 m giant would do all things in a lower "speed", and tiny animals are faster. Why? The bigger things often are in a distance, so they seem slower and also the circulatory or an elefant is not the same as of a mouse.

So from what I understand is, there are nearly no reasons to change the scale factor. Because your 72 m hight giant also belongs to the default scale factor and physics. But it could be less accurate, if you have objects smaller 5 cm or bigger 10 m. So in the real world most objects are not as tall or combined out of others.
If you would have maybe planets that should collide or so, that could be another thing. But mostly you wouldn't have plantes colliding at the same time an ant is doing something on this planet.

I agree no need to scale the physics
but with blinks kart physics the objects were 150 times their normal size
and this created issues with the bullet physics with the cars the fix was
scaling the physics to match the size of the objects or scale the objects
to normal sizes and use the physics normally

just so you know how much the objects were scaled, in blender they failed
to even show. So its nowonder they caused issues


There is more about this on blinks kart physics thread

Hmm, I think Stab (the original author of the physics implementation) described it differently.

As Raven said:


I too thought had to do with conversion metric vs imperial system as the calculations were too coincidental otherwise.
The original Bullet library was developed by a Dutch guy (so metric oriented) working for an American company(imperial system).
Naturally I thought had something to do with it given the math results being so coincidental, however Stab said it's *not* so.

And I'd like to think that someone who was able to implement this stuff knows what he's talking about. As far as I recall, he said had to with realistic, real world fall speed vs size. If not using the proper scale, tunneling will appear more often.


Also I do not think size matters.. in 3D that is.
The speed is determined by the amount of polygons/vertices: if a large cube is scaled up it shouldn't matter if still has same amount of poly's or vertices.

Now if you have a large cube and want light/shadowing to work nicely, it *does* matter if you have less segments, for otherwise will look ugly. So yes *that* will slow down things.


For me too goes: If I'm wrong please correct me..

[EDIT]
@fubarpk

Then Blender cannot be our weapon of choice?
Most 3D creation tools allow for setting the scale of the world measurements. If Blender does not then that completely s*cks.
[EDIT2]
Found this: Docs » Game Engine » Physics » World Physics



@AGK dev team: this is the millionth time this comes up. AppGameKit screams for a decent, once and for all, allround, complete physics system with proper docs.

Rick, it's a while since I played around with it, but here's my notes for exporting from Blender:

@basicFanatic
Thnx, this might prove to be very useful.

As far as Bullet Physics itself goes... strictly speaking it can be implemented as either Imperial or Metric.
It's actually fairly standard to use Imperial, as most Game Engines (ID Tech, Frostbite, Unreal) typically utilise Imperial., as this is their Default Scale Factor.

That is to say, you work with the Unit Systems you're used to... then leave the issue of conversion between to the Engine (Physics) Programmers to deal with.
Now., personally I've not used the Physics in AppGameKit rather I was going off of what you posted from the Help; and the way it was worded seemed to suggest it was using Imperial Measurements as the Default Scale.

From what others have suggested., this actually isn't the case and instead what the Help is more likely referring to is the fact that people are more familiar with creating Models for Unreal, Source, Quake, etc. where you do not only set Z as the Up Axis but also Default to Inches (with 72 Units / Inches = 6ft; or the Standard Height of a Character).

As I understand it, this isn't the case for AGK.
Instead it's Default Units are (just like DBP) 1.0 Unit = 1.0 Centimetre., and when you also take into account it also uses Y as the Up Axis... this means that Applications such-as Maya already utilise the Default Scale and Orientation.

Where-as Applications such-as Max (Inches Default, Z Up) and Blender (Meters Default, Z Up) aren't actually going to output correctly.
What does this have to do with the "ScaleFactor" … well basically again, as I understand it; this is essentially how many of your Model Units = 1 Meter.

So for example... if I were to export from Maya., which uses Centimetres (by default) then I'm going to want to set this to 100.
As well 100 CM = 1 METRE

But of course if your Modelling Application uses a different Scale., then you're going to want to manually set this; assuming you haven't accounted for this when you export (to FBX or such).
Now will this make a difference in terms of the Physics Calculations?

Strictly speaking no... but look at it like this., let's say your Model is already in Metre and it's using the Default Scale Factor of 100; well now instead of being say 1.8M Tall., your Character is now 180M Tall. That will make a difference in regards to how Physics will behave with it., because if it's falling at 9.81M/s (which btw, you DO NOT want to use this for Game Physics and instead you typically want to use Half to a Third of that for "Natural" Physics that Players can react to) then at 1.8M it takes ~183ms to Travel from Head Height to the Ground (again this is why you want Gravity to actually be Lower) where-as if it's 180M then it would take 18.35s; which is … well that's insanely slow.

As I said you want to use between 50 - 33% the Intended Gravity to allow for Input Latency and Player Perception.
Game Theory often covers how Game Gravity is different from Real Gravity., but I'm not sure if they've ever really dived into WHY we tend to use Lower Gravity.

If it's a Racing Game, you tend to be "Fine" with Real Gravity for Realism Purposes; but everything else., you want it to be Lower.
There's a lot more elements than just Scale involved still., this should be a good enough explanation for now.

Maybe I misunderstand you, but I always assumed that the AppGameKit units are in meters. At least, when I create a 1x1x1 box and view it in VR, it is 1 meter at each side. That would make more sense too, since meter is the "raw" unit, while centimeter basically means one hundred of a meter.

The documentation seems intentionally vague, talking about "size", without mentioning if that size is in centimeters or kilometers. I feel there is some tradition for weird proportions in game design, where a car might be 5 "units", or a soldier might be 72 meter tall. I don't quite grasp it.

In Blitz3d 1 unit stood for 1 meter. I thought AppGameKit was similar in that respect, except when it would come to physics.. I once was told it was al subjective, can be interpreted any way you like. You just choose one scale and go with that, however I'm not so sure if that works properly when designing your characters, buildings etc in a 3D package, for when exports you end up with either too large or too small models which you will have to scale in the language of choice with all the drawbacks that may give.

Would be good to have this all cleared up indeed.