|
|
Post by swatter on May 29, 2015 8:33:53 GMT
I am finally digging into Honey after much work on other aspects of my project. My first task was to integrate my map data into Honey, which was easy where I could align my data to Honey hex definitions. However, it is not so easy with rivers, but I am not crossing that bridge yet (programmer puns are terrible).
To the meat of my post: I looked over HexMarkers and with effort I think I figured out what is going on. You save all marker data (type, location, and rotation) in a texture with different layers corresponding to the r, g, b, and a channels on the texture (so you can have multiple markers in one hex). If I understand this correctly, all markers must be stored (without changing code in other files) on one atlas and you only have 4 layers to work with. The textureMapSize is the total number of sprites/images on the atlas and dataSize is 2 because you need to store type and rotation. Is that about right?
My experience in Unity is limited, so it is making Honey rather rough to pick up. Your a better coder than I am and you are making me read your mind to some degree because your commenting is sparse. Some explanation commenting would go a long way  Anyway, all that means is I'll be in here asking questions more.
What exactly would I need to do to make the marker system a bit more flexible? I have never written a shader and frankly I don't know what all scripts use the HexMarkers singleton. I am starting to understand how Honey works, but I have a long ways to go.
|
|
|
|
Post by khash on May 29, 2015 10:12:34 GMT
textureMapSize works togehter with dataSize. Resulting texture contains data for each hex on your world. Each hex get "dataSize" width and height in pixels for its data. Each hex have unique saving position thanks to the usage of X, Y coordinates (ignoring Z as its redundant). Then result coordinates are multiplied by dataSize which allows us to store 4 pixels (4x4 floating point values) for each hex if the dataSize is = 2.
this allows us to store in first pixel 4 indexes of the markers to be used in this hex, and we still have 12 floating point values which allows us to store other data like rotation, you may change this system easily to store there for example as well color and then use this to multiply color of the marker for each layer of each single hex independently (eg coloring borders, terrain ownership etc)
This data is then used to lookup another marker texture where you have stored visual representation of the markers and together allows you to draw markers with such precision and quality in the world.
This system is fairly flexible and you have a lot of memory space there, you just need to ensure you make textureMapSize bigger if your world hex radius is bigger than textureMapSize/2 (radius makes hex to go positive and negative while texture wraps coordinates to have all negative data moved to the other end of the positive coordinates in the texture) I need to think of making this bit a bit more automatic in the future
HexMarkers.instance is used instead of storing locally instance of it somewhere because it makes no sense to have more than one of it at a time, as its linked heavily with world rendering (it feeds world shader with marker texture)
|
|
|
|
Post by swatter on May 29, 2015 20:23:50 GMT
I believe I understand.
Couldn't you just set the textureMapSize = mapRadius * 2?
Anyway, I believe I will need more than 4 layers for markers. Looking at the TerrainDX11Markers shader, it looks like it wouldn't be too difficult to use another pixel worth of data to store 4 more layers. Am I looking at that correctly?
|
|
|
|
Post by khash on May 30, 2015 0:53:01 GMT
yes you may add another 4 layers mostly by duplicating what is there now in pixel shader and reading data for it from another pixel.  Because we have 4 pixels of data for each hex it should be straight forward. |
|
|
|
Post by swatter on Jun 1, 2015 20:48:21 GMT
I made some changes to HexMarkers and everything went well, but this is one problem. I noticed that all markers when rendered on the map tend warp or pull towards the camera. If you have a marker in the center is renders without distortion, but if you have markers on the four corners of the screen, the will all warp towards the center slightly causing blur and pulling the texture off center. How would I correct this to where there is no distortion no matter where the marker is on the screen? Is it that the marker is bill boarding trying to always face the camera?
|
|
|
|
Post by khash on Jun 2, 2015 8:18:26 GMT
Marker system is fairly complex math calculations based on the position of the pixel in the world and then conversion of it into hexagonal ownership. I think some of the values you receive are inacurate and may easily lead to bad render. There is no planes for the markers to get billboard (its rendered into terrain texture)
|
|
|
|
Post by swatter on Jun 2, 2015 14:20:44 GMT
"I think some of the values you receive are inacurate and may easily lead to bad render"
I am not sure how this answer provides clarification or some suggestion of how to fix it. I am simply using the marker system provided in the framework and it pretty badly distorts complex textures it renders. That severely limits the usefulness of the marker system.
|
|
|
|
Post by khash on Jun 2, 2015 18:13:48 GMT
I thought you have switched to ortographic camera which lead to this. If not then can you drop some screenshots with what you get maybe it would help to findout what is wrong? and this ortograhinc camera topic was somewhere else, sorry for that I'm a bit messed up by the number of tasks and it lead to this misread ;P
|
|
|
|
Post by swatter on Jun 2, 2015 23:26:37 GMT
It wasn't me that changed the camera, but that is the answer.
The reason the markers are distorting is simply due to the perspective camera, I suppose its the intended functionality. After some testing, I switched the camera to orthographic which clearly displayed the markers at all angles and distances. Of course, changing the camera has other issues, as you have pointed out.
So, in short, the problem is the markers are rendered to the perspective camera, which causes the distortion. As long as the marker textures aren't super detailed, the distortion is hardly noticeable. I will need to write some system that allows me to render highly detailed markers.
|
|
Anyway, all that means is I'll be in here asking questions more.
Because we have 4 pixels of data for each hex it should be straight forward.