|
Post by manthril on Oct 5, 2016 12:27:29 GMT
Hello there!
I successfully managed to integrate Honey Hex in my project and created a nice terrain of my own (without rivers and markers, as I have not yet completely understood the code behind these).
I have one question though, and I would appreciate if you can guide me with this one. I don't quite understand the importance of the orderPosition variable from Hex. I see that when I change that the chunks do not blend well together. But that variable is set random when the hexes are being created.
Can someone explain the exact purpose of the variable, and perhaps why it is necessary?
Thanks in advance!
|
|
|
Post by khash on Oct 5, 2016 13:11:18 GMT
This sets priority for each hex, that way some of your hills will dominate neighbours while others will get consumed by them. A single hex have 6 neighbours therefore you can order the same set of terrains in many ways creatng more natural feel. For example your mountain can dominate north and south and be pushed down from sides and this factor only reshapes the final result. It works along mixer and distance from center, where mixer allows you to specify very terrain specific features and their importance, distance ensures the blend is smoother, and order allows for blend to be processed in different order giving different results and yes, rivers and markers is a lot of fun too. I can imagine hard time it gives for not-insane people reading this code XD But I hope you will get a lot of value from it
|
|
|
Post by manthril on Oct 5, 2016 13:14:53 GMT
Thanks for the quick reply! The code is actually quite easy to understand. The principles behind it, not so easy, for a beginner in graphics. This is really a great and optimized engine for generating terrain!
|
|
|
Post by khash on Oct 5, 2016 15:10:32 GMT
Yes, it is complex, its packed with tricks which uses strengths and weaknesses of the rendering pipeline to its advantage. World generation and memory footprints are the worst problems Honey 1 had. My current work on Honey 2 gave me way better results in those two fields. It follows similar principles and knowledge from Honey 1 is about 90% of understanding how Honey 2 works but still memory and generation are out of compare
|
|
|
Post by manthril on Oct 6, 2016 7:39:44 GMT
Awesome! Any ETA for Honey Hex 2?
And I also have one question. I don't quite understand how are the shadows calculated, giving the two height off set textures. Do you mind explaining this?
And is there any reason why you chose rendering to chunks, instead of hexes or a big chunk containing all of them?
LE: I have also noticed that you are using sharedMesh instead of mesh. Any reason for that?
Thanks!
|
|
|
Post by khash on Oct 6, 2016 16:02:56 GMT
I have no eta for H2 because it will depend on time required to polish it to get it to the public. You can be surprised how much hate developer gets for product which is not polished to final state, and in Honey 1 I spend 5 times more polishing and documenting than developing system so as you can imagine taht this will take fair number of months (simply bcause I have do my regular work first) Shadows are one of the tricks I have mentioned in my previous posts they are calculated by taking into the account two offset heights: --------/\/\ -------/=/\=\ ------/=/==\=\ -----/=/====\=\ ----/=/++++++\=\---- now imagine that right mountain is true height, while left mountain is offset height. If you compare them you get something like: 0000SSSSS0LLLLL0000 0 - normal lighting S - shadows L - extra light and then you need to tune-down a bit extra lighting as it sometimes overburns the result, but you should get the idea Notice now that if you edit: Sorry my image above get destroyed completely by formatting... I tried to fix it by filling it with horizontal lines etc but with no success. Just imagine two mountains which share most of the area (small offset) I hope it helps if not I will try explain differently As for rendering... there are many many reasons why its rendering that way, but it ensup in one point: blending hexes textures and features. And single huge texture will not be enough detailed for visual part. LE: no specific reason I could recal for shared mesh, I dont think it matters anyway in grand scale of things.
|
|
|
Post by manthril on Oct 7, 2016 11:21:09 GMT
Hi there!
Thanks for the explanation, it makes more sense now. I still have to do some research since I just started to learn about rendering. I am currently working on refactoring some of the Honey Hex code so it fits better into my project. I learned a lot from your framework.
Good work!
|
|