Grid Framework [scripting and editor plugins]

If you want you can play with it now already. Create a C# script named TerrainMeshBuilder and use the following code:
http://pastebin.com/Vuy9Z2sP
You can then use a plain text file like this as your height map:

Code (csharp):

1.  
2. 0000000012
3. 0000000012
4. 0001100011
5. 0001100000
6. 0001100000
7. 0000000000
8. 0000000100
9. 0000000000
10. 0000000001
11. 0000000011
12.  

Create grid in your scene, add the script, drop the height map into it, position your camera (and a light source for shading) and hit play. For a real game you'll want to use something more robust as you rheight map, like JSON or XML and it would be a good idea to have the materials outside the script for easier tweaking. Also, the wireframe method I use is not very fast, you should see if there is a better solution, like a wireframe shader or something. Here is what it looks like in action:

http://i42.tinypic.com/2f0eff7.png​

 

+1 for cubic hex coordinates, yay!

The only other suggestion I would have for hex grids is to incorporate a GetNeighbors(x,y,z) so you can quickly get an array of all the neighboring tiles. Likewise GetVertices(x,y,z) where x,y,z is again a particular hex. Might as well go for broke and do GetEdges as well

 

the rendering is quite slow for the terrain example. Is it using the same method for rendering your other grids?

 

I will eventually, once the ground work is laid out it will be (relatively) easy to do. Here is a site that explains various coordinate systems and algorithms, so if you can't wait after my next update you could try it yourself. But first we need the extra coordinate systems to work with.
http://www.redblobgames.com/grids/hexagons/

The grid is not being rendered, just the mesh, so this is different. What's causing the slowdown is the way I do the wireframe lines, if you comment away that part (the entire OnRenderObject method) the speed should go back to normal. That's why I said in a real game you should look for a better solution for wireframe (like a shader).

 

Great, yes I have already implemented this for the herringbone/offset grid using three arrays(hexes,vertices,edges) and those functions but if it was included in the product by someone less likely to screw up the math it would make me feel better

Also that website was my primary resource for learning about hex grids, great resource

 

Hi,
I want to make a tile base top-down rpg game with 2d isometric sprites. I need a isometric grid system so that I can place snap and move sprites. I'm looking a start kit for this so that it save my time. Please guide me can this grid framework helps me in this regards if yes, how?.

Thanks

 

Isometric and 2D usually means everything is in plain old flat 2D without any rotation, but it's drawn in such a way that it looks like 3D. In grid Framework you can rotate a grid or the camera until it gets the right look, but it will be in 3D world, not in flat 2D anymore, which is a problem. To give you an idea what I mean look at this tutorial series:
http://xnaresources.com/default.asp?page=Tutorial:TileEngineSeries:4
http://xnaresources.com/default.asp?page=Tutorial:TileEngineSeries:7
http://xnaresources.com/default.asp?page=Tutorial:TileEngineSeries:8
http://xnaresources.com/default.asp?page=Tutorial:TileEngineSeries:9

What you want to do is use a 3D engine to have a 2D game that looks 3D. That's pretty redundant, it would be much easier if you used simple 3D models or used a 2d engine, or if you could roll your own isometric tools for unity in the style of the above tutorial. I'm afraid Grid Framework can't help you with isometric 2D, because what you would need is a grid that can give you the rhombic shape without being rotated. Unity is a great engine, but there are specific things it was made for and everything else requires you to do the ground work yourself.

 

Hey hiphish,

I'm having an issue when converting from world points to vector points. Im using a raycast from the camera to select a face, lets call that rayPoint. If I use raypoint such that selectedFaceW = grid.GetNearestFaceW(rayPoint) and selectedFaceG = grid.GetNearestFaceG(rayPoint) I get 2 different variable that should convert fine between each other. However, if I convert selectedFaceW to grid points using grid.WorldToGrid(selectedFaceW), I get Vector similar to selectedFaceG, but off by 0.5.

My grid is in the XZ plane attached as a component to the plane game object. Any idea what would be going on?

Thanks!

PS. My email is graham.gaylor@gmail.com

 

