Hehehehe … Kudos to .
Keep at it man … you’ll get it. 8-}
That’s the tricky part for sure, but it seems very doable. It wouldn’t work as well if there are large height differences between the tiles, as the sphere collision will be perfectly smooth, and the player could end up clicking through hills and hit the tile behind. For relatively smooth globes it would probably work well, though. I’d love to try to help you find out how to reverse the projection math, but I have to spend my free time making my turn based system marketplace ready. I’ll chime in if I think of something clever, though 
Thanks!
Definitely doable. I will get it worked out, one way or another. Any help is bonus.
The collision sphere can be invisible, so if mountain height is a problem I can just make the sphere extend out over the tiles a bit so that it isn’t a problem. It will be one of those things where I spend a lot of time clicking around a tile hundreds of times until I am sure there are no edge cases that can become a problem. Theoretically I could even use 2 and calculate the angle between to figure out where the player meant to click.
Just coming out of left field … but what if you extend the collision beyond the hexes and have those invisible hexes perform your collision. So your base hex on the visible sphere is lets say 20 units on each side. Your invisible sphere will then use hexes of like 30 units on each side. This should still keep the hexes aligned and your collision problem might be solved.
Dunno … just throwing it out there and I might be completely off the mark here. I do that sometimes. 8-}
Well that isn’t really even my current collision problem. What I am dealing with right now is that the projected sphere doesn’t actually have any collision. That is still on the flat map. I need collision to work on top of the projected sphere while also giving me the exact tile index for the tile that is clicked on the projection. That has to be converted from the hit location on the sphere back to the flat map. Once I work that out, any remaining collision issues should be trivial.
So I am trying to replicate the sphere projection by arranging collision volumes into a sphere to make sure I understand the process. Here is an image of my current math fail:
Nevermind the flat background, the object of alien origin is the problem. I have pretty much copied the math in the material into blueprint as faithfully as possible. Not working. I don’t know if things operate out of order or some node acts a little differently in the material compared to blueprint. It is pretty much all math so I am not sure what could be different.
I don’t know if anyone will be able to make sense of these scribbles, but just in case this is a compressed version of the blueprint that copies the material:
C(Vector) = Current Vector (Absolute World Position in the Material. Where in the material this would be a pixel, in the blueprint this is the original vector for a Volume)
O(Vector) = Offset Vector
R(Float) = Radius
L1(Vector) = C + O
L2(Float) = R + Cz + Oz // Cz & Oz =Z float values of the C and O vectors
L3(Float) = 2 - (L1 Vector Length)/L2
L4x(Float) = L1x * L3 // The X Float Value of L1 Vector
L4y(Float) = L1y *L3 // The Y Float Value of L1 Vector
L5(Float) = L2^2 - (L4x, L4y, 0 Vector Length )^2
Heya ,
Here’s what I came up with for collision using ~the same math from the material. It doesn’t move in game, as it is only setup in the construction script, but you can see how it would operate in the editor. The main math is all in the Macro called ProjectToSphere.
Really what needs to happen is it needs an array of vectors that are then offset by the Actor/Component location, then those vectors are used to project onto the sphere during/after a move, figure out the transform, feed that into the collision shapes. This method is super expensive on a per frame basis.
I’m thinking there’s gotta be a much more simple method that takes the location hit on a collision sphere then reverses the math to get the XY grid cords then offset that back by the location of the Actor (Then later, when you want to wrap everything, you’d have a known offset vector that’d be used instead of the Actor location).
Yeah we were talking about something like that. A collision sphere is probably the most ideal solution. I am trying to understand how the projection works in the first place in order to reverse it. Seeing it work in blueprint is good, so thanks for that! I got your version to show up after I aligned it properly in the level, but I am still having trouble getting your macro working in my setup even though the sphere projection is 1 for 1 copied. I think I will just focus on trying to reverse the projection math for the collision sphere.
I think I am getting a better understanding of what is going on by looking at your working blueprint. I may just be out of my league on the math though. It has been 14 years since I have had formal math education… 
I am hoping it is as simple as flipping a couple signs somewhere in there. 
Took a moment to create a Shadow Map for Polar Wrapping. Fun, but it just doesn’t make any sense, visually or mechanically. Like having a mismatched equator of ice at the poles. 
I only know of a few practical options to make it happen.
One option would be to use an ice cap as seen in Civ4. Maybe the easiest option of the 2, but it is ugly, has an ice cap that is way too huge, and doesn’t let you really wrap the poles over that giant dome.
Another would be to use Goldberg Polyhedra which would require 12 pentagons in every map(whatever it’s size). I kind of cringe at the idea of including pentagons along side hexagons in all the neighbor checking functions… Really the whole offset system would have to be scrapped. I couldn’t even store the data in the arrays using the current method. Even if that transition were made, everything map related becomes more complicated to program for.
Another would be to stretch the tiles towards the pole, but that has all kinds of problems, visually and mechanically.
I really only have 2 minor problems with the current spherical hex map.
-
It is only a sphere visually when you are not hovering directly over the poles. The sphere kind of unfolds as you get to the poles. Not a huge problem, but could be immersion breaking.
-
Mechanically it is still a cylinder. I could just create individual North & South Pole tiles where all units go, and then allow them to traverse to any tile in the top/bottom most row of tiles from that point. Might work, but could still be a problem visually. This could basically work like Civ 4, minus the giant pole, and would actually allow you to traverse the pole. But then the tile would be strategically vital since it would allow units to seemingly teleport across halfway across the map. I could kill all pre-modern units with the cold, but then there are maps with hot polar regions to consider…
I don’t think there is an ideal solution, but we will see.
I have the collision sphere sized to the projection sphere and locked to the player position:
I tried some preliminary hit location conversions from the sphere surface to the plane using a basic stereographic projection, but it was returning nonsense.
Anyone know the technical term for this form of projection? Hard to research it when I don’t even know it’s name.
It took 13 years, but sleeping in math class is finally biting me in the ***.
Yea I was banging my head against it to. There’s some relationship between the original location and the projection, but I don’t know how to reverse it.
My next step was to attempt to visualize it then capture some data along one axis. But, I’m betting there’s someone out there with way better math skills that could handle it.
Yeah I have tried to reach out to the guy who posted the original projection link but he stopped replying last week. Maybe I will get lucky, but if not oh well.
I appreciate the help you have provided so far! Just looking at what you made in blueprint compared to the code snippet, I can see that it was a very small piece of code for the math. I was able to trim out a few bits(the IF statements), the redundant Sq roots, etc that make it easier to swallow. I am thinking I can just delete everything that goes into Z since we already know it will be 0.
As far as I can tell, this is all that is needed to provide the X/Y of the projection, so if I can just reverse this…
Lets try to compare some differences that we know:
Flat to Sphere
Z starts at 0. (so it actually doesn’t do anything when you add it to the Radius(for the flat vector, not the material math)… maybe we can just divide the Vector Length by the Radius)
Z becomes non-0.
Sphere to Flat
Z starts as non-0.
Z becomes 0.
So:
(2 - ((C+O (Vector Length)) / Radius)) x C+O
So I pulled an unfiltered hit location straight from the trace to the sphere and found that it was not producing the expected results. The difference between 1 tile and it’s neighbor is at least 3 times higher than it should be. The slope isn’t so great that moving 115UU to the right should produce a vector with an X that is instead 300-500 units higher.
So yeah, I will be working that out prior to tinkering with the formula.
I partially fixed the trace hits on the sphere. It wasn’t actually striking the sphere but stuff behind it.
Ok, I got some things with collision and sphere trace measurement worked out. I will be out tomorrow, but got a 4 day weekend coming up so hopefully I can crack this code that has been vexing me. 
I spent all day(in addition to the past couple weeks) sitting here banging my head on the keyboard, and then it all came together as if by magic. And funnily enough, Van Halen’s “Right Now” followed by Whitesnake’s “Here I go Again” played just as I worked it out.
I pretty much gave up on trying to understand and reverse the projection. I instead tried to take the vectors I was witnessing in game from clicking on the sphere, and line them up with what they actually should be on the flat map. So, as it turns out, when tile (0x, 0y, z) matches the offset location, then the x,y hit location is the same as the flat map location multiplied by 2. As you move the offset off 0,0 things start to get out of whack. So, I found that you can take the hit location, add the offset to it, and then divide by 2, and you have the corresponding vector on the flat map. Took me weeks to figure out 6 nodes worth of code… -_- lol
Now I need to snap the hit location to the nearest tile vector and I will be back in business!
One other thing I have been pondering is how to deal with units. They will have a similar projection/collision problem, but it will be harder to use the sphere for their interaction. I can either move them around on top of the projection, or project them like the tiles and fake their collision. Faking their collision seems like the easier of the 2 options, but I am not sure how I will account for a unit’s height when a player is trying to click-select it. If the material could project collision as well as rendering info that would be amazing.
Good to know you got it working!
Snapping to the nearest tile vector is easy now that you’ve got access to the corresponding vectors on the flat map. Just divide the hit X location by the width of your tiles and add the hit Y location divided by the length of your tiles times the width of your array to get the appropriate array index and just get that vector from the vector array. Also subtract the location of the grid from the hit result if index 0 is not on worl location 0,0,0.
I also think faking collision seems like the better option. I don’t think you’d have to account for the height of a unit. At least in Civ I don’t think units are selected by clicking on the mesh of the unit, but rather the tile beneath it.
Unfortunately I don’t think that will account for the offset in all cases. Sounds like that would work for square grids, but in a hex grid you could click in a corner of one hex and end up getting the neighbor instead.
I will probably re-purpose the collision volumes and use the vector to trace down to the nearest volume and pull the index. That is basically how I did it before anyway.
I think you may be right about clicking the unit. One of these days I will have to refresh my memory on some of those little nuances.
Sorry to hear you’re having trouble with the math side on this but the end result is gonna be AMAZING.
For some reason I forgot you were using hex grids for a second No matter. I’ve done the exact same thing with hex grids in my system. The math is a tad more complex, but it works perfectly. I can send you the appropriate blueprint snippet tonight if you’re interested.
Thanks! The hardest part is past I think(hope? :p), so the rest should be pretty straightforward. Looking forward to getting back to the actual generation. Need to wrap a few things up and then refactor the whole thing.
I kind of really want to wrap the poles, though the options are fairly limited, especially without an essentially impossible redesign of the generator.
Here is a pic of how polar wrapping looks with a rectangle/cylinder map instead of an actual sphere:
As you can see, it is essentially polar wrapped, but obviously it looks and acts almost nothing like a normal pole. But then, neither does a rectangular flat map. At least with this setup, as ugly as it is, you would be able to traverse the poles. Though it could get confusing when people scroll over the pole and find the world effectively upside down…
Actually, if players don’t have ice in their map they might not even be able to tell the difference. Even with ice, they won’t even be able to see how ugly it looks until well into the end game.
And here is how the tiles are laid out by index:
The math to get polar wrapping working with the rest of the generation algorithms should be pretty easy. Perhaps a bit tedious to update all the systems.
Of course, with polar wrapping I would then need to have even more shadow maps. It wouldn’t be a problem right now(apart from the forests which are on the chopping block), but it could really start to tax the system when improvements, units, etc are added into the mix. I have an idea for dynamic movement/spawning of tiles around the player that should be manageable, especially with the world in sphere mode.
Anyway, what do you guys think about polar wrapping? Ugly, but too useful to pass up?