Polar grid drawing refined

Hello again

Last time I showed a preview of polar grids it was a full cycle starting from the origin containing all layers up to the edge. During runtime if only part of the grid is visible to the player rendering the whole thing can be a waste of resources, that's why you have the option of specifying a specific rendering range.

I was trying out several approaches of interpreting the rectangular range, but in the end I went for a polar approach. What does this mean? You have two Vector3 values, one called renderFrom, the other called renderTo. The x-coordinate tells what radius to start and end at, the y-coordinate gives us the starting and ending angle and the z-coordinate gives us the starting and ending layer. Here is an example of what if can look like:

The only limitations are that the starting radius cannot be less than 0 and starting values cannot be larger than ending values (and vice-versa). The only exception is the angle, this is is necessary in order to  be able to draw a sector from, let's say 300° to 15° (which can be seen as from 300° to 375°).

This has been the biggest roadblock so far, now I need to do some proper testing and final polish, write the new documentation and I can submit the update to Unity. Supporting a new type of grid is a substantial effort and, since everything is interconnected, it usually requires going through the code for the other grids as well. Sometimes parts that seemed general enough might need to be overridden and other parts that seemed very specific become more general and need to be moved up the hierarchy. Considering this and the updates since the release of version 12.0 I believe raising the price to from 20$ to 25$ is appropriate.

Of course, as usual, if you already bought Grid Framework all updates are free for you. If you intend to buy Grid Framework, now is the chance to still get it for the lower price. You don't need to rush and get it immediately though, I'll post an at least one more update before I submit version 1.3.0.

As always, thank you for your support

HiPhish

Grid Framework version 1.2.5 released

This release serves as a preparation for Version 1.3.0, which will add polar grids

• The methods NearestVertex/Face/BoxW and NearestVertex/Face/BoxG replace FindNearestVertex/Face/Box and GetVertex/Face/BoxCoordinates respectively. This is just a change in name, as the old nomencalture was confusing and makes no sense for grids with multiple coordinate systems, but the syntax stays the same. The old methods will throw compiler warnings but will still work fine. You can run a Search&Replace through your scripts to get rid of them.
• The GFBoolVector3 class can now be instantiated via GFBoolVector3.True and GFBoolVector3.False to create an all-true or all-false vector
• Similarly you use GFColorVector3.RGB, GFColorVector3.CMY and GFColorVector3.BGW for half-transparent standard colour vectors

I apologize for the inconvenience of having to rename the methods, but I'll try to explain my reasoning. When Grid Framework was originally conceived only rectangular grids were in place. For rectangular grids only one coordinate system really makes sense, so there were two spaces: world space and grid space. Consequently, every point could only exist in either of those two.

One of the most basic needs I implemented back then was to find the nearest vertex of a point, hence the name FindNearestVertex, and later the same for faces and boxes. I also needed a similar method for grid space, I wanted to get the point's grid coordinates.

The problem arises when you start having more than just one grid space. When I wrote hex grids I always considered the possibility of having a second coordinate system aside from the herringbone pattern, and that's when I should have realized that my naming convention was... well, stupid. Polar grids will have two coordinate systems from the start, so I had the choice to either use some band-aid solution and have a naming convention that makes even less sense, or I could make a clean cut here and now.

So, what does this mean for you? At the moment nothing aside from a bunch of compiler warnings. You can just ignore them if you want, the old methods are still in place, they just call the new ones instead. I don't have any intention of removing them anytime soon, so you don't need to rush ahead and replace your old calls. The syntax has stayed the same, so running a quick Search&Replace will fix things for good.

The new naming convention goes as follows (without the brackets): Nearest[Vertex/Face/Box][X], where X stands for the coordinate system in question. For world it's W, for grid it's G and for the upcoming polar coordinates it will be P. Obviously only W and G make sense for all grids, the rest depends on the specific type of grid. You will be able to convert a point from any system into another (like PolarToWord).

I am sincerely sorry for this, but please understand that this was a necessary step in order for Grid Framework to remain clean. I always find things to improve and tweak, but most of them are under the hood and go by unmentioned, it just happened that this one was on the surface.

a first look at polar grids

I've been working on the next type of grid: polar grids. The polar grid is based on polar coordinates, meaning instead of identifying a point's position using X and Y coordinates we use a radius and an angle. The radius tells us how far from the origin the point is and the angle tells us the direction. This screenshot shows the new polar grid in Unity

A polar grid is defined by three values: radius, sectors and depth. Radius refers to how far apart the red circles in the picture are, sectors is how many sectors you have and depth is how far apart each two layers of a polar grid are. Since we have a third dimension the mathematically correct term would be a "cylindrical grid", but I'll call it polar just for the sake of simplicity. If you have cylindrical coordinates just ignore the third component and you get polar coordinates. You'll notice that the angle between sectors does not define the grid, because the sectors have to cover the grid completely; you can't have the last sector be only a third of the other sectors. I'll see if I can still make the angle adjustable via an accessor.

Polar grids have a few unique quirks that differentiate them from rectangular and hex grids. First of all we now have circles instead of straight lines, but we can't draw actual circles. My solution is to add a "smoothing" option; without smoothing the red lines inside the sectors will be all straight and the grid will look like a spider's web, but each increase in smoothing breaks up the line into more segments, coming closer to a round shape. Of course increasing the smoothing means that there will be more points to calculate, but fortunately a single-digit number is already enough to get a smooth look. Also, the more sectors you have, the less smoothing you need.

A more fundamental issue rather than just a cosmetic concern is the coordinate systems. Yes, plural. The first one is the regular cylindrical coordinate system where radius, angle and height are given as absolute from the origin with respect to world dimensions. This means, no matter what you set your grid's radius, sectors or depth to, a given point will always have the same coordinates. The other one is a grid coordinate system where each component represents the relative position inside the grid with respect to radius, angle (calculated from sectors) and depth. Changing the grid also changes the coordinates of a given point.

You can convert between both coordinate systems and world space on the fly and neither system is really "better" than the other. It would be just wrong to have a polar grid without polar coordinates and it is what you want to use when moving objects in the world. On the other hand, it you want to think in "grid space", it's easier to think in terms of fields, like a board game, so grid coordiantes appear more intuitive.

At this point all the math is done and the hardest to implement methods (drawing, coordinate transformation and finding nearest vertex/face/box in all three coordinate systems) have been written. The next parts should be easier to implement, but I'm not exactly sure how to design them (what exactly does "aligning" in a polar grid even mean?). I'll keep you updated once I have more to show.