Spherical Gravity Issue.

Game Engine Game Engine Support and Discussion
1

Hi,
I recently tried to attempt to make gravity like the earth’s gravity, how its always being pulled towards a point.

I was pretty successful at this, the method I used was to find the angle of elevation from the centre of gravity to the player on all 3 axis’ then apply the gravity accordingly so that the bigger angle got more gravity and the smaller ones got less gravity but making sure that the combined gravity always equalled 9.8. I also chucked in a quick method to find out which way the gravity should be applied.

My issue is that when the player is near the poles of my “earth” (1 or 2 blender units to it) it gets sucked towards them.

I’m not sure why this happens, perhaps if someone can look over my .blend or code they could help me? I’ve put a grid over the sphere so the poles can be found easier (the poles are the top and bottom parts, where all the lines converge). Arrow keys to move the cube.
spherical_gravity.blend - 1033kb

2

Well, I have no idea. Whenever the second angle comes close to 90 degrees, the sucking effect happens. The y_rise thingy.

The reason I have no idea is because I never use angles in my spherical gravity scipts. I always use simple vectors.

###Code by Hamish Pain. Use as you wish, no credit required - I don't own the ideas or knowledge in any way###
###This may not work, haven't tried this specific one out yet###

vec =\ 
[playerPos[0]-objectPos[0],\
playerPos[1]-objectPos[1],\
playerPos[2]-objectPos[2],\
]

def normaliseVector(vec):
    dist = math.sqrt\
    (\
    vec[0]*vec[0]+\
    vec[1]*vec[1]+\
    vec[2]*vec[2]+\
    )
    return (vec[0]/dist,vec[1]/dist,vec[2]/dist)

def mult(numbers, size):
    list = []
    for i in numbers:
        list += [i*size]

motion.setLinearVelocity(mult(normaliseVector(vec)),0)

Or that’s the idea. While there may be some specific reason you’re using angles and GameLogic.setGravity(), this thing generally works for me. I’m sure I’m not the first person to think of it nor the last but I love the idea.

3

Ah thank you, its not just the poles, its where ever any angle of elevation is around 90 degrees, but why would it be doing that?

The reason is only spotted it at the poles is because I always start it off there.

4

Not any angle. There is no sucking effect when x_rise is close to 90 and the other two approaching 0.

I think the multiplier is off. The sucking effect happens much more powerfully if the multiplier is set to 1.

I am too tired to think right now, so my observations may be off. Also, check out my previous post, I edited it to attempt to include how else it could be done.

5

I didn’t actually check to see if the sucking happened when x_rise was at 90 only for y_rise and just assumed it was the same story for x_rise.

The multiplier is there so gravity will always be 9.8, if you print x_grav + y_grav + z_grav you should always get 9.8.

I think it may be something to do with my pivot points and the x_rise y_rise and z_rise, they may not be right when the player is on the equator of the sphere, or maybe they are right there and wrong on the equator. I will check tomorrow.

I don’t really understand the your way, it looks like it works better then mine aswel. I’m planning on changing GameLogic.setGravity() to a motion actuator because it won’t work with other objects in the scene.

6

The way that I’m suggesting is a common way to get the vector between objects, that is, the direction and the distance in x,y,z coordinates.

If an object is ten meters from a point and another object is four meters from it, 10-4 = 6. The first is six units from the second in a positive direction. If this is done for all the axis, you get the direction and the distance from the second object to the first…

From this you make all directions added equal one - this means that with every single multiple, you move exactly one unit.

Then do with it what you want. You have a vector towards the object, you could multiply it by 9.8 and place it in your motion, giving 9.8 movement ‘downwards’

7

Ok, well I never knew what vectors were so I googled them and found out its a quantity with size and direction.

I understand it now, I had to change it a bit.

I put it in and there is no suction, but its a bit jittery because its always trying to push downwards. Do you know how I can lower how fast the script is processed?

8 
if timer > 0.01:
    ##CODE
    timer = 0
9

I guess that would work, I just though there was a way to make the sensor go off every so logic ticks

10

There is, but that is inelegant. A timer allows you to set it to run the same no matter what the logic tic. (Well, sort of…)

If needed, it can be done with logic bricks:
Always - > and - > prop(+1)
prop = x - > python script

where x is the number of logic ticks.

11

Ok, thanks for your help, I just have one last question.
How does it find the direction?

12

Direction is the same as vector. Divide the vector - the x,y,z values - by the total distance

##Note, not code =P###
dist = sqrt(x^2+y^2+z^2)
vect = [x/dist,y/dist,z/dist]

That gives you a direction in steps of one. I’m not entirely sure if that is what you are asking, so I hope this helps.