What you're seeing is a stupid design decision I made a long time ago. Face coordinates for rectangular grids are all offset by half a unit in each direction; the idea was that if you have a board game you want to base your coordiante system on faces instead of vertices, but the inconsistency is just stupid. When it says G for grid coordinates it should be consistent all the way across the framework. I changed this to normal in the update I'm working on, but I can't release it yet, too much wet paint.

If you want the new behaviour find the file GFRectGrid.cs under Plugins/Grid Framework and replace the NearestFaceG method with the following code:

Code (csharp):

1.  
2. public override Vector3 NearestFaceG(Vector3 fromPoint, GridPlane thePlane){
3.         return RoundPoint(WorldToGrid(fromPoint) - 0.5f * Vector3.one + 0.5f * units[(int)thePlane]) + 0.5f * Vector3.one - 0.5f * units[(int)thePlane];
4.     }
5.  

This used to make more sense when the method was still called GetFaceCoordinates, because it was indicating a "face" coordinate system, but that was unintuitive in its own regard.

 

Dude, awesome response time. It makes me so happy when developers follow their users and answer questions
And thanks for the tip! Much appreciated.

EDIT:

That fixed the original problem I was having, but now some other weird stuff is happening when it comes to drawing the tiles on the map. I don't *think* this is the intended behavior with the fix above, but if it is, my apologies.

void OnDrawGizmos () {
Gizmos.color = Color.red;
Gizmos.color = Color.green;
grid.NearestFaceW(selectedFaceW, GFGrid.GridPlane.XZ, true);

}

 

Looks fine to on my setup. Maybe you need the updated NearestFaceW method as well:

Code (csharp):

1.  
2. public override Vector3 NearestFaceW(Vector3 world, GridPlane thePlane, bool doDebug = false){
3.         //debugging
4.         if(doDebug){
5.             Vector3 debugCube = spacing;
6.             debugCube[(int)thePlane] = 0.0f;
7.            
8.             //store the old matrix and create a new one based on the grid's roation and the point's position
9.             Matrix4x4 oldRotationMatrix = Gizmos.matrix;
10.             //Matrix4x4 newRotationMatrix = Matrix4x4.TRS(toPoint, transform.rotation, Vector3.one);
11.             Matrix4x4 newRotationMatrix = Matrix4x4.TRS(GridToWorld(NearestFaceG(world, thePlane)), transform.rotation, Vector3.one);
12.            
13.             Gizmos.matrix = newRotationMatrix;
14.             Gizmos.DrawCube(Vector3.zero, debugCube);//Position zero because the matrix already contains the point
15.             Gizmos.matrix = oldRotationMatrix;
16.         }
17.        
18.         //return toPoint;
19.         return GridToWorld(NearestFaceG(world, thePlane));
20.     }
21.  

The update doesn't change the output vector, only where the drawing is placed, so the result of the old method was still correct. Anyway, that will only draw the tile using gizmos, which is intended for debugging points in the editor, but gizmos won't show up in the finished game. You hould look for a proper drawing solution.

 

Perfect! That fixed it. And yea, I was just using the gizmo drawing to get some visual feedback. I'll definitely look into the proper rendering calls soon.
Thanks again.

 

Just FYI you're still including DocSearch in the AssetStore package.

 

Yeah, I haven't published an update since I accidently included it, so unfortunately it will still be around for a while.

 

Hello and good day. We are currently planning to make a tactical game using tile-based movement on a grid. Will this framework be useful for us because if yes we will consider in buying it. I also want to ask if we can implement path-finding algorithms for this one. The algorithm we're planning on using is A* algorithm, can we implement such algorithm to your framework? Thank you and have a nice day.

 

Tile-based movement can certainly be done. For one, you could have your destination in grid coordinates and convert the result to world coordinates:

Code (csharp):

1.  
2. Vector3 dest;
3. GFGrid myGrid;
4. player.position = myGrid.GridToWorld (dest);
5.  

If you want to move one tile at a time something like this would be easier:

Code (csharp):

1.  
2. player.position += myGrid.forward; // forward only for rectangular grids
3.  

Of course you could use waypoints as well:

Code (csharp):

