February 11th, 2009
In case you haven't heard enough about trees, I have decided to talk a little bit about how our tree assets work in Overgrowth.
Many games use the popular tree editing middleware called SpeedTree. Although SpeedTree does some cool things, it has the problem that because it creates tree models from scratch using procedural parameters, the trees tend to look a bit similar and generic. This problem is compounded by the fact that it's use is so widespread that you have probably seen these trees in dozens of games (GTA4, Gears of War 2 and Fallout 3, just to name a few). David and I are pretty tired at looking at SpeedTree content, and having worked with it, I am not sure why so many games use it. Did I mention it costs almost $10,000?
Having decided that we didn't really want to use existing middleware, it was my job to come up with something that would work for our trees. I wanted my art assets to be as flexible as possible, and look naturalistic. I wanted the workflow to be simple, and to fit in with our existing techniques so that there would be fewer special cases to learn. What I came up with is to make the trees modular, which is simple, but works very well.
The modular tree assets are broken up into a 3 main categories; trunk, branch and leafy areas. Here is an example:
In the above image, the leafy parts share the same textures, but the branch and the trunk have their own texture space. One advantage of this is that the parts of the tree can look different, while standard procedural techniques usually use a tiling texture for the trunk, which means it looks the same everywhere.
Another great thing about this is that I can use these parts to make all sorts of different looking trees. In the above image, I have used the modular tree assets to make trees of different ages. because I can tweak each branch by hand there is another advantage over procedural generation; because I know how the game camera works, I could put dense branches that use more graphics resources only in places that the player is likely to see it. This means we have more resources for everything else.
It may seem that I don't like procedural techniques, but that is actually not true at all. There are a few ways we can use procedural systems with these same assets. For example, because our different trees use the same basic pieces, there is no reason we can't make a procedural editor to define how the pieces fit together. Another way to use procedural systems with these assets is to to make a bunch of tree presets, like those different aged trees, and have the editor decide where to place the trees based on the amount of sun or water they might get.
The main reason people use procedural asset creation is because it saves time, but the ironic thing is that complex middleware has so many sliders and dials that it can take ages to get the look that you want. With our method if I want something to look a certain way, I just make it that way, which takes far less time. Since all the editing takes place using the engine I don't have to worry about exporting data from middleware which can sometimes be tricky. This way we can avoid all the bad parts of procedural content creation but keep all the good things about it.