Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!

We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.

hash space partitioning explanation needed

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
3 replies to this topic

#1 serumas   Members   -  Reputation: 723


Posted 14 May 2013 - 04:49 AM

Hi, sorry for stupid question


After lots of time of reading blogs and books about spatial hash partitioning on bradphase collision Im still cant understand some things. Maybe Im not too smart for that or its my english language knowledge.. So could someone to help finaly get point.


does hash partitioning is some kind similar to uniform grid, becouse it still has uniform cells, but  every cell has allmost unique hash value and stored not as map[w][h] but in list[hash]. So it could be used on endless world and empty cells were not stored.


Edited by serumas, 14 May 2013 - 05:17 AM.


#2 raigan   Members   -  Reputation: 726


Posted 14 May 2013 - 05:44 PM

I think there are many different ways to skin this cat. If you're really interested, Christer Ericson's book "Real-Time Collision Detection" has a great chapter on grids.


For a normal grid, you map 2d world coords (x,y) to 2d grid coords (u,v) via something like: u = floor(x/cellsize), v = floor(y/cellsize).


For a hashed grid, your 2d grid is only virtual, and it maps onto a 1d list of cells.


The way I approach this is to map the virtual (u,v) grid coordinates to a cell index i via something like: i = (u + (v * stride)) % list_length (where stride is the number of columns in the virtual grid). I don't know if this makes sense, but it works for me. AFAICR Ericson provides some other hash functions.


If your input coordinates may be negative, you can either just use abs() -- which is simple but ends up mapping points around the origin to the same cell, which may or may not be a big problem -- or you can handle them like you would a 2d rotation, i.e computing the naive (u,v) coordinates but then adding some multiple of the virtual grid dimensions to shift things into the proper range, so that u is in [0,num_columns-1] and v is in [0, num_rows-1].


Note that since multiple cells in the virtual grid can map to the same physical cell, you can't assume two objects in the same cell are necessarily close to each other, so you should do e.g an AABB test to make sure they're near each other, before a narrow-phase test.

#3 serumas   Members   -  Reputation: 723


Posted 15 May 2013 - 03:21 AM

So my statement is correct. Thanks I just wanted to make shure about that...

#4 LorenzoGatti   Crossbones+   -  Reputation: 2733


Posted 16 May 2013 - 03:28 AM

The benefit of hashing is being able to use a practically infinite grid with an arbitrarily small cell size, with negligible performance costs (computing hashes of positions instead of quantizing them, discarding the rare aliased objects). With a directly addressed grid you would have to compromise because you cannot afford the memory for enough grid cells, making your universe smaller and/or grid cells larger than they should be.
Produci, consuma, crepa

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.