A few points to notice:
- These are my first procedurally generated models which have a texture applied. I added texture coordinates to generated models ages back, for use with shader effects (ironically also being displayed on an early tree model). But this is the first time I’ve actually applied a texture to a generated model using those texture coordinates. And that worked on the first try!
- I did a lot of tweaking on the spacing of branches, to stop branches from (for example) being generated past the end of another branch.
- The ‘canopy’ of trees, in this shot, is a simple dome-shape. Eventually, I’ll want to have more than just this one shape, in order to make different types of trees.
- There are rendering glitches right at the very top of each foliage dome, probably due to extremely compressed UV coordinates there. I need to look at fixing these.
- In this shot, all the visible trees are using exactly the same generated model, just with different rotations and scales applied. For the final game, I’ll probably want to generate several different species of tree, and several variations of each.
- I’m not completely happy with the single-shade green of the foliage canopy. I’m trying to decide whether I can improve that using a greyscale texture, or whether I’m actually going to have to put colour data into the foliage texture. I’d rather avoid doing that if I can, though, because I really want to be able to vary that colour according to different factors, and as soon as I actually put the colour into the texture, I can’t modify it in code any more. (Edit: I’d forgotten to apply lighting to the foliage! Updated the screenshot with lighting turned on. Original screenshot for this post is here)
- Trees aren’t hovering above the ground any more; now they properly project down through the ground. This was surprisingly tricky to make work properly.
There have also been a number of changes under the hood, which will eventually be propagated back to the VectorStorm trunk. Most notably, vsTextureMaker has been renamed to vsImage, and can now load its image data from a file (previously, it could only be initialised by code setting each pixel manually). You can still make a vsTexture from a vsImage, if desired.
Also of note, I’ve been playing with different names for the vsBuffer class, which wraps around the OpenGL VBO functionality. Currently, I have it named vsRenderBuffer, which at least gives a vague hint at what it’s used for, rather than implying that it’s some generic memory storage class.