1.  
2. Vector3[] dest = new Vector3[4] {...};
3. for (int i = 0; i < 4; i++) {
4.     player.position = myGrid.GridToWorld (dest [i]);
5. }
6. // or
7. Vector3[] dest = new Vector3[4] {myGrid.forward, myGrid.forward, -myGrid.right, myGrid.forward};
8. for (int i = 0; i < 4; i++) {
9.     player.position += dest [i];
10. }
11.  

This would just give you the positions where to move to, but you will still have to write the movement logic. You can do it many ways, for a turn-based game a tweening solution like iTween (free) looks like a good idea.

Pathfinding is possible, but you will have to write the algorithm yourself, there is nothing built into Grid Framework. What you will need for A* is a graph, I don't know what type of graph representation you want to use, but a two-dimensional aray could be built the following way:

Code (csharp):

1.  
2. GFGrid grid;
3. int[] from = new int[2] { 0, 0};
4. int[] to = new int[2] { 15, 10};
5. Vector3[,] graph = new Vector3[15, 10];
6. for (int i = from[0]; i < to[0]; i++) {
7.     for (int j = from[1]; j < to[1]; j++){
8.         graph [i, j] = grid.GridToWorld (new Vector3 (i, j, 0));
9.     }
10. }
11.  

Other graph representations can be done similarly. You will still need to give weight to nodes and edges. Also, since this graph contains points in world space you don't have to use any conversion:

Code (csharp):

1.  
2. player.position = graph[2, 7];
3.  

I hope this i what you wanted to know, if you have any further questions feel free to ask.

 

Thank you so much for answering. I think this is enough information we need to know(for now). We will give this framework a try and if we have any questions we will just ask. Thanks again and have a good day.

 

It has been two weeks snce my last update, so I wanted to let you guys know what I am currently at. The good news is that the new coordinate systems have been implemented and are ready to use. Of course there is still the obligatory last check to do, but i expect everything to be fine. All methods that got the axe are now gone as well and have been put into extension methods and ZIPped into archives; that way no one will accidently use the deprecated API. I also added a section called Legacy Support to the manual with instructions.

Now for the promised rant. I have transitioned all the documentation to Doxygen, both scripting reference and user manual. Now all that would be left would be to sprinkle some CSS fairy dust on top of it so it looks nice and I'm done. Except editing the CSS is an exercise in pure trial error frustration, there is no documentation for it and the code is barely commented. The manual is a pain in the butt as well, it's like it was written for people who already know how to use Doxygen. It will go into detail about all the possible ways of formating my text, but it doesn't explain how to get the text into the manual in a specific order. Don't worry, I got it all covered now, but it was not a fun journey.

I wanted to slim down the default HTML design, because I think the large header buttons at the top are too large and vibrant, but I've had it with Doxygen. Don't get me wrong, it's a great system and I'm sure everything made perfect sense when wrting it, but it is obscure from the outside. Anyway, I'm going to stick with the default design for now, but at least I limited the size of images so they don't disrupt the flow of the text. There probably won't be any PDF documentation anymore though, the HTML is more flexible to read and navigate, plus the PDF generated by Doxygen looks rather... ugly.

Now that I've got everything out of the way it's time to wrap it up and hopefully get it released next week.

 

Thanks for the update Hiphish, really looking forward to it.

I've been playing around with cubic and trapezoidal hex grid coordinates on my own and it's making my brain hurt, think I will wait the extra week for your update

 

Hi, hiphish,

This is a powerful tool that could implement my game idea. Great Job!
And I am now learning this framework to try to integrate it in my SLG game. I wonder if the framework is supporting below feature:
1. (0,0) Point for the grid based from left top direction, then x axis should be increased to right, y axis should be increased to bottom. Like Windows form's coordinate.
2. I only want to use the grid part which x>=0 y>=0 (one quarter of the whole grid), is that possible? Related to above one.
3. Is there any built in method to get the range grid cells? For example, I have a point (5,5), I want to get all the grid cells which the distance<=2. (That means I want to get all the grid cells in 2 unit far away) Notice, both rec and hex grid.

Best regards.

 

