Page 1 of 2

Resolving collisions with HardonCollider

Posted: Mon May 25, 2015 7:21 pm
by Reef
I've been experimenting with HardonCollider for collision detection recently and while I understand the basics thanks to the tutorial and reading the documentation, I'm running into some peculiarities that I can't seem to understand.

In the attached .love you will see my current problem. My on_collide collision detection function works fine for certain shapes (the walls of the arena) but not for others (the circle, called enemy). I've found out that it works inconsistently. Collisions are handled fine as long as the player is shape_a, but the player will get stuck and jitter if it is shape_b. Strangely, this only seems to happen when colliding with the enemy, not the walls, and happens inconsistently when starting the program.

Is this something I just need to account for in my code? I've attempted to do this but it isn't working. I was also experiencing tunneling through the walls previously, but it seems to have fixed itself and I can't get that to happen any more. What am I missing? Are there any more clear examples I can look at?

EDIT: Here's the collision function:

Code: Select all

local function on_collide(dt, shape_a, shape_b, mtv_x, mtv_y) -- mtv is 'minimum translation vector' needed to resolve the collision
	local other

	if shape_a == Game.player.shape then
		other = shape_b
		shape_a:move(mtv_x, mtv_y)
		print('AAAAAAAAAAAAAAA')
	elseif shape_b == Game.player.shape then
		other = shape_a
		shape_b:move(mtv_x, mtv_y)
		print('BBBBBBBBBB')
	else
		return
	end

	if other == Game.enemy then
		print('enemy')
	end

	print('bump')
	
	--Game.player.shape:move(mtv_x, mtv_y)
	Game.player.speed = 0	
end

Re: Resolving collisions with HardonCollider

Posted: Sun May 31, 2015 8:41 pm
by Reef
I'm going to try bumping this one time so see if anyone can help or has any advice.

Re: Resolving collisions with HardonCollider

Posted: Mon Jun 01, 2015 6:29 pm
by Positive07
This works totally fine. Cant replicate the issue, sorry. I can crash with the enemy and it will collide so I dont really get this issue

Re: Resolving collisions with HardonCollider

Posted: Mon Jun 01, 2015 8:34 pm
by Reef
Image

This is what happens. Strangely it only happens sometimes. Not when the collision happens, but when the program is run. If it doesn't happen I can restart the program a couple times to replicate it. If I watch the print output it happens when the player is collision shape B.

Re: Resolving collisions with HardonCollider

Posted: Mon Jun 01, 2015 10:37 pm
by Zeliarden
Sorry for the short answer (its late)
Try this

Code: Select all

shape_b:move(-mtv_x, -mtv_y)

Re: Resolving collisions with HardonCollider

Posted: Wed Jun 03, 2015 5:46 am
by Reef
Zeliarden wrote:Sorry for the short answer (its late)
Try this

Code: Select all

shape_b:move(-mtv_x, -mtv_y)
Thank you for the help! I tried this and it seems to work although I'm not sure why, despite looking through the HC source code. Does the minimum translation vector assume shape_a is being moved? Can anyone explain this to me? I also don't understand why if the player is shape_a on one collision with the enemy they always seem to be shape_a and vice versa. Sorry for so many questions!

Re: Resolving collisions with HardonCollider

Posted: Wed Jun 03, 2015 6:43 am
by vrld
Reef wrote:Does the minimum translation vector assume shape_a is being moved?
Exactly. This is somewhat hidden in the documentation:
shape_one and shape_two are the colliding shapes and dx and dy define the separating vector, i.e. the direction and magnitude shape_one has to be moved so that the collision will be resolved.
I am working on a sort of redesign of the API which hopefully will make things easier to understand (and it is also less code on my side - less things that can go wrong):

Code: Select all

HC = require 'hardoncollider'
 
function love.load()
    HC.resetHash(100) -- optional
    circle = HC.circle(400,300,50)
    rect = HC.rectangle(200,100,100,30)
end
 
function love.draw()
    HC.hash():draw()
    circle:draw('fill')
    rect:draw('fill')
end
 
t = 0
function love.update(dt)
    t = t + dt
    circle:moveTo(love.mouse.getPosition())
    rect:move(100*math.sin(t)*dt,0)
    rect:rotate(dt/5)

    -- no more callbacks. no more active/passive/ghost shapes. no more groups.
    -- you decide how to handle your shapes
    for shape, mtv in pairs(HC.collisions(circle)) do
        -- the translation vector always points in the direction circle has to 
        -- to move to resolve the collision
        shape:move(-mtv.x/3, -mtv.y/3)
        circle:move(unpack(mtv))
    end
end

Re: Resolving collisions with HardonCollider

Posted: Fri Jun 05, 2015 2:40 am
by Reef
Ah! I thought I must have missed something. Thanks for the response! I think I understand a bit better now, hopefully I can work through the rest of my questions.
Not sure I can judge whether your new API will be easier to understand from your snippet, but it's certainly different.

Re: Resolving collisions with HardonCollider

Posted: Fri Jun 05, 2015 10:41 am
by kikito
vrld wrote:I am working on a sort of redesign of the API which hopefully will make things easier to understand (and it is also less code on my side - less things that can go wrong):
{...}
If I'm understanding this correctly, I did something similar in the transition from bump 1.x to 2.x . This change has two big consequences.

First one is that users will be responsible of deciding which collisions are resolved first, instead of "letting the engine decide". I am totally fine with that, I think it's the correct thing to do in most games (not in simulations).

A maybe more worrisome consequence is that you lose the capacity of detecting collisions between two fast-moving objects - they can "tunnel" through each other, if both of them are moving sufficiently fast and/or are sufficiently small. It is a sacrifice I was willing to make: simpler code and API in exchange for not handling an obscure an infrequent edge case.

People used to box2d will have to do a mental jump, and some will not like the change. I think it is worth it. Good luck!

Re: Resolving collisions with HardonCollider

Posted: Fri Jun 05, 2015 4:43 pm
by davisdude
kikito wrote:A maybe more worrisome consequence is that you lose the capacity of detecting collisions between two fast-moving objects - they can "tunnel" through each other, if both of them are moving sufficiently fast and/or are sufficiently small. It is a sacrifice I was willing to make: simpler code and API in exchange for not handling an obscure an infrequent edge case.
To solve this, couldn't you just make a line segment from the current point to the predicted next point for each object, and check if those segments intersect? If I understand correctly, that would solve this problem.