[SOLVED] love.physics collision issues

[Wscb]

Started trying to use love.physics yesterday and I've run into some issues...

1) I made a dynamic body with a rectangle shape, that can have force applied to it via keyboard, and a bunch of static rectangles as the ground. That bunch of rectangles cause a problem. They're in a row but when the movable character is sliding horizontally on them it seems to collide with the edge of the next one, freezing completely because I've fixed its rotation. When I don't fix it, it rotates and gets blown up suddenly, as if it hit a very small obstacle.

Visual representation: (dots are there because space gets auto-deleted, they don't mean anything)

....[1]......
[][][2][3][][]

If the blocks below block 1 are the ground and block 1 is a rectangle that's trying to slide on them towards the right, it'll freeze at a position similar to this. Exactly before moving on the next ground block.

(If we fail to communicate because of my bad visual representation I guess I'll just post a picture )

I think I know what's happening. Correct me if I'm wrong: For some reason during collision detection block 3 is calculated as being slightly above block 2 (even though they have exactly the same position), or something similar. This seems to be the problem, but I'm not sure how to deal with it... Can anyone help? Is there a way to make collision resolution less sensitive? Seems like a problem that would be common but I failed at googling for a solution because I didn't know how to call it or describe it, as this post proves.

Edit: I've sort-of solved this one now, by turning the player rectangle into an octagon that's almost a rectangle. You can tell what I mean by that if you look at the function that calculates its vertices:

Code: Select all

function almostRectangle(width, height, slope)
  local wdiv2 = width*0.5
  local hdiv2 = height*0.5
  if not slope then slope = 0.1 end
  -- return vertices
  return {
    -wdiv2, -hdiv2, -- upper left
    0, -hdiv2 - slope, -- upper middle
    wdiv2, -hdiv2, -- upper right
    -wdiv2 -slope, 0, -- center left
    wdiv2 +slope, 0, -- center right
    -wdiv2, hdiv2, -- down left
    0, hdiv2 + slope, -- down middle
    wdiv2, hdiv2 -- down right
  }
end

It also gets "fixed" if I do this to the ground blocks instead, or both of them. I only made the player into an octagon because since it has more vertexes I'm assuming it'll be more costly to calculate, so I'm keeping the octagons to a minimum. It does get a bit jerky at times and it's a very crude solution, so it's not really fixed. Does anyone have anything more elegant in mind?

2) Instead of calling Body:destroy (btw, should I use Body:setActive instead? This issue persists if I do anyway.) I made a table for instances to be destroyed, then I iterate over it and destroy them one by one so they all get destroyed together at a set place in the code. Is this a good idea, or is it pointless? Anyway, when I do this, some of them don't get destroyed (or deactivated) even though I know the instance of the body was on the table and it does get iterated over. I know because the other things I do to it (like stop it from getting drawn) along the destruction of its body do get done. Any ideas why?

I'm using love2d version 10.2 because love.graphics.print doesn't work for me, by the way.

[Wscb]

Sorry for bumping my own thread, but I found helpful stuff for my problems, so if anyone has the same problems here you go:

1) http://www.iforce2d.net/b2dtut/ghost-vertices
This link has both the problem I described and the solution. As you can see the solution I described in my edit is also presented in the link and referred to as a "hatchet job" . Unfortunately I can't find anything about ghost vertices in love.physics but edge shapes work well enough that I haven't run into any problems with them.

2) http://www.iforce2d.net/b2dtut/removing-bodies
I don't know what I did wrong exactly but I should try it again because according to the link not only should bodies be destroyed at a set place in code, they should also be created at a set place in code.

[ivan]

I've seen a tutorial where somebody used hexagons for the blocks, similarly to what you did with your player shape.
But yea this is a hacky way to do it.
Edge shapes are certainly the way to go as pointed out by Wscb. Plus, you can make them one-sided if you want.

[Wscb]

Guess I was wrong about love.physics having no ghost vertices. I think these two are functions to set the ghost vertices. setPreviousVertex probably sets the v0 one and setNextVertex the v3.

Oh, I also found my mistake in the second issue. I forgot to check if the object to be destroyed had already been added to the table of objects to be destroyed.

Plus, you can make them one-sided if you want.

Like jump through floors, right? I can see how you could do this in the preSolve callback by checking a few things and enabling or disabling the contact object. Is that what you mean? Or is there an easier way?

Anyway, I'll mark the topic as solved.

[ivan]

To be honest, I've never had to use ghost vertices, so you probably won't need to either.
Yes, jump-through platforms are fairly easy, all you have to do is check the player's vertical velocity.
Positive velocity means that the player is jumping and should NOT collide with the platform.
You could make that check slightly more sophisticated, and test if the velocity is beyond a certain threshold (basically avoiding cases where the player is jumping halfway through the platform).