Hi Guys,
Hurrah, first test results from L3DT's vegetation mask generator:
This is the mask for a 'grass' veg type. The mask is zero (black) for all non-grass land types in the attributes map (sand, rocks, etc.) The mask value is 20% lower for 'dry grass' land types, and 20% greater for 'lush grass' land types. Furthermore, there is variation in the score based on the gradient, so steep areas have lower score in this type. There is also support for masking based on the altitude (i.e. for snow lines), water depth (for mangroves, etc.), and salinity, but these was not used in this demonstration. Anti-aliasing to smooth transitions from one land type to another is also planned, but not yet implemented.
These per-type vegetation masks represent the first stage in vegetation mapping. It is envisioned that the user may then customise/modify these masks to add perlin noise or light map dependency (as David demonstrated), or other effects using ZeoGraph. Once the user is satisfied with the masks, they will be fed into a yet-to-be-written algorithm that will generate a vegetation instance map (probably 8-bit, but possibly 16 if required) and/or a long list of vegetation instances. This calculation step may involve a 'game of life' style simulation, but in the first instance, it might just involve a sort of random shotgun approach.
Anyway, I have still yet to build a user interface for the mask generation, so it will be at least several weeks before the vegetation masks are available to users.
David Walters wrote:Hi, here's an update showing my work with vegetation. I added trees over the last couple of nights.
Bravo! Really nice work there.
David Walters wrote:Based on your prior post alluding to the system you're planning, I've designed my vegetation system so that it uses a single 8-bit map at a 1M resolution (same as my HM). The values represent the type of thing in that square metre - grass, grass+flower, tree, etc.
That sounds fine. By default, the veg type masks are generated at the same resolution as the attributes mask (to make anti-aliasing less of a headache), but the final output vegetation instance map will have user-selectable resolution, probably defaulting to the size of the heightmap.
David Walters wrote:Unfortunately this ends up being too dense in places, so a rules system to enforce a minimum and maximum separation should help that out a lot.
Planned; will be set by 'game of life' rules.
David Walters wrote:1. The ability to assign an arbitrary user id value for each plant type. I use 0x80 and up for trees as they require different processing from grasses and it makes it easy to quickly filter them.
OK, on to-do list. However, I wash my hands of managing ID collisions. User beware.
David Walters wrote:2. The ability to mark a plant type as being present at all points of a mask, and not just dotted around. I can only think of grasses for this, or maybe kelp forests?
Sure. I'll have a thinker about it.
David Walters wrote:3. A coarse priority assignment to resolve ambiguities at the merging phase - eg. a tree is high, flower is medium, grass is low. Equal priorities would have a random resolution -- so you could have blue flowers and red flowers that both trump grass, but you'd still have a random spread of flowers.
I will have to implement this for the game of life, but I've not thought through the mechanism just yet.
David Walters wrote:In terms of density/mask maps like the ZeoGraph stuff I did - would they be used one per-biome? I think this would work well to allow user injection of masks. I definitely think some user control here would be nice to allow for drawing crop circles or something.
Each vegetation type will have its own mask, and yes, you certainly could make crop circles using it.
David Walters wrote:I thought for mask edges maybe they would work as a dice roll against the value as it dropped from 1.0 to get a ragged 'binary' fringe? although maybe you'd want a curve there? some plants could be tagged as outliers and thus prefer edges. This would be good to have more ragged plants there or perhaps to apply a greater tilt so they hang out over the edge of a river?
I'm not sure edges will require any particularly special treatment, but I'll keep it in mind when developing the game of life algorithm.
Tilting trees is a possibility. I suppose I could use a 24-bit vector for the tree's up vector, plus another 24-bit vector for random axial scaling, and a byte for rotation about the up axis. This will add quite a bit to the data size; m'think's I'll use a binary file format for storing this per-instance data.
Cheerio,
Aaron.