Sign in to follow this  
Mephs

ArenaWars Terrain Texturing

Recommended Posts

Hey all, If anyone has ever played ArenaWars and loved the look of the terrain, I think I've worked out almost exactly how they did it. I've implemented very similar methods into my own engine and I must say, for the first time, this is the one terrain texturing system that I am 100% happy with. It's very fast, looks stunning and allows for an almost unlimited number of terrain textures. It also has a system that works similar to decals for rendering things like direction arrows onto the terrain. Now I'm sure this is no major breakthrough, but I was quite impressed that I managed to work out a system of terrain texturing that does not seem to be documented anywhere online, which is odd when it works so well :). To see some screenies of Arena Wars, look here Arena Wars Screenies If anyone is interested in a summary of the technique, then just reply and I'll detail the technique here (haven't bothered to post it until I know there is some interest). Cheers, Steve

Share this post


Link to post
Share on other sites
Okay, I'm at work at the moment, but I'll look into writing up a mini article and posting it in this thread. I'll do this in my lunch break, but if the article goes on too long, I'll continue it at home and post it from there.

Please bear in mind that I wont go into huge detail as I'm still avidly working on my own engine (never enough time!!), but I'll give enough info to get people started and try to answer any questions that may arise.

Look out for an update within the next 48 hours!

Thanks,

Steve

PS I have already started writing it, so fingers crossed it will be soon

Share this post


Link to post
Share on other sites
Hey, I'm the programmer of Arena Wars, you can ask me any question in the Arena Wars boards and I will be happy to answer :)
http://arenawars.krawall.de/com/phpBB2/viewforum.php?f=7

Share this post


Link to post
Share on other sites
Hey :) Thanks for a great game by the way, and now I'm sure you'll be able to point out holes in my translation of your technique!!

Actually, I'd be interested in running the article by you if you have time to look at it, perhaps then I can improve my own method if I have anything incorrect!? Also, I guess I should ask if you mind me putting this info out?!

Thanks,

Steve

Share this post


Link to post
Share on other sites
Yeah sure, I will be happy to help. And no problem putting this info out, there are a lot of engines using the exact same stuff. Sure each engine has its own features, but its not rocket science imo.

Share this post


Link to post
Share on other sites
Okay, I've done this in my lunch hour..... it's FAR from complete but bear in mind I've only spent about half an hour on it so far, but it's something to get your teeth into if you're eager to work on something similar until I get the final thing complete and checked through/rewritten!!!

............

The texturing is done using a 2 texture stage, multipass system. The first texture stage is an alpha texture, and the second stage is the desired terrain texture.

Terrain organisation is not important to this method, but I use the method that I prefer, which is to have chunks of 33x33 vertices. I will not go into how to organise your terrain structures etc, as this is covered in many places online and is not really a difficult subject.

Your chunk structure should contain a list of quad structures representing the quads formed inside your chunk. The quad structures should contain (among other possible variables) a list of 4 texture indices. Each texture index corresponds to a vertex of the quad, so you could even store the index inside the vertex information if you keep a copy or a pointer to it in the quad structure, however this would not work well with feeding the vertices into the rendering system, as this information is only need for determining transitions, so I prefer to keep the texture indices separate from the vertex information.

Every chunk structure holds an array of a class I call cTileManager. The array is equal in size to the number of textures used in the editor. Each element of the array is a separate cTileManager class which deals with the tiles (and transitions) for the corresponding texture. The cTileManager class performs a variety of functions. It contains two other classes of my own devising which dynamically create and destroy vertex and index buffers and populate them with the necessary information. I’ll leave this to you guys to implement your own version, but may be tempted to go into further depth if required. To sum up, the tilemanager class creates a vertex and index buffer and stores the relevant information (number of vertices/indices/primitives/etc).

I’ll now go into some more depth about how the whole system works. When texture indices are updated, we scan through the adjacent quads and find out what kind of tile or transition is needed at that quad. If a 100% alpha tile is needed, we tell the tilemanager class to add the vertices and indices for that quad. If a transition is needed, we tell the tilemanager for the relevant texture to add the vertices of the quad into a linked list (or a vector in my case as I find it quicker to implement). Transitions work a little differently to 100% alpha tiles though, rather than using a list of indexed vertices, we store precisely 4 vertices for every quad added. That is to say that transition quads do not share any vertices, because we need to assign a unique texture coordinate for every vertex dependant upon the transition, and shared vertices will not allow us to do this.

I should mention the alpha texture at this point. It is based entirely upon one texture. I have nowhere to host images at the moment so I’ll have to describe it. This alpha texture contains alpha masks for 3 types of blends. It has an alpha mask for an edge transition, a corner transition and an enclosed corner transition.

When we paint a given texture onto the terrain, we are in fact simply altering the texture indices in the quad structures. You need to implement in your level editor a function to determine which quad your mouse is currently intersecting, and update the top left texture index (textureIndex[0] in my case as 0 is the upper left element of the array, 1 is the upper right, 2 is lower left and 3 is lower right). Whenever you update a texture index you must rebuild the transitions and tiles on the quads adjacent to the quad you are editing. To do this we evaluate the quads one quad at a time (it will be handy to calculate and store pointers in quads to tell them which 8 quads are adjacent to it). When evaluating a quad, we loop through all available texture numbers and check if any of the texture indices for that quad match the texture number. If we find a match for the texture on all 4 indices, then we know that the quad is completely enclosed, so we add a tile (100% alpha quad, ie no alpha map). If texture index 0 matches (upper left) then we add a transition, telling the tile manager class to give the vertices the correct texture coordinates such that we pick the appropriate corner transition. Remember though that we must ensure that only one transition is applied to a quad at any one time, so you must test for these transitions in a certain sequence, or you will go through and test your indices, and a case where all 4 indices are the same texture will be interpreted as a tile, 4 corner transitions, 4 edge transitions and 2 diagonal transitions, when all we wanted to add was the 100% alpha tile.

Transitions of the same texture override one another, so you must delete underlying transitions if a new one is to be placed as a result of changes, but transitions do not overwrite tiles. Tiles overwrite other tiles, so if you enclose a quad in a grass texture, the middle existing tile will be removed and a grass tile put down in its place.

We then go through and render tiles and transitions separately. We render tiles as purely the texture on its’ own, we render transitions with the additional alpha mask to blend them into the tiles. This then ensures that we only use alpha blending on areas that actually need it (transitions) so we cut down on fillrate IIRC, rather than splatting which alpha blends the entire terrain and in my own experience runs rather slowly when a large number of transitions are in view, even on high end hardware.




Hope this helps for the time being,

Cheers,

Steve

Share this post


Link to post
Share on other sites
heh, thanks for posting that link, but take a look at the original posters username ;) heh.... it's somewhat of a longstanding favourite subject of mine.

Cheers,

Steve

Share this post


Link to post
Share on other sites
Okay, I've not had as much time today to be able to go through and update what I've written so far. So what I'll suggest is the following...

If anyone is interested in what has been written so far, but still has question regarding implementation of anything specific, just post what you'd like help with and I'll do my best to answer. That way, anyone who wants to have a go implementing it can do, and with my limited time, I can still be of use. In answering the questions, I will also update my document, and once I feel everyone has had any questions answered that they need answering, I'll publish a final document with a little more polish!

Hope that sounds okay! Let me know if you have any questions, as I'm aware that the document isn't too polished at the moment!!

Cheers,

Steve

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this