Creating and removing shapes from HardOnCollider on the fly

[molul]

This topic was badly explained, so I'm editing it to make a simpler question: is it safe creating and removing shapes from HardOnCollider while you're playing?

I'm planning on removing my current collision detection system and use HardOnCollider instead. I think the best way is to make walls, ceilings and grounds (diagonal grounds included) shapes from the collision layers I've created in Tiledmap, which only have the neccessary tiles, independent from the map tiles.

My main doubt is if in HardOnCollider is or not safe to create and remove the shapes as they approach or leave the viewport. In the few examples I've seen, the shapes are created in love.load(), so I wonder if doing it in love.update() would mean losing a lot of performance.

Any advice is appreciated.

[Golan2781]

You don't have to manually deactivate shapes outside the active area, HOC already very efficiently checks whether shapes can collide or not. Unless your maps are truly massive, you shouldn't have much of a problem.

If you need to, you can add, remove, activate or deactivate shapes whenever necessary. HOC "simply" checks for collisions from a list of shapes whenever its update function is called, you can freely edit the shape list before/after the call so that it uses the updated list the next time it is called.
You might want to set the shapes of static objects (i.e. surfaces of the world) to passive, this should suffice for most tasks. Should you need to deactivate shapes, instead of removing you should ghost them which allows you to turn them on without having to re-create them.

[molul]

Thanks for the info! Let's see if I got the last part right: if I set all grounds/walls/ceilings shapes to passive they won't be taken into account when checking collisions, but I can still check my player's collision against those shapes, right?

[Golan2781]

Sort of, HOC handles this automatically. When HOC's update function is run, it checks for every active object whether there's a collision with a solid shape. Passive shapes can be collided with but they cannot collide by themselves.

Let's say you have a player object and three surfaces. Set the player's shape to active and the surfaces to passive. When HOC is updated, it will check whether the player collides with one of the surfaces. It will however not check whether the surfaces collide with anything - most importantly, not with themselves either.
Checks HOC will perform:
With passive: Player->Surface1,Player->Surface2,Player->Surface3
Without passive: Player->Surface1,Player->Surface2,Player->Surface3, Surface1->Surface2,Surface1->Surface3, Surface2->Surface3

A similar effect can be achieved by using groups. Shapes using the same group will not generate a collision event - they will however be checked for colliding, so it's less efficient.

[molul]

Nice! Thank you, it helps a lot


EDIT: crap, I hate when I ask something I find impossible to understand and then I find out what's wrong in a little while >_< Sorry if you read this post before I edited it.

But this question is "legit": I've changed my love.load() so it creates all ground tiles. In my current test stage it's more or less 1500, but the final stages will be 10 times bigger. Should I worry about having 15000 shapes to check?

[MarekkPie]

(it's HardonCollider, not HardOnCollider; you know, Large Hadron Collider, but with the usual LOVE library naming scheme.)

HardonCollider uses something called a spatial hash to localize collision checks. It's essentially a grid that lays on top of the screen and only forces collision checks between things in the same grid. So, the player (or any non-passive/ghost) object will only potentially collide with a much smaller portion of map, because it's not really feasible for them to collide with something off screen or on the other side of the screen.

[molul]

(it's HardonCollider, not HardOnCollider; you know, Large Hadron Collider, but with the usual LOVE library naming scheme.)

Oh, I thought it was a dirty joke, like the "Anal" library for animations. Not kidding, I believed that!

Thanks for the info. I'm closer to finish the new ground detection logic

[Robin]

Oh, I thought it was a dirty joke, like the "Anal" library for animations.

It is.

[Xgoff]

But this question is "legit": I've changed my love.load() so it creates all ground tiles. In my current test stage it's more or less 1500, but the final stages will be 10 times bigger. Should I worry about having 15000 shapes to check?

i would be worried that the vector allocation/collection overhead (hardon collider is vector-heavy last i checked) would be an issue with that many shapes, so you'd probably want to test that

[molul]

Oh, I thought it was a dirty joke, like the "Anal" library for animations.

It is.

I lol'd!

But this question is "legit": I've changed my love.load() so it creates all ground tiles. In my current test stage it's more or less 1500, but the final stages will be 10 times bigger. Should I worry about having 15000 shapes to check?

i would be worried that the vector allocation/collection overhead (hardon collider is vector-heavy last i checked) would be an issue with that many shapes, so you'd probably want to test that

So far I've lost some performace, so I'll be aware. I worst comes to the worst, I'll just divide the stages in substages as needed.



One more question: is it possible to get if a shape is colliding with any shape from a group? Currently I'm doing a for loop to check all the shapes from a group, but I wonder if there's a faster way to access that info through vector. Kind of

Code: Select all

shape.collidingGroups = {} 

that would be updated everytime a collision is detected. Thus, I'd just need to check if shape.collidingGroups.mygroup exists.