Let me first answer your second question: All grids are infinitely large, so you can use whatever part of it you want and ignore everything else. In fact that's the only way to work with it, since there is no way you will ever use the whole grid, considereing it's infinite.

The first question is tricky, rectangular grids use the cartesian coordinate system with the Y-axis going upwards. You could either internally always multiply the Y-coordinate with -1 and then use the lower right quadrant (x >= 0, y <= 0), *or* you flip the grid 180° around. Grids are components and as such are attached to GameObjects. gameObjects can ro rotated and the grid's calculations will respect this rotation. Rotating the object 180° around its X-axis should yield exactly what you want. Just keep in mind that when you use the grid to align objects and you rotate them to the grid they will be upside down. In that case either make them not pick up the grod's rotation or add a correctove rotation to them avery time.

Your third question can be solved with a simple loop:

Code (csharp):

1.  
2. int radius = 2; // the range
3. int[] centre = new int [2] {5, 5} // the central face
4. List<int[]> faces = new List<int[]>(); // we'll store the resulting faces as pairs inside a generic list
5. for (int i = -radius; i <= radius; i++) {
6.     for (int j = -radius; j <= radius; j++) {
7.         if (i == 0  j == 0) // use this if you want to skip the centre itself
8.             break;
9.         faces.Add (new int[2] {centre[0] + i, centre[1] + j});
10.     }
11. }
12.  

This is for rectangular grids. Hexagonal grids are similar, but the details depend on the coordinate system (currently there is only the herringbone coordinate system, but i hae already submitted the new update that adds additional coordiante systems). If you want to use rhombic coordinates you do it just like above, except you skip pairs if they have the same sign and the sum or their absolute value is greater than the value of the radius:

Code (csharp):

1.  
2. for (int i = -radius; i <= radius; i++) {
3.     for (int j = -radius; j <= radius; j++) {
4.         if (i == 0  j == 0) // use this if you want to skip the centre itself
5.             break;
6.         if (Mathf.Sign(i) == Mathf.Sign(j)  Mathf.Abs(i) + Mathf.Abs(j) > radius) // skip these
7.             break;
8.         faces.Add (new int[2] {centre[0] + i, centre[1] + j});
9.     }
10. }
11.  

It makes sense if you take a sheet of paper and draw a few hexes, then connect them the way they are connected in a rhombic coordiante system and then skew it back into a rectangular pattern:

Code (csharp):

1.  
2. // O is the centre
3. // a number is an included pair belonging to the specific radius
4. // - is an omitted pair
5.  
6. 2 2 2 - -
7. 2 1 1 2 -
8. 2 1 O 1 2
9. - 2 1 1 2
10. - - 2 2 2
11.  

 

This will be my next purchase....I'm so impressed how you listen to your developer community, the support you provide and the continuous improvement to the product.

I too am eagerly awaiting Playmaker support, so consider this my +1 for that feature. Any timeframes for that you can share with us will be wonderful.

 

Hey, I am one of your customers, and I'm quite satisfied so far.

I wonder if, and when (please give a rough estimate, if possible) you plan to add pathfinding to the grid framework.
Ill need a pf system for my project, and would wait for pathfinding support for the grid framework, if this is planned within the nearer future.

 

Pathfinding is a larger endeavor, it has to be properly inegrated into the framework with no loose ends hanging around and it has to be implemented in a way that makes sense for users without having to read fifty pages of API reference. This is all still very vague, so I can't give any real estimate. I still hope to finish it this year though. The agorithm itself is not that complicated, you can read it on Wikiepedia, it's the question of how to get it all interlocked.

 

Version 1.3.2 of Grid Framework has been approved by the Asset Store Team. The biggest news is the addition of new coordinate systems for hexagonal grids. You have cubic coordinates, rhombic coordinates and the old odd herringbone coordinates now. Even herringbone and barycentric coordinates will be added at some point in the future for the sake of completion, but they are no priority.

