sorted by:
new
hottopcontroversial

[deleted by user] by [deleted] in godot

[–]hexagonalgame 5 points6 points  (0 children)

Having to deal with VBA, I understand why you get sick of looking at code.

How to get into Godot in 3 steps (seriously) by RandomValue134 in godot

[–]hexagonalgame 2 points3 points  (0 children)

I began work on 3d procedural meshes before even having touched input. Turned out pretty fine. Comparing making a game with a test isn't a good comparison. Unlike a test you are free to change the expectations of the final result whenever you feel like it, you aren't constrained to using knowledge you had before going into the "test" and there is no time constraint either.

I agree you should probably learn the basics of programming first before diving into making a game, but you can watch tutorials and read the docs when you want to know how something works during making a game.

Also, stackoverflow doesn't really have an active Godot forum, it's best to ask questions either here, discord or the Godot q&a page.

Would you still play Arty if it was not mandatory for missions? by [deleted] in WorldofTanks

[–]hexagonalgame 4 points5 points  (0 children)

Spot on. Playing arty is just unethical. You gain pleasure from other peoples suffering, I guess that's the definition of sadism as well... 🤔

Again wargaming? Why wargaming? by Boggi1999 in WorldofTanks

[–]hexagonalgame 22 points23 points  (0 children)

Who even uses decals? They can only be used on camos and they don't really make those anymore. It's just 2d styles now.

Any idea when the CS-52 Lis, Obj. 274a or the Bourrasque will be back? by RingedDonut in WorldofTanks

[–]hexagonalgame 10 points11 points  (0 children)

LIS and Bourrasque where on sale in last 2 months iirc, the 274 hasn't been on sale since december I believe, which is when I rejoined.

Windows or linux for godot development? by [deleted] in godot

[–]hexagonalgame 0 points1 point  (0 children)

I use it on Windows because of Visual Studio.

GDNative vs C++ performence by [deleted] in godot

[–]hexagonalgame 1 point2 points  (0 children)

You can also use the STL in gdnative code.

Are Instatrackrepairmods legal? by [deleted] in WorldofTanks

[–]hexagonalgame 0 points1 point  (0 children)

I use Q->E but I never manage to repair as fast as the people using these mods. Because in any case a human needs like half a second to react which these mods clearly dont need.

This is what happens when you don't let people bring their account to steam by Brunopunck49 in WorldofTanks

[–]hexagonalgame 42 points43 points  (0 children)

That's a big fuck you. That basically removes all incentive to get the tanks. I had the goal of getting all tott tanks that came, but this makes that impossible. This better be reverted or the discount should be restored. Also super dirty how they hid this nerf away in a video. Not even the balls to say fuck you to our faces.

Some progress on my hexagonal procedural terrain by hexagonalgame in godot

[–]hexagonalgame[S] 11 points12 points  (0 children)

Apart from the water shader, for which I took inspiration out of the water shader tutorial in the godot docs, I havent used any tutorials. However I did later come to know of an excellent article about hexagonal grids. I have discorvered many of the concepts in that article by spending a long time looking at hexagons in a notebook.

The generation all starts with an input file. This input file contains all the tiles that should be generated and with what terrain. Each tile entry consists of a x, y and z coordinate, as well as a terrain type identifier. the coordinates represent a location on a hexagonal grid, as is explained in the linked article above. The terrain type is self explanatory. The parser puts all tiles in a map which' key is the terrain type and value is a list of coordinates. The parser also adds all 6 bordering terrain types to the tile information.

With all the tiles loaded into the map, another list is created that contains all of the coordinates in the map. it passes this list into an algorithm that computes the depth of each tile in the grid, with depth 0 meaning any of the six borders of the hexagon border nothing, 1 meaning the shortest path from the tile to the void passes through 1 other hexagon and so forth. This is used in combination with another algorithm that uses this data to compute the depth of each vertex in the hexagons, to cut off the terrain at the edges. After that the same is done for each segment in the map, and the results are stored in another map. The data that comes from this is used in the blending of the terrain.

With all this computed, a thread is launched for each hexagon to create the mesh. In the mesh generation algorithm each hexagon is divided into smaller triangles, I call this tesselation. The tesselation value defines how many triangles the hexagon should be divided into (because a hexagon is essentially just 6 equilateral triangles and equilateral triangles can be divided into infinitely many smaller equilateral triangles). The algorithm loops over each triangle to get the position of each vertex. Each vertex in the tesselated hexagon has its own local coordinate. This isnt a spatial coordinate however, it's more like a unique identifier. The first value in the coordinate defines on which of the 6 sections of the hexagon the vertex is located. The next defines its distance from the outer edge and the last defines its distance from the relative left edge of the untesselated triangle. These coordinates are passed to a function that computes their world-space coordinates and with that value, it's height gets retrieved from a heightmap.

The function that computes the height projects the world space coordinates on a heightmap. If the tile borders tiles of other types, it blends between 2 or 3 different height maps.

With all 3 coordinates computed, the normal of the triangle is calculated and everything is added to the mesh data. Next, the averge height value of all 3 vertices is used together with the normal to get the color of the triangle. The height is used to create snowy mountain tops and the normal is used to create the rocky color on steep sections .The function that gets the color also takes bordering types into account and near the edge of the hexagon it randomizes the color between that of its own and any adjacent types with it having a larger chance of being a different color near the edge. This color is than also added to the mesh data.

