[Edited by - Dragun on May 22, 2005 3:52:05 PM]
3D rendered Hexes...what's the best approach?
Author
Call me crazy, but I'm trying to create an 3D engine with rolling terrain via Hex tiles. Inspiration came from 'Dai Senryaku VII' on the Xbox. The only thing I hated about the game is the 'stacked' hexes for hills when they clearly should have done a rolling terrain of some sort.
I've figured out how to texture map onto a hex using triangle strips but now I'm stuck on how to actually create the rendering loop for the map. I thought about doing it 2D style where I would write a function to individually render each tile at a time but that was horrendously slow. Anybody have any ideas? Any suggestions would be appreciated.
To get what I'm trying to accomplish, the following pcitures are Dai Senryaku (the inspiration), the hex grid system that I'm using for the terrain height (yes, lots of wasted space), and the rendering of my single hex so far (yes, four triangles make a hex).
[Edited by - Dragun on May 22, 2005 3:52:05 PM]
[Edited by - Dragun on May 22, 2005 3:52:05 PM]
I think it would be better to use 6 tris per hex. Like this:
The point in the middle of the hex would make it a lot easier to making it rounded, rather than flat-topped like in Dai Senryaku. To make it even more round you could tesselate the triangles (split the triangles into 4 equal, smaller trianges).
With the 6 tri hex I showed above, all lines are the same length (all angles in the triangle are 60 degrees)
__ /\ /\ /__\/__\ \ /\ / \/__\/ The point in the middle of the hex would make it a lot easier to making it rounded, rather than flat-topped like in Dai Senryaku. To make it even more round you could tesselate the triangles (split the triangles into 4 equal, smaller trianges).
With the 6 tri hex I showed above, all lines are the same length (all angles in the triangle are 60 degrees)
Author
Currently it's at:
With each hex tile following it's own slope (the four tiles will have the same slope), I don't think adding a pivotal point in the middle would do anything besides increase the vertices being rendered. But I could be wrong...
Oh, and any ideas for a map?
Damn, this forum blows on formatting.
[Edited by - Dragun on May 10, 2005 2:01:57 AM]
...________../|...../|./.|..../.|./..|.../..|..\..|../...|../.\.|./....|./..\|/_____|/With each hex tile following it's own slope (the four tiles will have the same slope), I don't think adding a pivotal point in the middle would do anything besides increase the vertices being rendered. But I could be wrong...
Oh, and any ideas for a map?
Damn, this forum blows on formatting.
[Edited by - Dragun on May 10, 2005 2:01:57 AM]
Quote:Original post by Dragun
Hey Frostburn, with your idea I can do triangle fans...good point.
True, but I'm not sure how much you gain vs indexed triangles or tri-strip. The 6 verts around the edge is shared with 2 neighboring hexes, and would have to be stored again for them.
I didn't know each hex was just a slope, so in that case doing it the way I described might be a bit of a waste. I thought that the hexes was supposed to be non-planar, in which case that middle point would be very handy.
If I was the one making it I would use the 6 triange approach even if there's no other reason than that the tringles would be more "ordered" in my head (or on a wireframe display).
Note about the messed up ascii art: If the last character of the line is '\' it won't work as it and the following line break gets stripped. I fixed it by simply putting a space behind it ("\ ").
I don´t know how many tiles you will have, but I´d prefer the 4 triangle/hex approach you posted. Simply less vertices to save and less primitives to draw.
And I would use an index buffer for it.
But if you want something like a hex with a hill on it,like frostburn posted you would definitely need his approach.
And I would use an index buffer for it.
But if you want something like a hex with a hill on it,like frostburn posted you would definitely need his approach.
Author
Here's an update on what I have going. So far the map is hardcoded and rendered with a vertex and index buffer. I haven't figured out how to texture map it so far...Also I plan to replace the hardcoding of the vertex with an algorithmn...
[Edited by - Dragun on May 22, 2005 3:50:32 PM]
[Edited by - Dragun on May 22, 2005 3:50:32 PM]
Author
Hey fellas, just wanted to let you guys no I hammered down the vertice and index buffer routine so I can now generate the basic maps on the fly (I throw in '4' and it creates a 4x4 hex map).
This is a 64x64 hex map with a funky rotation loop
[Edited by - Dragun on May 22, 2005 5:54:11 PM]
This is a 64x64 hex map with a funky rotation loop
[Edited by - Dragun on May 22, 2005 5:54:11 PM]
If i'm reading your map correctly, couldn't you cut out the two wasted points in the middle of each hex and index into the map data as if the hexes were really six point rectangles?
And if you are always dealing with square maps, with a bit of math majic you could store the points for each row sequentially, (i.e. not in a square 2D array like you are now) and determine the correct index into the 1D array for each row and hex from there. You actually already have the hex points numbered with the corresponding indicies.
large 2D array = 255 points
smaller 1D array = 47 points
for the map above.
Just an idea.
~Chris
And if you are always dealing with square maps, with a bit of math majic you could store the points for each row sequentially, (i.e. not in a square 2D array like you are now) and determine the correct index into the 1D array for each row and hex from there. You actually already have the hex points numbered with the corresponding indicies.
large 2D array = 255 points
smaller 1D array = 47 points
for the map above.
Just an idea.
~Chris
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