The documentation received a complete overhaul. Rather than two manually typed PDFs you now have one automatically generated Doxygen documentation in HTML format. Previously you accessed it by double-clicking the PDF in your project view, not you can just go to Unity's help menu and the documentation will open up in your browser.
The user manual and scripting API are now together again. The top- and sidebar of the HTML can be used to quickly find what you want. There is also a new section called Legacy Support that contains information on changed or dropped features and how to restore them or upgrade your code. The changelog has also been added to the manual, thanks to Markdown you now have both a nicely formatted HTMl and a well readable plain text file.

There are also two new examles. The first example constructs a SimCity-like terrain mesh from a plain text file containing the heights as integers and allows you raise and lower vertices by clicking them. Just set up your grid, insert your height file and click play.
The other example uses polar grids to simulate a rotary dial, as found on old telephones. Click a number and the dial will rotate that much, print a message and then rotate back. This example can be used for circular GUIs, menus, clocks or anything else that needs to rotate around angles.

There is also the usual bug-fixing, vertex matrix methods got cut and the NearestFace/BoxG methods of rectangular grids have changed somewhat. You can find the exact details in the Legacy Support section of the documentation. Here is the full changelog:

 

Hi, hiphish,

Thank you for your detailed description for my questions. I learned a lot from your reply. Thank you again for your great work.

Best regards

 

just downloaded v.1.3.2, but the Sliding Puzzle example scene is totally broken.

 

I'm sorry, I'll upload a patch soon. In the meantime, you can replace the contents of the SlidingPuzzleExample.cs script with the following:
http://pastebin.com/nkErgU3j

 

Hey hiphish, first off great job on this amazing asset! I was wondering how hard it would be to implement this grid system into my game so that a player can place/rotate walls and add a roof?

Thanks,

Drew

 

Placing walls, and any other object by extension, is simple: First you get where the player is pointing to, then you round that position to the nearest face and finally place your wall there. Here is a quick mockup:

Code (csharp):

1.  
2. GFGrid myGrid; // the grid object you use
3. Vector3 pointedPosition; // hwere the player is pointing at
4. Vector3 roundedPosition = myGrid.NearestFaceW (pointedPosition, GFGrid.GridPlane.XZ);
5. // instantiate your wall object now
6.  

For buildings that are more than a face large you'll simply round the positionof the central point. Roofs are a specific topic, t depends on how exactly your game works. For example if you want an are surrounded by walls to fill with roofs you could make a rectangle and then fill its contents:

Code (csharp):

1.  
2. // turn world positions into grid coordinates
3. Vector3 lowerLeft = myGrid.WorldToGrid (lowerLeftWall);
4. Vector3 upperRight = myGrid.WorldToGrid (upperRightWall);
5.  
6. for (int i = Mathf.RoundToInt (lowerLeft.x) + 1; i < Mathf.RoundToInt (upperRight.x); i++) {
7.     for (int j = Mathf.RoundToInt (lowerLeft.y) + 1; j < Mathf.RoundToInt (upperRight.y); j++) {
8.         // spawn your roof
9.     }
10. }
11.  

If your game is heavily based on tiles I'd just keep everything in grid coordinates and only convert when you want to place objects in the world.

 

You're awesome man!! Appreciate the prompt response, that all makes sense and I will try applying this logic in the near future! Thank you so much for the help

- Drew

 

Code (csharp):

