LÖVE

Hi all!

I am looking for a collision library that also take rotation in to account. For now I only need rectangle shape.
Yes I can see there is lot of discussions on the forum about this that usually end with recommending the HardonCollider library:
https://github.com/vrld/HC

However, my problem with this library is that there is a conflict when I want to rotate and move the collider at the same time.
The problem is that the rotation command uses the center point to rotate the collider and the top left corner to position it. While the move command uses the center point to position the collider and it is create a conflict between the two commands when used same time. The move command essentially override the rotate command positioning.
The problem with this is that my sprites are rotating around the origin point and position of origin can be anywhere I want to. I can make the collider rotate or move with my sprites but I can not make it rotate and move same time because the library handle this 2 different ways.

Setting the position of the collider box directly using obj._pos.x and obj._pos.y instead of using the move command is not working but I have no idea why.

The library is not documented and it uses abstraction on top of abstraction on top of abstraction, I can't figure out how it works and not even Visual Studio Code is able to find definitions of the methods. Why on earth someone didn't think of moving and rotating a collider at the same time using the same position is beyond me.

So apart from HardonCollider is there any other collision library I can try?

Or would anyone have any idea how to make :moveTo() and :setRotation() work together in HardonCollider?
To be honest I don't even understand how :setRotation() works because the method accept x,y as arguments and pass it on to an other rotate method and it is offset the position of rotation
But if I go to the definition of the rotate command, it doesn't do anything with position, it doesn't even accept position as argument:
There has to be an other implementation but I can't find it where it is.

And the moveTo() method for whatever reason subtract the center position from the actual position:
I have no idea why is it need to take in to account the center position at all but if I remove it, it doesn't work and VS code can't find the definition of :move()

The only thing I can find is this:
But this is not the one the rectangle is using.

I simply can't find the move() and rotate() method used by the rectangle.
I spent the last 2 days trying to figure this out, but I can't.

I would appreciate any help.
Thank you.

tl;dr

If you mean are there any collision libraries that support rotation, AFAIK there's windfield and the better and updated version of it breezefield.

windfield: https://github.com/a327ex/windfield
breezefield: https://github.com/HDictus/breezefield

Yes, I am basically asking for collision libraries that also support rotation (and easy to use), or help with the HadronCollider library.

Windfield and Breezefield looks interesting, I have a look. Thank you.

I would recommend using love.physics as you might hit other obstacles using outdated (windfield, HardonCollider) or even updated libraries (breezfield).

https://love2d.org/wiki/Contact

https://love2d.org/wiki/World:setCallbacks

Thank you I have considered using love.physics but I don't need a full physics engine and I was hoping there is some lightweight library that allow me to "simply" just create a rectangle collider, set x and y position, scale, rotation and check collision so I can super easily integrate it in to my system.

If I can get this working I don't expect any obstacles unless Love2D change the way its draw method and math library works.

But seems like these libs are rotating around the center point only while my sprite is rotating around the origin point and by default the origin point is in the top left corner. HadronCollider, Windfield and Bereezefield doesn't seems to like this setup.

What battles me, HadronCollider have considered this scenario and allow me to offset the rotation position but why rotation and movement at the same time was not considered I have no idea. It is such an obvious use case to me. It would be perfect.

Windfield does not seems to allow me to apply offset when rotating, it is rotate around center point only.

I'll look in to love.physics but if I hit the same obstacle, I need to consider to rotate my sprites around the center point only, which I don't really want to do.

ddabrahim wrote: ↑Mon Aug 28, 2023 9:30 am OP post

I'm assuming your shape is a polygonshape in HC due to you talking about rectangles.

I looked at the code of HC and i'm assuming the move function you were looking for is in fact ConvexPolygonShape:move on line 327 of shapes.lua

Also, ConvexPolygonShape:rotate takes in two extra parameters cx and cy that define the center of rotation, that default to the centroid of the shape in question if you don't pass values yourself.

So you can have any "origin point" you want to rotate around, and yes, this will inevitably change the position of the collider shape; if you only rotate around the centroid (center of the rectangles in your use case), the center positions won't change, but the "topleft" will, since you applied rotation to them. If you rotate around any other point, even the center points will change location, for obvious reasons.

That said, according to the docs, "Most shapes will be centered on the point (x,y)." To me, that says that the positioning is based on the centroid of the shapes, not their topleft that you expect for some reason.

I also don't get why you're trying to use moveTo instead of move; the latter would probably work better considering that cares not about your shape's current position, it only applies an offset.

moveTo subtracts the center because as i said, positioning is based on that, so if you have a rectangle centered on (1,1) with a size of (2,2), that you want to move to (10,10), it will calculate that it needs to move the shape by (10-1,10-1) => (9,9) which is correct.

Thanks a lot. I'll look in to ConvexPolygonShapes then.

That said, according to the docs, "Most shapes will be centered on the point (x,y)." To me, that says that the positioning is based on the centroid of the shapes, not their topleft that you expect for some reason.

When I create the rectangle the constructor hc.rectangle() position the top left corner of the collider on x and y.
Then :setRotation() center the position on x,y but I can apply offset.
However, if I use moveTo() it is center the collider on x and y and override the offset set in setRotation() and this is my problem, I don't want it to be centered because the x and y position of my sprite is relative to the position of origin point. I need the offset in setRotation() but moveTo seemingly override it.

I have an other look at ConvexPolygonShape and see if I can figure this out.

ddabrahim wrote: ↑Mon Aug 28, 2023 2:30 pm Thanks a lot. I'll look in to ConvexPolygonShapes then.

That said, according to the docs, "Most shapes will be centered on the point (x,y)." To me, that says that the positioning is based on the centroid of the shapes, not their topleft that you expect for some reason.

When I create the rectangle the constructor hc.rectangle() position the top left corner of the collider on x and y.
Then :setRotation() center the position on x,y but I can apply offset.
However, if I use moveTo() it is center the collider on x and y and override the offset set in setRotation() and this is my problem, I don't want it to be centered because the x and y position of my sprite is relative to the position of origin point. I need the offset in setRotation() but moveTo seemingly override it.

I have an other look at ConvexPolygonShape and see if I can figure this out.

Apparently HC gives you a rectangle constructor as a syntax-sugar like thing; behind the scenes, that's a ConverPolygonShape already.
https://hc.readthedocs.io/en/latest/MainModule.html

And it does have a notice saying that the top-left x,y parameters are just for show, those get converted to center coordinates internally.

it does have a notice saying that the top-left x,y parameters are just for show, those get converted to center coordinates internally.

Yes this is the problem. Apparently all collision libs using the center point including love.physics but when rotating it does not suite the way I rotate my sprites. I see if I can hack one of the libs to make it fit. Thanks a lot.

ddabrahim wrote: ↑Tue Aug 29, 2023 8:20 am

it does have a notice saying that the top-left x,y parameters are just for show, those get converted to center coordinates internally.

Yes this is the problem. Apparently all collision libs using the center point including love.physics but when rotating it does not suite the way I rotate my sprites. I see if I can hack one of the libs to make it fit. Thanks a lot.

Wouldn't it be easier to switch to using center point for your stuff rather than the other way round? Just saying.