Avoiding moving objects going into walls in bump.lua

[MrFariator]

The "slide" method does not apply any sort of push to objects. Instead, it will simply make an object glide along the given surface, by not permitting the object to move further on the X or Y axis once the collision is detected. In the case of an object hitting a corner, it'll stop it from moving on both axes.

The "bounce" method on the other hand simply flips the direction on the appropriate axis, subtracting the traveled distance, and then applying the remainder.

If you wish to enable objects to push one another in bump, you need to code it yourself, which you already have (the applyImpulse methods in your code). Remember, bump is a collision library, not a physics library. If objects begin to push one another (or phasing through one another) where they shouldn't, it's likely a problem on your side. In your specific case I suspect that once an object applies an impulse to another, it may start pushing objects it shouldn't, mostly because impulses are applied based on the objects' relative speeds to one another. Hard to comment further without a fuller example of seeing the code in action.

[pgimeno]

But the images in bump's wiki imply they do, am I missing something?

They don't push anything, they vary the final position of the object moved with the move() command, which is no longer goalX,goalY but slide.x,slide.y (or bounce.x,bounce.y, or touch.x,touch.y depending on the mode). But that object does not push other objects.

Once again, if you can provide a test case, we can look into it, but without it there's very little we can do.

Edit: Sorry, I didn't see MrFariator's reply. phpBB is a mess.

[Gunroar:Cannon()]

Nice, thnx for clearing everything up. I thought so but the images confused me.

Once again, if you can provide a test case, we can look into it, but without it there's very little we can do.

I wasn't asked before (unless you're talking about a previous post)
A test case (sweat). Not that I don't want to, I've passed that whole ideology but that might take some effort/a while for me to make a test case this time, so before I do that just three questions for yous peoples( ) to check, pls...