1.  
2. Type `GFGrid' does not contain a definition for `vertexColor' and no extension method `vertexColor' of type `GFGrid' could be found (are you missing a using directive or an assembly reference?)
3.  

Looks like an undocumented changed. Not an issue as I'm not using it anyway, but I wrote a PlayMaker action for it regardless so was alerted to the error on upgrade. Just a heads up for anyone that maybe using it. It appears gone completely, but it's still documented in the script documentation.

 

You're right, it got axed together with the rest of the vertex matrix, but it cannot be in the documentation anymore. The new documentation is generated with Doxygen, which parses the source code. If something is not in the source code, then it cannot be documented. Maybe you are still using the old PDF documentation. The last updated brought a new HTML-based documentation, you can access it from Help -> Grid Framework Documentation in the Unity editor or by opening Grid Framework/Documentation.html in your browser. If you still have the old PDF docs please throw them away.

 

Yes I am still using the PDF documentation. I did not import the HTML documentation, because I don't want well over a dozen files cluttering my project. If possible please consider parsing the HTML into a PDF or provide the documentation online instead of on import.

I'm also having a new major issue. My axis colors will not "stick". I change them, press Play, they reset back to default. Any idea why it's doing that?

 

I agree with Krileon. The HTML documentation is too cluttered. Especially with the extra folder you needed to add to the asset to keep Unity from trying to parse the javascript. For a local copy of the documentation I would recommend converting it to PDF or zipping it all up into an archive that is included in the GridFramework directory.

 

I uploaded the documentation to my Dropbox for now until i find a permanent solution:
https://dl.dropboxusercontent.com/u/22321777/GridFrameworkHTMLDocs/html/index.html

At first I wanted to provide a PDF as well, but the LaTeX code generated by doxygen was a mess an needed lots of search&replace to compile and in the end the resulting PDF was pretty hideous. The HTML files are not scattered around, they are still int that one folder, so if you want you can take the folder out of your project and place it somewhere else. Zipping it up wouldn't really solve any problem, you'd still have to unzip it and then you would have all the files back. I think an online documentation is unavoidable; I've had this prototype of a new website stitting on my hard drive for a few months, but I never came around to finishing it. I guess I should get back to work then.

I'll look into it.

 

I've got it! The scripts GFColorVector3 and GFBoolVector3 are missing a serializing directive. In the file GFColorVector3.cs (under Plugins/Grid Framework/Vectors) you have to turn line 12

Code (csharp):

1.  
2. private Color[] values = new Color[3];
3.  

into

Code (csharp):

1.  
2. [SerializeField]
3. private Color[] values = new Color[3];
4.  

then your values will be persistent. You can do the same thing for the bool vectors as well if you need them. Thanks for pointing it out, I did some changes to those two classes to make them fit with the .NET guidelines and forgot about serializing.

 

I think that zipping it up would solve the following problems:

• There wouldn't be a zillion documentation files to scroll through on the asset import dialog.
• There wouldn't be an extra directory containing a zillion documentation files cluttering the project.
• Requiring your users/customers to unzip the documentation before they could read it would also require them to place it where they want it. Or in other words, it's easier to double click the zip file to open it from within Unity and then extract the files to wherever is convenient than it is to manually browse to the documentation path and move the folder elsewhere.

Please note that the above is just my opinion. Take it for what it is. (c:

 

I agree with your first two points, but I have to disagree with ou third point. The entire documentation is under WebPlayerTemplates/GridFrameworkHTMLDocs, you just have to move that one folder to where ever you want. That's one step to move the folder and one step to delete it, two steps in total.

Requiring you to unzip the documentation is one step,then you have to move it either to WebPlayerTemplates/GridFrameworkHTMLDocs or somewhere else, and if you want you can delete the ZIP. That two or three steps.

However, the breaking point in your suggestion is that everyone has to go through these steps, whether they want the documentation in their project or not. My solution only affects people who don't want it. Since everything is in one folder you can either just uncheck it when importing or delete it in one go. The best option of course would be if Unity gave me a proper way to separate the documentation from the package. After all, it's not like their offline documentation is cluttering up people's projects. My problem is that the Assets folder is really the only place that's accepted by the import dialogue, I can't flace the files somewhere outside.

Anyway, I'm going to finish my website, then I'll be able to host an online documentation there as well. I'll post hwere and in my blog when it's up. Until then you can use the dropbox link I posted above.

EDIT: Now the help menu checks if there is a local documentation, and if it isn't it opens the online URL instead.

 

I've been using the Grid-Framework for a while now, however I have encountered a little problem that I've been wondering for a while now:
Let's say I want a 2-dimensional rectangular grid with the dimensions of 5x10 or something like that. The important point is that one of the dimensions is odd.
I'm using a Grid in combination with a BoxCollider to snap to the grid, but It's impossible to get an odd dimension smoothly. If I use 2.5 for the size, I get 2 and 1/2 fields in each direction, but I'd need 5 full fields (so a 0.5 offset into that direction). So far I've solved the problem by making the grid 10x6, and setting the box-collider only onto 5 of the 6 rows, for my specific case. I consider this a hack, however, and it requires me to offset my GameObjcets position by 0.5 into that direction.
I realize that the grid actually is infinit and the rendering stuff is the only thing that makes it seem limited is because it doesn't draw everything. A simple automatic/manual addition of an offset would probably solve the problem.

 

Grid Framework version 1.3.3 has been approved by the Asset Store team. This update adresses a bug introduced in version 1.3.2 where values of colour vectors (such as axisColor) and bool vectors were not persistent. Now they will stick again. I also broke the examples for the sliding puzzle and movement with obstacles, which are now fixed. Based upon a customer's question I also built a snake game example; it's mostly an extension of the grid-based movement but with several snake segments following each other.
And last, but for some people certainly not least, if you delete the local documentation (found in the WebPlayerTemplates folder) the help menu entry will forward you to an online documentation instead. Some customers complained about me cluttering their project with that folders, and they are right, but unfortunately that's the only place where I can place the files, or else Unity will try to compile the JavaScript files and throw a ton of errors.

The documentation files are all contained in that one folder, so you can either uncheck it when importing, delete the folder after import or move it somewhere else. I know this is inconvenient, but unless Unity provides me with a proper way to bundle offline documentation this is the best I can do.

 

Adding an offset option to the panel is not hard, but I'n not exactly sure what you want. Could you make a mockup screenshot or drawing?

 

Sure. I'll just use screenshots of my setup here, which is: A quad with size 20x5 and a RectGrid that should separate the area into 20x5 fields. The Grid has a collider that covers the area. The grid is not a child of the quad, since it makes the numbers easier to read.

I've highlighted the important stuff/changes in the screenshots. Sadly the forum downscaled them, open in separate window/tab for full resolution.

Here is the Setup without the offset:

As you can see, the grid does not create a 5x20, but a 20x(2x2.5) as expected by the size-parameter beeing 2.5.

Here is the Setup with the offset:

Here I worked around that problem by making the grid 6x20 and offsetting its and the colliders position by 0.5. As I see it, beeing able to tell the grid to offset itself by 0.5 would allow for 5x20 grids?

Hope this clears things up a bit.

 

I have a RectGrid with 2d array matrix ( 50 x 50 ), 0 is empty, 1 is occupied.
If started from a random position, How to find a possible location for 3x3 object that can be fitted into the grid without using brute force search ?
any better algorithm could you suggest ?

 

OK, I get it. The size works by applying the values to both sides equally, so entering 2.5 will add 2.5 to both sides. This is similar to how the sacle of Unity's Transfom works. What you want to use instead is the custom rendering range. There is a foldout in the inspector, open it and you can set your own renderFrom and renderTo values. If you want to offset the grid's origin though, that would require extra code. I'll look into it.

Off the top of my head I can think of k-d trees, they were designed to break up large spaces into neighbouring chunks. That way you only have to search through the part of the tree that's close to your position.

 

While this at least removes the additional row, it still does require an offset. It's not that much of a problem since you can work around it by moving the Transform, but it is kinda annoying and hacky.

 

Yes, I agree. usually the pivot point of a collider is at the centre and that's what used when designing my grids and i never thought of changing the pivot. So far I have successfully added this option to rectangular grids, hexagonal and polar are to follow. of course this affects only the grid component, you will still have to add the offset to the collider as well and i can't change that.

​

If you want I can PM you the changes, but I don't guarantee that I won't change the code until the actual release nor that it's bug-free (it won't break anythign that worked before though).

 

I'm unable to get this to render the grid at runtime. I have attached a view of my setup. Any help would be great.

I want this to be visible in game. I know this should work but i'm not seeing why it fails, I went through the examples and tried to set it to the exact same values and it still wont show up. I know I can see it if I have gizmos checked but I read that you don't have to have that anymore. Also, I updated the asset after the 21st update.

 

Just to make sure it's not because of your material, did you try leaving the material field empty? Also, your camera needs a special script added to it (GFGridRenderCamera), as explained in the manual.

 

Thanks for the fast reply. It was in fact the material... I don't know how I missed that. Thanks again for the speedy response! Product works great!