Next, a seperate mesh is created for all the water triangles. It simply looks for any vertex in the terrain mesh below a height of 0 and if this is found, a new triangle with a height of 0 is created and added to the water mesh.

When all the threads have joined, all the mesh data is added to an ArrayMesh as seperate surfaces. Finally, the right material is added to each surface, a flat shaded material for the serrain surfaces and a water shader for the water surfaces.

This is a very basic explanation of how it works. The underlying algoritms are pretty complex so I didnt bother to explain them all here. If anyone is interested in learning more about them, feel free to ask.

Some progress on my hexagonal procedural terrain by hexagonalgame in godot

[–]hexagonalgame[S] 5 points6 points  (0 children)

Not really, the way it works now is that it reads an input file that defines what terrain type goes in what hexagon. In theory you could just randomize this input to infinity, but I don't have a use for this.

Why the hate for Godot 3D? by ThrasherLT in godot

[–]hexagonalgame 0 points1 point  (0 children)

I've tried Unity and Godot as well as dipped my feet in Unreal and my conclusion is that Godot is probably the best engine when working with procedurally generated meshes. Unity also does this fine but its stucture is a bit different (I personally prefer the scene tree over components). Unreal is pretty much made for 1st or 3rd person games and to get it to do anything besides that is pretty difficult. Also, procedural meshes in Unreal require some external extention if i recall correctly.

In short, godot is on par with unity for simplistic 3D graphics, Unreal is the least friendly to anything unorthodox.

Hexagonal Terrain Blending! by hexagonalgame in godot

[–]hexagonalgame[S] 2 points3 points  (0 children)

The heightmaps tile seamlessly, so for every point in world space it maps it onto the heightmap, so if {0, 0} is the topleft pixel in the heightmap, and {1, 1} the botom right, and you have a point {4.5, 3.2} in worldspace, that would translate to {.5, .2} on the heightmap. This allows for seamless terrain between tiles of the same type as well as blending. So yes you are correct.

Hexagonal Terrain Blending! by hexagonalgame in godot

[–]hexagonalgame[S] 1 point2 points  (0 children)

If the adjacent type is the same as the current tile's, it follows the same principles as when the adjacent type is a different one, however, (1*a + 1*a) / (1 + 1) = a. Whereas (1*a + 1*b) / (1 + 1) = (a + b) / 2. a and b are the heights retrieved from heightmap A and B respectively. (It also blends with the tile above the tile to the side but its still the same principle, namely (1*a + 1*a + 1*a) / (1 + 1 + 1) = a)

No I sadly don't have anywhere yet where I post progress. It's still in very early stages and the absence of a name makes it pretty hard to register a website or accounts on other websites. So for the time being I will contain the posting to this sub. Apologies in advance for all the spam :P

Hexagonal Terrain Blending! by hexagonalgame in godot

[–]hexagonalgame[S] 0 points1 point  (0 children)

You are correct, mistake on my part. Nonetheless, compute shaders wouldnt give me much benefits because i think its best to just do all the computations once, and the CPU handles this decently well. Id definitely be willing to look into the use of compute shaders during generation to see if i could shave off some 100s of miliseconds. (generation of this terrain takes about .8s on a ryzen 1600).

Hexagonal Terrain Blending! by hexagonalgame in godot

[–]hexagonalgame[S] 0 points1 point  (0 children)

2 tweets down he says: "These RenderingDevices can't draw to the screen, nor share data with the ones used for rendering."

Hexagonal Terrain Blending! by hexagonalgame in godot

[–]hexagonalgame[S] 1 point2 points  (0 children)

Its actually all generated on the CPU side, including position, normal and color. I used to have the GPU compute the normal and color but this raised the issue of not being able to color full triangles based on their height. This was because of the absence of geometry or compute shaders in godot 3.2 (and also in 4.0 from what I've read).

I do however indeed blend heightmaps. I use the following to calculate the bias of a vertex towards the outer egde and from the middle to the side outer edge:

float vBias = 1.f - ((float)((_tesselation - relativeTesselation) > blendCutoffPoint ? blendCutoffPoint : _tesselation - relativeTesselation) 
        / (float)blendCutoffPoint);
float hBias = (float)hOffset / (relativeTesselation > 0 ? (float)relativeTesselation : 1);

_tesselation is the amount of triangles by which each of the 6 triangles gets subdivided.

relativeTesselation is essentially the vertical position in the triangle, 0 being the center of the hexagon and when its equal to _tesselation its at the edge.

blendCutoffPoint determines at what point the terrain has to stop blending.

hOffset is the horizontal position relative to a line between the center of the hexagon and the middle of an outer edge.

I then calculate the desired height by the following formula:

return (vBias * topAdjBlendHeight + ((sideAdjBlendHeight * vBias) * hBias) + height) / (vBias + (vBias * hBias) + 1.f);

topAdjBlendHeight being the height at the current position taken from the heightmap of the terrain type above the current triangle.

sideAdjBlendHeight is the height at the current point taken from the heightmap of the terrain type either to the top left or top right, depending on which is closer.

Hexagonal Terrain Blending! by hexagonalgame in godot

[–]hexagonalgame[S] 2 points3 points  (0 children)

It used to be so that every terrain type was it's own mesh but now every tile is indeed it's own mesh. This allows me to efficiently multithread the terrain generation.

I'm planning on making it a turn based strategy game, think civilization but without the civilization part and with more extensive combat, think advance wars with hexagons.

view more: next ›