1.I've been wondering, if an object that doesn't move at all(like a wall) has the vx and vy variables (though they still aren't applied) could it affect another moving object bumping into them?
Since the vy/vx of the "other" could be negative and the wall's vy is 0 could it cause a condition where other.vy is smaller than wall.vy, or something like that?

2.Is it possible for a collision response in bump to make the x/y ahead of the goal and/or before the origional position, as in what the pictures look like it's doing?

3.And...

Wait...

But the images in bump's wiki imply they do, am I missing something?


and could me changing the velocity affect the movement?

... unrelated, a little, can you see the pictures in this post?(I can't but it could just be from my browser, so just making sure)

[pgimeno]

I wasn't asked before (unless you're talking about a previous post)

Yes, I was referring to another thread in which I insisted that there's nothing we can do without code we can run.

1.I've been wondering, if an object that doesn't make ar all(like a wall) has the vx and vy variables (though they still aren't applied) could it affect another moving object bumping into them?
Since the vy/vx of the "other" could be negative and the wall's vy is 0 could it cause a condition where other.vy is smaller than wall.vy, or something like that?

I have no idea what you're asking. The presence of a variable doesn't affect bump's behaviour.

2.Is it possible for a collision response in bump to make the x/y ahead of the goal and/or before the origional position, as in what the pictures look like it's doing?

If I understand what you mean correctly (i.e. if bump can in any case end up in a position that is beyond the goal) I don't think so.

3.And...

Wait...

But the images in bump's wiki imply they do, am I missing something?


and could me changing the velocity affect the movement?

... unrelated, a little, can you see the pictures in this post?(I can't but it could just be from my browser, so just making sure)

I did "Copy Image Link" and pasted in a new tab to see it. If you copy the link given in Download, it will be visible inline.

[Gunroar:Cannon()]

Thnx for answering..

1.I've been wondering, if an object that doesn't make ar all(like a wall) has the vx and vy variables (though they still aren't applied) could it affect another moving object bumping into them?
Since the vy/vx of the "other" could be negative and the wall's vy is 0 could it cause a condition where other.vy is smaller than wall.vy, or something like that?

I have no idea what you're asking. The presence of a variable doesn't affect bump's behaviour.

Sorry my fault, doesn't make ar all* should be "doesn't move at all", I edited it.That question is more based on my resolveCollision. If an immobile object is involved in the resolveCollision/implyImpulse thing(that always has a velocity of 0,0) could it mess things up for others, maybe if it's 0 velocity is bigger than a negative one (since I do't think I used math.abs), though I'm not sure.

[pgimeno]

Sorry my fault, doesn't make ar all* should be "doesn't move at all", I edited it.That question is more based on my resolveCollision. If an immobile object is incolved in the resolveCollision/implyImpulse thing(that always has a velocity of 0,0) could it mess things up for others, maybe if it's 0 velocity is bigger than a negative one (since I do't think I used math.abs), though I'm not sure.

Nothing in the code you've shown can cause object interpenetration.

[MrFariator]

Just to add a bit more to pgimeno's responses...

1.I've been wondering, if an object that doesn't move at all(like a wall) has the vx and vy variables (though they still aren't applied) could it affect another moving object bumping into them?
Since the vy/vx of the "other" could be negative and the wall's vy is 0 could it cause a condition where other.vy is smaller than wall.vy, or something like that?

Bump does not care what your object contains, except when trying to resolve collision responses (eq. checking if a response should be "touch" or "slide" in the filter functions you provide). In your case, as-is, there is nothing to suggest that bump itself would treat any objects differently from one another (except not collide with background objects, obviously). Instead any weird thing is going to depend on your code, and your code alone.

However, here's the problem: you have given us some code that shows that once two (non-background) objects collide, the one with greater velocity will apply its velocity to the other (as an "impulse"). This will affect any object that does not have the "isTile" value set (as some non-falsy value). I see no code that would slow or stop objects from moving once an impulse is applied, because objects will keep moving with their assigned velocities (as often as their respective update methods are called). As such, my hypothesis is that your objects are not phasing through walls, but rather your objects are pushing the walls. Perhaps if you try to query the objects present in the bump world, and draw their bounding boxes, you'll get some insight and better understanding of what's going on. The physical and visual presentation of your objects may have decoupled in unintended ways.

An the end of they day though, without a working test case, whatever musings I have posted may also be false guesses. So, please provide a test case if you want further help.

2.Is it possible for a collision response in bump to make the x/y ahead of the goal and/or before the origional position, as in what the pictures look like it's doing?

No, bump will return the position where the object ends up, and collisions it encountered along the way when using the move function.

However, technically, if an object is inside another, and the collision response is "slide", in that case the object may "zip" outside the other object (basically teleport out, so that the objects aren't overlapping anymore). This is just a byproduct of the math involved in bump however, and should be avoided (most often happens when you spawn an object inside another). This does not apply to your case from what I understand, but just letting you know.

3.... unrelated, a little, can you see the pictures in this post?(I can't but it could just be from my browser, so just making sure)

If I recall, Github does not like embedding images on other sites. You'd have to download and rehost those images elsewhere.

[pgimeno]

I've found a bug in Bump where two objects can end up interpenetrating each other when using "bounce" collision resolution.

Test case:

Code: Select all

love.window.setMode(200, 150)
local world = require 'bump'.newWorld()

local player = {50, 20, 20, 20}
local box1 = {20, 70, 160, 20}
local box2 = {100, 15, 60, 20}

-- Position where to send the player with world:move()
local goalX, goalY = 135, 105

-- Final position reported by bump as the result of the move
local finalX, finalY


function love.load(args)
  world:add(box1, unpack(box1))
  world:add(box2, unpack(box2))
  world:add(player, unpack(player))
  love.graphics.setLineStyle("rough")
end


local bouncefilter = function() return "bounce" end


function love.update(dt)
  -- Reset player back to initial position
  world:update(player, unpack(player))

  -- Move player towards goal using bump with bounce filter
  finalX, finalY = world:move(player, goalX, goalY, bouncefilter)
end


function love.draw()
  -- Player in green
  love.graphics.setColor(0, 1, 0)
  love.graphics.rectangle("line", unpack(player))

  -- Box 1 in pale blue
  love.graphics.setColor(0, .5, 1)
  love.graphics.rectangle("line", unpack(box1))

  -- Box 2 in lighter pale blue
  love.graphics.setColor(0, .7, 1)
  love.graphics.rectangle("line", unpack(box2))

  -- Hand calculated impact points
  local hitpos1X, hitpos1Y = 80, 50
  local hitpos2X, hitpos2Y = 95, 35

  -- Draw the trajectory 1 of 2: From player to goal line in dark green
  love.graphics.setColor(0, .5, .3)
  love.graphics.line(player[1] + player[3], player[2], goalX + player[3], goalY)

  -- Draw the trajectory 2 of 2: Actual trajectory in white
  love.graphics.setColor(1, 1, 1)
  love.graphics.line(player[1] + player[3], player[2],
     hitpos1X + player[3], hitpos1Y,
     hitpos2X + player[3], hitpos2Y,
     finalX + player[3], finalY)

  -- Position of the player on each hit in dark red
  love.graphics.setColor(.5, 0, 0)
  love.graphics.rectangle("line", hitpos1X, hitpos1Y, player[3], player[4])
  love.graphics.rectangle("line", hitpos2X, hitpos2Y, player[3], player[4])

  -- Goal x, y in dark red
  love.graphics.setColor(0, .5, 0)
  love.graphics.rectangle("line", goalX, goalY, player[3], player[4])

  -- Final x, y in bright red
  love.graphics.setColor(1, 0, 0)
  love.graphics.rectangle("line", finalX, finalY, player[3], player[4])

  -- Restore colour
  love.graphics.setColor(1, 1, 1)
end

function love.keypressed(k)
  return k == "escape" and love.event.quit()
end

Image:

bump-bounce-bug.png (754 Bytes) Viewed 2508 times

The light green box is the player. The pale blue, long boxes are obstacles. The dark green box is the goal, the position passed to world:move(). The light red box is the final position of the player after the move, as calculated by bump. Note it's inside one of the obstacles.

The white line is what I conjecture to be the actual trajectory of the top right corner of the box. The dark red boxes are the intermediate positions of the player at the contact points, according to that trajectory. The dark green line is the line from the player to the goal.

From that, my guess is that either Bump only considers two collisions, or it does not consider a second collision with the same object if it happens, causing the interpenetration. I haven't made additional tests to distinguish which of the two cases applies.

However, in the code that the OP has shown, bounce resolution is not used, therefore, assuming that slide resolution has no bugs, I don't think bump can end up with a box interpenetrating another if they were not overlapping from the start.

As for hotlinking images from GitHub, the applicable policy is probably this one: https://docs.github.com/en/github/site- ... dwidth-use

Short version: they don't mention that they oppose it explicitly, but they reserve the right to throttle or cut access in case the bandwidth usage is excessive.

[Gunroar:Cannon()]

I've found a bug in Bump where two objects can end up interpenetrating each other when using "bounce" collision resolution....

Thnx for looking into it. It seems it happens in slide too.
I made a testcase where you tap/click inside the box to spawn bouncy bullets(more like balls really those aren't what normally cause it, but because they're fast and will collide and bring up the scenario quicker I used them, and if you look in data/bullets.lua at bouncy bullet I pass slide for it(was bounce before but after p.gimeno's post I checked).
I really don't know how to fix this, though I added some more debug info, screen flashes when a bullet is about to mess up .
I even made a stressful minigame from it, how many can you get in at a time in the box (number at top), I got 62 ( ).
Note:The reason the balls tend to bounce of the walls is because once one goes past the screen it gets stuck there since it's not updated anymore, so it stays still, and others can bounce on it.

[MrFariator]

I haven't had the chance to properly look through your code, but on line 262 in data/bullets.lua, is this right?

Code: Select all

function bullets.BouncyBullet.checkCollisiuon(item, other) -- "Collisiuon" instead of "Collision"
 -- ...
end

As far as I can tell, because of that typo you're using the default filter (as defined in entities/bullet.lua, in Bullet.checkCollision), so you're still using whatever the response collisionType for the given item resolves to, instead of hardcoding "slide"?