Honey 2 mesh as data source
Dec 27, 2014 13:31:51 GMT
Post by khash on Dec 27, 2014 13:31:51 GMT
(from previous forum: forum.unity3d.com/threads/honey-hex-framework.265154/page-4#post-1887795)
Lennartos said:
I have looked at the shader and its pretty much as simple as can be - nothing fancy there.
The performance seems to suffer from the HEX coordinate system conversions and not the "work" itself.
Im not strong enough in the hex math to see any better method to reduce direct instructions. ( what i found on google was similar as you used here ), and dividing the work up into seperate render passes again imposes unity PRO version... So i think we just have to accept it as it is.
On the good side, after i fixed the HexGrid - i had a 300K hex grid visible with 3ms render time.
We should have switched LOD long before that, so i dont think that the shader performance really is a issue.
Edit:
Could one use the vetexes as a data as a container for hex data?
For example If the mesh would follow hex design, then a simple methods like UV can be used to tell distance from center and which axis is more powerful - no hard math needed.
Answer:
Idea of honey 2 is that data related to the world would be dynamically created.
If you will be willing to have mesh rigged to shape of hexes you will be forced to have mesh for whole world of yours. Huge world like 300k hexes would consume a lot of memory and partially kill the idea which lead us to this solution in the first place.
I do not oppose usage of mesh all together because I think I should be able to achieve even nicer world if I would use pool of meshes for hexes (so that mesh does not follow square shapes as they do at the moment but rather circular which would hide many mesh artifacts you can see especially around the river borders in non tessellated worlds.
The difference is that if I use pool of meshes I do not have data in this mesh for a specific hex, because if you scroll the same mesh would be used for different locations and instead of reuse would have to be recreated and pushed to gpu again.
Lennartos said:
I have looked at the shader and its pretty much as simple as can be - nothing fancy there.
The performance seems to suffer from the HEX coordinate system conversions and not the "work" itself.
Im not strong enough in the hex math to see any better method to reduce direct instructions. ( what i found on google was similar as you used here ), and dividing the work up into seperate render passes again imposes unity PRO version... So i think we just have to accept it as it is.
On the good side, after i fixed the HexGrid - i had a 300K hex grid visible with 3ms render time.
We should have switched LOD long before that, so i dont think that the shader performance really is a issue.
Edit:
Could one use the vetexes as a data as a container for hex data?
For example If the mesh would follow hex design, then a simple methods like UV can be used to tell distance from center and which axis is more powerful - no hard math needed.
Answer:
Idea of honey 2 is that data related to the world would be dynamically created.
If you will be willing to have mesh rigged to shape of hexes you will be forced to have mesh for whole world of yours. Huge world like 300k hexes would consume a lot of memory and partially kill the idea which lead us to this solution in the first place.
I do not oppose usage of mesh all together because I think I should be able to achieve even nicer world if I would use pool of meshes for hexes (so that mesh does not follow square shapes as they do at the moment but rather circular which would hide many mesh artifacts you can see especially around the river borders in non tessellated worlds.
The difference is that if I use pool of meshes I do not have data in this mesh for a specific hex, because if you scroll the same mesh would be used for different locations and instead of reuse would have to be recreated and pushed to gpu again.
)