Sorry for the bout of silence after putting the Editor up for download. I took a couple of days off as I was starting to feel a little burned out. Part of me wants to start working on a side project as sort of a palette cleanser but I don't think I can afford that luxury as I'm the only one working on Fractured State. I wouldn't want to disappoint all my fans (*cue cricket noises and tumbleweed*).
At any rate - I've been doing a lot of reading on shader authoring and the Cg language the past few weeks as well as studying various terrain texture painting techniques used in past RTS games. The path I originally went down (the foundation of which is currently implemented) is similar to that of Warcraft 3 and Command and Conquer : Generals in that you paint single terrain "tiles" at a time. Warcraft 3 blends between different textures by overlaying triangle strips that appear to either have a higher Z value or are simply drawn in a different pass in the shader. Generals does an interpolation between adjoining textures using something that sort of looks like vertex weights - although I can't be 100% sure on this.
By far the one that was the most impressive is the algorithm used by Starcraft 2. Their Galaxy Editor allows you to paint per-pixel textures onto the terrain using a variety of brushes. My best guess at this implementation is that they are using a series of Alpha Maps with a texture assigned to each spectrum of RGBA. This texture gets passed to a shader that does a blend of each texture based on the color of the fragment. So when you paint textures in the editor you're actually painting some subset of RGBA. This explains why they imposed a limit of 8 textures per map (if you use all 4 components of RGBA and use 2 control map textures you end up with 8 possible - this was probably a design choice to get a middle ground between customization and performance).
Given how good the results are, and how nice the user experience is with the toolset, this is the method I've decided to pursue. The unfortunate trade off with this is that I need to lock down some of the requirements when creating a new map. The current plan is to lower the vertex limit on terrain mesh chunks and generate them in squares instead of strips. This way, each chunk can get it's own 512x512 (or lower or higher - this might vary as I go along) to act as the control map. What I may do is categorize the maps into Small, Medium, Large, Very Large instead of allowing a free ratio between height and width. Really not sure yet - we'll have to see as I dig in. On the plus side, I'll still have vertex color and UV2 to do any kind of baking that I want (still planning on per-vertex ambient occlusion at some point).
On the other side - I did clean up the Place Object tool UI a bit. I added a new element to the prop definition schema called category. This allows the Editor to chunk objects into categories so you don't have to sort through a huge list in order to find the prop you're looking for. I put a skin on it so here's what it looks like now:
Some nice things that it does currently:
- Automatically adds Categories based on prop definitions (no need to declare the category separately)
- As you can see in the shot - longer prop names wrap (Categories currently do not as it just flat out breaks the UI)
- The Editor automatically alphabetizes both Categories and Props in each Category
The only limitation with this system currently is that each Prop still needs to have a unique name across the entire game. I may remove this limitation in the future depending on user feedback.
