Page 9 of 11
Re: Simple, lightweight, general purpose collision detection
Posted: Sun Jan 22, 2012 6:20 am
by tentus
vrld wrote:HardonCollider Update!
- Fixed polygon triangulation bug.
- Added Spatialhash:draw()
- Use class-commons for all the things
Usage of class commons is optional. If you don't use it, HC will work regardless. If you do, do it like so:
Code: Select all
class_commons = true
require 'slither'
Collider = require 'hardoncollider'
-- rest as usual
Awesome, dragged it into my current project and everything seems to be working great. Also, neat demo!
Edit: Just a note, you may want to increment your copyright for your next update.
Re: Simple, lightweight, general purpose collision detection
Posted: Sun May 20, 2012 4:09 pm
by vrld
Harder, Better, Faster, Stronger
In the last few months HardonCollider has undergone major (but mostly internal) changes:
- The new function HC:shapesAt(x,y) returns all shapes that contain the point (x,y) (brought to you by TechnoCat).
- HC:activeShapes() and shape:neighbors() are iterators to the active shapes and a shape's neighbors. In case you want to implement the detection loop yourself or do funky stuff in the collision callbacks.
- More importantly: speed improvements! The most significant speedup is gained by using a different (and much much faster) collision detection algorithm. The penetration vector should also be more accurate.
- Another speedup comes from using vector-light.lua (basically a table-less version of vector.lua). If you were using this module, you should use hump.vector from now on.
Besides the new functions and the removal of
vector.lua the API did not change, so you should be able to just use the new code without any trouble.
However, if you experience bugs, please post them here or
here. Same goes for feature requests.
Re: Simple, lightweight, general purpose collision detection
Posted: Tue Jul 10, 2012 3:42 pm
by vrld
Double Post! More updates!
- Fixed a bug with polygon merging/convex decomposition.
- Removed hash:getNeighbors() in favor of hash:inRange().
- Added shape:scale that lets you change the size of a shape without removing and adding it.
- Added HC:addShape(shape) that lets you add custom shapes if you are not satisfied with the available ones (see here). To be able to use the collision detection algorithm used by HC, you also need to implement shape:support(dx,dy). See here on how this works.
- Added hash:inRange(), hash:rangeIter() and (more importantly) HC:shapesInRange(). This is
stolen from inspired by bump.lua and mostly useful to quickly get the objects visible on the screen:Code: Select all
for shape in pairs(HC:shapesInRange(camera:boundingBox()) do
shape.parent:draw()
end
Re: Simple, lightweight, general purpose collision detection
Posted: Tue Jul 10, 2012 4:39 pm
by kikito
awesome!
Re: Simple, lightweight, general purpose collision detection
Posted: Tue Jul 10, 2012 9:04 pm
by ishkabible
how does vecto-light.lua work?
edit:
never-mind; I looked at the source. have there been any issues using light vectors with other functions given that your just passing around groups of variables?
Re: Simple, lightweight, general purpose collision detection
Posted: Tue Jul 10, 2012 9:17 pm
by bartbes
ishkabible wrote:
have there been any issues using light vectors with other functions given that your just passing around groups of variables?
I assume he knew what he was doing, so he kept this in mind all the way through. I happen to know why he does this though, it's because all the table allocations for "full" vectors were a bottleneck, and simply using multiple return values increased performance quite a bit.
Now, as a word of advice, don't assume this is the case for your code, vrld found this after profiling
his code.
Re: Simple, lightweight, general purpose collision detection
Posted: Tue Jul 10, 2012 9:49 pm
by ishkabible
I was actually aware of the reason for doing it. it's a bottle neck for most languages, allocation. and it *should* actually be more efficient in every case. because creation time, and access time are so much lower. there is no access time so check mate there; creation time is MUCH faster becuase allocation takes so long. depending on how copies are made(by reference or by value), the table could be slightly faster. with the table, you only need to copy 1 TValue*, with the doubles, you have to copy 2 TValue*(meaning two move instruction in the Lua VM, not just plain pointer moves) but this is drastically out weighed by the other benefits in most cases. if you copy the table by value then it becomes slower becuase a new table has to be allocated, and the elements have to accessed to be copied. but yes, profile your code first, always.
Re: Simple, lightweight, general purpose collision detection
Posted: Tue Jul 10, 2012 11:00 pm
by bartbes
ishkabible wrote:and it *should* actually be more efficient in every case.
I wasn't saying it might not be more efficient, I was saying it might not be your bottleneck (and it probably isn't).
Re: Simple, lightweight, general purpose collision detection
Posted: Wed Jul 11, 2012 5:47 am
by ishkabible
O, sorry; I misunderstood the use of bottleneck. yes, It probably wouldn't change performance very much unless your doing a lot of operations with vectors as in this case.
Re: Simple, lightweight, general purpose collision detection
Posted: Thu Jul 12, 2012 11:14 am
by vrld
ishkabible wrote:have there been any issues using light vectors with other functions given that your just passing around groups of variables?
The only thing you have to be careful with is how Lua handles multiple return variables. This will work:
Code: Select all
local x,y = vector.normalize(lx, ly)
local mag = vector.dot(x,y, vector.normalize(eye_x, eye_y)
while this wont:
Code: Select all
local mag = vector.dot(vector.normalize(lx, ly), vector.normalize(eye_x, eye_y)
It's also a pain - compared to "full" vectors - to write even just slightly complicated stuff. Case in point, the above could be written as:
Code: Select all
local mag = light:normalized() * eye:normalized()