Resolving collisions with HardonCollider

Questions about the LÖVE API, installing LÖVE and other support related questions go here.
Forum rules
Before you make a thread asking for help, read this.
User avatar
Reef
Prole
Posts: 33
Joined: Sun Mar 04, 2012 10:19 pm

Resolving collisions with HardonCollider

Post 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
Attachments
snowblower.love
(24.42 KiB) Downloaded 182 times
User avatar
Reef
Prole
Posts: 33
Joined: Sun Mar 04, 2012 10:19 pm

Re: Resolving collisions with HardonCollider

Post by Reef »

I'm going to try bumping this one time so see if anyone can help or has any advice.
User avatar
Positive07
Party member
Posts: 1014
Joined: Sun Aug 12, 2012 4:34 pm
Location: Argentina

Re: Resolving collisions with HardonCollider

Post 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
for i, person in ipairs(everybody) do
[tab]if not person.obey then person:setObey(true) end
end
love.system.openURL(github.com/pablomayobre)
User avatar
Reef
Prole
Posts: 33
Joined: Sun Mar 04, 2012 10:19 pm

Re: Resolving collisions with HardonCollider

Post 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.
Attachments
stutter.gif
stutter.gif (56.6 KiB) Viewed 6703 times
Zeliarden
Party member
Posts: 139
Joined: Tue Feb 28, 2012 4:40 pm

Re: Resolving collisions with HardonCollider

Post by Zeliarden »

Sorry for the short answer (its late)
Try this

Code: Select all

shape_b:move(-mtv_x, -mtv_y)
User avatar
Reef
Prole
Posts: 33
Joined: Sun Mar 04, 2012 10:19 pm

Re: Resolving collisions with HardonCollider

Post 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!
User avatar
vrld
Party member
Posts: 917
Joined: Sun Apr 04, 2010 9:14 pm
Location: Germany
Contact:

Re: Resolving collisions with HardonCollider

Post 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
I have come here to chew bubblegum and kick ass... and I'm all out of bubblegum.

hump | HC | SUIT | moonshine
User avatar
Reef
Prole
Posts: 33
Joined: Sun Mar 04, 2012 10:19 pm

Re: Resolving collisions with HardonCollider

Post 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.
User avatar
kikito
Inner party member
Posts: 3153
Joined: Sat Oct 03, 2009 5:22 pm
Location: Madrid, Spain
Contact:

Re: Resolving collisions with HardonCollider

Post 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!
When I write def I mean function.
davisdude
Party member
Posts: 1154
Joined: Sun Apr 28, 2013 3:29 am
Location: North Carolina

Re: Resolving collisions with HardonCollider

Post 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.
GitHub | MLib - Math and shape intersections library | Walt - Animation library | Brady - Camera library with parallax scrolling | Vim-love-docs - Help files and syntax coloring for Vim
Post Reply

Who is online

Users browsing this forum: Bing [Bot] and 223 guests