Simple, lightweight, general purpose collision detection

[rude]

Hardon Collider

+1

Whether it's a reference to Richard Dawkins' legendary typo or not.

[HAJ523]

This needs to happen!

Would be interested in using and contributing.

[Lap]

Speaking of super useful community libraries, wasn't there some fancy text writing library that included in-text color changes and such that the community could work on together? Almost every game will use text somewhere.

RichtText? It's already (mostly) finished.

Awesome. I'll have to try it.

[Taehl]

So... How is the system going to work? Does one just have a table and everything in it collides with one-another? Or will there be multiple tables (one for statics (ground, platforms) and one for dynamics (player, enemies)?)? Are collisions going to be square? Rectangular? Will it be tile-based? Is the collision and detection system going to control movement and momentum, or will it only inform objects that they've collided?

Hell, I'd go code it myself if I knew exactly what the Love community wanted it to do.

[TechnoCat]

Hell, I'd go code it myself if I knew exactly what the Love community wanted it to do.

I would want a set of MiddleClass shape objects that have collide functions. Just something as simple as that is what I imagined.

[Taehl]

I think it would be neither lightweight nor general-purpose if it relied on such other libraries...

[kikito]

well, as long as there's a single shape:method() notation, middleclass-based objects perform like the regular lua "table-with-a-metatable" ones. middleclass just adds some convenience methods-it can't do much more than that in 122 lines of code.

Mind you, I'm not saying that middleclass should be used; I'm just saying that the efficiency or lightweight argument isn't sound. There are other arguments there - for example newby-friendliness.

[Robin]

I have been purposefully absent from this discussion for a while now, to avoid any misconceptions about my involvement, but there are some things I'd like to reply to, so…

So... How is the system going to work?

It's good to discuss that now.

Does one just have a table and everything in it collides with one-another? Or will there be multiple tables (one for statics (ground, platforms) and one for dynamics (player, enemies)?)?

All possible. I would suggest going with whatever is both flexible and simple.

Are collisions going to be square? Rectangular?

Possibly.

Will it be tile-based?

Probably not. Too restrictive.

Is the collision and detection system going to control movement and momentum, or will it only inform objects that they've collided?

Probably the former. It's a bit silly to have a physics lib that doesn't actually handle any physics.

Hell, I'd go code it myself if I knew exactly what the Love community wanted it to do.

By all means, please do. Make a start, slap a name on it and release it unto the unsuspecting public. Even if it's not really what people want, we could still use parts of it if it's written in a reusable.

[Kadoba]

Hello, I'm new to love. I just discovered it last week but I realized that it was missing a simple collision library like the one described in this thread so having no prior experience with LUA and very little geometry skill I started making one myself called "geo".

After dozens of hours and headaches its actually starting to shape up.

However a couple of things:

• It is written entirely in LUA, not C++. Although apparently binding LUA is relatively easy so that could change.
• I am not a very experienced coder. This will actually be my first public release of any kind. (<- that's red flag if you just missed it)
• It is currently not in a very presentable state but is getting very close.

These are the goals for the first release:

• Be able to create collision bodies shaped like rectangles (non-rotatable), circles, segments, and points.
• Frame independent (step-wise).
• A collision grid for the broad phase.
• Customizable responses but with simple, predefined "push-out" ones available.
• Automatically tweens drawing locations between steps so transitions are always smooth.
• Includes a useful vector class (currently this is built over a very ugly adaptation of hump vectors with some extra functionality)

The long term plan is to include convex polygons and possibly multiple shapes in a single body.

Currently the definitions for all shapes are made (actually there's just one general "shape" table) and almost all collision test possibilities are done. Rectangles are completely working and it's very easy to customize callbacks.

Here's a simple example of how it currently works:

Code: Select all

function love.load()

   colsys = CollisionSystem:new() -- create a new collision system
   colsys.step_size = 0.01 -- steps update every 1/100 of a second
   colsys.step_max = 3 -- maximum amount of steps in one update

   --create new bodies for the ground and player
   player = Body:new("player", Shape:new("Circle", 50, 0, 16), colsys)
   ground = Body:new("ground", Shape:new("Rect", 0, 0, 400, 50) colsys)
 
   -- make a new callback for player and ground. The function will put the player's location above the ground.
   colsys.callback["player"]["ground"] = function(player, ground) player.next.y = ground.current.y - player.next.height end
end

function love.update(dt)
-- advance the collision system.
colsys.advance(dt)
end

function love.draw()
-- drawX() and drawY() will tween the correct values so drawing is always smooth
love.graphics.draw(player_image, player.drawX(), player.drawY())
end

Once I get it to where I feel like it's in a stable state I'll release it (I may need some help with that). Right now I'm in the process of moving so it may be another week or two.

[Taehl]

... More discussion, please! I really want to know what I'm supposed to be making! What are the available shapes - just rectangles, or will more be needed? Do shapes need to be able to be attached to other shapes? Are shapes allowed to rotate? Will there be slopes? What kind of scale are we talking about, and will there be a limit to how big or small shapes can be? Can shapes travel at very high velocities (further than their size each frame), or will there be a relatively low terminal velocity? How feature-full will it be - just something that'll work for basic platformers, or do mass, friction, etc. enter into it?