Phys2D: Detecting juxtaposition of collided objects?

[Eli Delventhal]

Hey there –

I want to basically set a flag of whether or not a Body is floating in the air. I currently was using Arbiters to set a onGround boolean to true when there was a collision involving this object, and false otherwise. Basically, I want my Body to be able to "jump" when it is on the ground, like in real life. The problem with my current method is that any sideways collisions still allow the object to jump, which of course is not correct.

I was trying to use the position and normal of the Contacts for the Arbiter, but they are often giving me 0 vectors as results. Is there any way I could get this working, setting onGround to true only if there is a downwards collision?

Another question:
I'm going to eventually need to send out a "ray" to where the Body will be. If there is a StaticBody that is, say, 50 pixels in the direction of velocity of the Body, then a certain button should do a jump-type-thing. I'm not sure the best way to navigate around the space like that would be, aside from potentially looping through every Body and doing it on my own. Is there a smarter way to do this?

Thanks.

[Eli Delventhal]

So I figured out how to get this to work for StaticBody's because they don't rotate (which is easy), but doing this for regular rotatable Body's proves to be difficult. For a StaticBody (or a Body that happens to be oriented with 0 rotation), all I need to do is check to see if my y+height/2 is >= the StaticBody y-height/2, and my x+width/2 <= the StaticBody x-width/2, and my x-width/2 >= the StaticBody x+width/2. That's easy (I only use Box Shape's for all my collision).

But if I'm doing this via rotations, things obviously change. A "sideways" Body should be checked via its width instead of its height and vise versa, whereas a partially rotated Body will go beyond its bounds entirely as collision will probably occur on a corner. I'm sure there's some trig I can use to get this to work, which I'll try to figure out, but, like I said before, is there an easier way to do this? Some way I can use Contact points?

Thanks.

[kevglass]

Could you use the change in velocity as a result of the collision to determine which direction it happened in?

EDIT: Normals work for me btw.

Kev

Games published by our own members! Check 'em out!

[Eli Delventhal]

Hmm, well, I'm using an older version of Phys2D, I think... was there a version where the normals had issues?

I'll look into them again, but by the change in velocity you mean what gets applied from the collision, or the incoming velocity specifically? The incoming velocity works for detecting bottom or top collision, but left or right collisions can still be wrong. I'll double check the normals – if I still have 0 vectors, I'll post my code here.

Thanks Kev.

[Eli Delventhal]

Okay, here's my code with the normals.

1   2   3   4   5   6   7   8   9   10   11

ArbiterList arbiters = world.getArbiters();       for (int i = 0; i < arbiters.size(); i++)       {          Arbiter a = arbiters.get(i);          Contact[] contacts = a.getContacts();          for (int j = 0; j < contacts.length; j++)          {             if (a.getBody1() == player.getBody() || a.getBody2() == player.getBody())                System.out.println(contacts[j].getNormal());          }       }

Don't worry about the player's Body, that's just because I only want to report the normals for the player while I am testing this.

The results are:

1   2   3   4   5   6   7   8   9   10

[Vec 4.3435415E-7,1.0 (1.0)] [Vec 4.3435415E-7,1.0 (1.0)] [Vec 0.0,0.0 (0.0)] [Vec 0.0,0.0 (0.0)] [Vec 0.0,0.0 (0.0)] [Vec 0.0,0.0 (0.0)] [Vec 0.0,0.0 (0.0)] [Vec 0.0,0.0 (0.0)] [Vec 0.0,0.0 (0.0)] [Vec 0.0,0.0 (0.0)]

Repeatedly. The value of that normal (the ones that actually have a value) is correct of course (if very small values are rounded off), because it is pushing straight up in the Y direction only, but I'm curious about those zero's. Should I just have my code ignore any vectors with a length of zero? I'm more curious exactly what collision they are supposed to be dealing with... where are they coming from?

Also, those reported values are when the player is at rest on top of a StaticBody with a Box shape.


[EDIT]
I got it to work, using normals (as long as I ignored the zero ones, things seemed to work fine). Here is the resulting source code. It basically says that a hill with a 45 degree angle or less should count as the ground. I will probably change my jump application of force to reflect the angle of the ground slope, but for now this works.

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23

ArbiterList arbiters = world.getArbiters();       for (int i = 0; i < arbiters.size(); i++)       {          //TODO fix this         Arbiter a = arbiters.get(i);          Contact[] contacts = a.getContacts();          for (int j = 0; j < contacts.length; j++)          {             if (a.getBody1() == player.getBody() || a.getBody2() == player.getBody())             {                if (contacts[j].getNormal().getY() != 0 || contacts[j].getNormal().getX() != 0)                {                   if (contacts[j].getNormal().getX() == 0 || Math.abs(Math.atan(contacts[j].getNormal().getY()/contacts[j].getNormal().getX())) >= Math.PI/4)                   {                      if (a.getBody1().getPosition().getY() < a.getBody2().getPosition().getY())                         doGroundHit(a.getBody1());                      else                         doGroundHit(a.getBody2());                   }                }             }          }       }

And back to my other question...

I'm going to eventually need to send out a "ray" to where the Body will be. If there is a StaticBody that is, say, 50 pixels in the direction of velocity of the Body, then a certain button should do a jump-type-thing. I'm not sure the best way to navigate around the space like that would be, aside from potentially looping through every Body and doing it on my own. Is there a smarter way to do this?

Any insight on this?

Thanks.

[kevglass]

I think the best way would be to loop round the bodies doing collision checks, this isn't as painful as it sounds really .

However, you could shoot out an object infront of your player, see where it hits - little sphere or something.

Or you could do the checks in the visualisation model (assuming it's separated from the physics model that might be slightly quicker).

Kev

[Eli Delventhal]

Well, if I did it through the visualization model I would loop through all stationary objects (the ones I want to check), probably construct a Rectangle2D with a certain length in the proper direction, and a Rectangle2D to match the bounds of each stationary object as I check them. Then if the two Rectangles collide, I know the distance is right. Certainly a very simple implementation, I was just wondering if there was already a way to implement something similar right through Phys2D.

In terms of "looping round the bodies doing collision checks," there wouldn't actually be collision at this point, theoretically. Is there way to check for collision with a certain offset (aside from potentially using move() or something)?

Thanks again.

[kevglass]

You'd need to create a shape that represented your path I think, and collide this against geometry.

Kev

[Eli Delventhal]

You'd need to create a shape that represented your path I think, and collide this against geometry.

Kev

Okay. Will there still be collision if I haven't made the World step() since adding the new Shape?

[kevglass]

You can call:

http://www.cokeandcode.com/phys2d/source/javadoc/net/phys2d/raw/CollisionSpace.html#collide(float)

instead. That just runs collision checking.

Kev