Continuing from our last post, We were just ready to create our grid “buckets”!
Buckets are small rectangles forming the grid; objects corresponding to each bucket location will be saved (a reference to them) in that bucket.
To create buckets (and our grid) we need to divide the size of our target canvas (it can be our stage size or a virtual stage) to create smaller rectangles, then we will need just to check each object against other objects only in the same bucket or neighbor buckets which will dramatically reduce the required number of iterations. but it’s important to decide about the bucket sizes according to our needs (number of objects, desired distance to check…) and since variables affecting or decision here aren’t constant, it’s better to make it flexible so we can decide about the bucket size later! we will start with defining a float variable that will dictate desired size of our bucket to the class, if it’s not defined when calling the class it can be created automatically according to number of objects and requested distance check etc. but for now … let’s keep simple!
Also, we would want (I imagine at this point) two methods:
1. obj.set() –> Objects will declare their position to class and get referenced in corresponding buckets.
2. obj.get() –> which will return an array of references in all the neighbors in the  requested distance.

Here to check the functionality of our Spatial hash grid class I’ll use a simple class I wrote before, which just generates bunch of random point objects on the stage, so we can put our class under some definable load, the Points class is simple (and anyway not the subject of this topic, but let me know if you want know more about it!):

So! here is the structure of our HashGrid class:
Here we just declared the class and bunch of variables and methods we know we’re gonna need.
There is also a displayGrid() function that will just draw our grid for us on the display so it’d be easier to understand and to debug.
But we have defined another class inside the HashGrid class as well (a nested class) near the end of this code snippet, Buckets class. that’s because in Java you should define the array type in declaration time and since our array will keep reference to Objects and there is not such a primitive called “Object” you need to define the object to be able to declare an array of that kine of objects, so we create a nested class called buckets to keep our bucket arrays and an array of our buckets in it!
Also you may notice that I hard coded another object type in my HashGrid class (The Points) which is not the best practice since we want to be able to use this class everywhere with no modifications, but for now and to keep it as simple as possible we are gonna leave it like that, but later on (in another post hopefully if I could) we will make it more abstract by using an interface or some other techniques.

Now we need to create an array of buckets, create an array in each bucket (to keep our object references) and populate our set() and get() functions:
Now our HashGrid class is all functional! awesome! but there is a few things still we need to do, some of them are relatively easy to implement, like adding the functionality to be able to define the desired distance to check (checking neighbors as well as the bucket itself) and also the Interface, we are gonna work on these later-on (hopefully!) in another post. But now to test our class we can create a new processing file (tab) and put this code on it:
Yep! it works! you can download, contribute or fork the whole project here at Github:
https://github.com/mim-Armand/HashGrid

While working on bunch of sketches to create visuals for one of my documents, I was thinking to implement it with a simple Spatial Hash grid, but since performance wasn’t that important in that particular project, I just did it the simple way (checking every node against all the others in each iteration which means —> n² checks / frame (90K check for 300 prticle points for example!)) and it worked just fine! but strangely enaugh it was bothering me that I didn’t do it the right way! and since I’m gonna to reuse the code in another projects for sure and since I’ll need to implement this technique anyway sooner or later in one of my “things”! I tried to give it a try and do it the “right way”.
I started by just thinking and trying to analyze the way I’d imagine it works, I wanted something simple and minimal, so I did bunch of sketches on paper like these one (which probably make sense just to myself!):

The concept behind spatial grids is simple: you keep track of each target object by keeping a reference to that object in the grid bucket beneath it (in a 2D scenario (which is expandable to a 3D one respectivly easy)), so each bucket is an array of references to objects located on that bucket’s position (on the grid), of course it can be further developed I think to a more efficient algorithm combining a quad-tree system for scenarios where objects are placed mostly not evenly on the grid ( buckets will have a limit size (let’s say 3) and then (if there is more than 3 objects located there) they’ll divide to 4 buckets…), but we don’t need that here since my objects will be scattered on space by a random perlin noise algorithm (almost evenly placed on enough large spaces). Doing a bit of research I found out some interesting libraries which would do the job just fine, like HashGrid class in giCentre Utiles library:

hashGrid = new HashGrid(width,height,10);

But first of all, I wanted it to be simple and just do a few things that I need it to do and secondly (and more important for me) I wanted to do it myself so I’d understand it and I’d be able to use the technique whenever and wherever (let’s say in my simple JS Canvas game) I wanted to, and all in all it looked like easy to implement! (surly enough, just to do the basic and probably not in the best way possible?!) So anyway I started to write the class:
(Ah btw, unfortunately, their source code is not available to public! (just a broken link on their Google repo site) and I didn’t find any other essay to do this on internet so I was (or am) pretty much on myself to figure it out! wish me luck!)

class HashGrid{
// It is just a simple class declaration so far!
 HashGrid(/*defined vars*/){
// constructor
 }
}

To keep reference to objects there is ArrayList class/ interface available in JAVA (and Processing) which is very convenient since it resizes dynamically according to the number of objects in it, but is slower than a simple array of objects, so it’d be better if we can have simple arrays but then we should think about a mechanism to add AND remove (There is a confusion for me though since in Java these methods doesn’t exist! but apparently they exist in Processing (as it explain in the reference page: Decreases an array by one element and returns the shortened array. (Also look at this snippet))) (EDIT: I further investigated this issue and found out that (as I guessed) the append and shorten methodes in processing are pretty ineficient and actually just create a new array, with one member more or less and copy the old one to it, and don’t respect Java specs, all in all, seems better to avoid them (after all we can do the same thing if we need and keep the code more reusable in another Java envirenment)) items manually to and from the array (which happens automatically using ArrayList) but due to Java Array limitations the length of Array can not be changed, … since our concern is performance here (that’s why we want to create a hashGrid in the first place!) we should obviously go with standard arrays. (I’ll make this decision later on, be cause although Arrays are faster but: 1.we need to allocate a considerable amount of memory to them either we use that space or not, and 2. it may bring more and in-neccesary complexity to the process when we need to itterate each bucket array to get references to objects… (EDIT: it turned out that it wasn’t that complicated! so I used simple Arrays finally, Although I guess other implementations, including the GiCentre Utiles, are using arrayLists, so I guess my methode should be a lot faster than other ones specially when the number of elements is higher) ), let’s go and start by creating out buckets:

. . .
TO BE CONTINUED IN THE NEXT POST!