|
Post by ldicesare on Feb 18, 2017 11:29:55 GMT
Hello. Just got the framework and started playing with it. I used GetHexCentersWithinSquare to get all the hexes in a rectangle in order to create arectangular map. To my surprise, the map created is NOT rectangular. The culprit is the Rect class, Contains method. It behaves badly! If you're on the left or bottom border, the check uses <= and so you're in. If you're on the right or top border of the rectangle, then the check uses < and you're out. So generating a rectangle patch looks like this (to test, use a 6x4 rect or 30x20 if you like to see it big): -xxxx- xxxxx- xxxxx- I had to change the code this way: // if (r.Contains(HexCoordinates.HexToWorld(pos))) -- old code var worldPos = HexCoordinates.HexToWorld(pos); if( r.x <= worldPos.x && r.x + r.width >= worldPos.x && r.y <= worldPos.y && r.y + r.height >= worldPos.y) in order for it to behave better. This gives at least a symmetrical look: -xxxxx xxxxxx xxxxx- Well, I'd expect to actually get a rectangle, like that: xxxxx xxxxx xxxxx I can find out why there's a discrepancy along the 0 axis,but the method should be symmetric and it's currently not because Rect.Contains has been badly coded. You might want to check it and replace the calls to Rect by calls to a Rect that manages both ends of the rectangle in the same way.
|
|
|
Post by khash on Feb 18, 2017 12:26:27 GMT
I'm not sure what the problem exaclty is with what you have, but you should remember that the transformation on floating point produce errors by the nature of the variable type. Also conversion of the hex coordinates to the world is far from perfect. Hexagonal coordinate system and regular 3d systems are completely different spaces and errors and rounding are handled in many places to ensure better results but some errors would persist in your results if you look for value-perfect positions. eg by defining rectangular like (0, 0, 1, 1) some places my endup at 0.97 and another at 1.01 even though they seem aligned. Also potential error may grow with very far positions as well
|
|
|
Post by ldicesare on Feb 18, 2017 12:36:54 GMT
Yes, there are additional errors due to the fact that 3.0 != 3.0 because somehow a 2e-17 error squeeezes in at some point when converting ints to floats in different ways. I added an epsilon to fix these issues, but the Rect class itself remains bugged and you should be careful using it. Unity documentation of the function copies the documentation of one of the C# base classes, including reference to an argument that no longer exists (parameter allowInverse ). The underlying function is bugged as it compares with <= on the left and < on the right. So even if you converted to int, the code would give false results because the left part of a rect is contained in the rect, and the right part of the rect is not contained in the rect. So anyway it's fixed and thanks for providing us with this framework (and Thea of course!). Also thanks for bothering to answer so quickly.
|
|
|
Post by khash on Feb 18, 2017 13:16:16 GMT
Thanks for the hint, one learns something new every day XD
|
|
|
Post by robert45 on Jul 7, 2017 11:48:03 GMT
Very useful advice.
|
|