Sign in to follow this  

Storing grass patch data (terrain system)

Recommended Posts

Juliean    7068



I'm working on adding grass to my terrain system. I'm using three cross-aligned billboard, to represent a grass "blade". Now I'm wondering what a good method for storing grass patches, so that I can load them into the game? I'm currently using a heightmap for the topology and a "weight" map for which kind of texture to apply to where. I want the artist to have control over where to place grass and where not to, so any suggestions for a format to store this information? Should I e.g. store an 2d array for each smallest possible unit on my terrain with 0-9, determining what kind of grass is at this position? This doesn't seem optimal in size, so any other suggestions is welcome!

Share this post

Link to post
Share on other sites

This is how I've done it in the past:


Grass "clumps" are placed in the world individually or via a spray brush in the world editor.  The brush and placement tool have various options to make this easy including an 'align to terrain' behavior and various controls over how sizes, orientations and texture variations are handled.  This process generates a massive list of positions, scales and orientations (8 floats per clump).  There are millions of grass clumps so storing all this in the raw won't do...


At export time the global list of grass clumps is partitioned into a regular 3d grid.  Each partition of the grid has a list of the clumps it owns and quantizes the positions, scales and orientations into 2 32 bit values.  The fist value contains four 8bit integers: the first 3 ints represent a normalized position w.r.t. the partition's extents and the 4th is just a uniform scale factor.  The second 32 bit value is a quaternion with its components quantized to 8 bit integers (0 = -1 and 255 = 1).


At runtime the contents of nearby partitions are decompressed on the fly into data that's amiable to hardware instancing.  This was a long time ago so it was important the vertex shader didn't spent to much time unpacking data.  Theses days with bit operations available to the GPU you might be able to use the actual compressed data and not need to manage compressing and uncompressing chunks in real-time, if you do use a background thread.


It worked pretty well and was extended to support arbitrary meshes so the initial concept of a grass clump evolved to include pebbles, flowers, sticks, debris etc.  Any mesh that was static and replicated many times throughout the world was a good candidate for this system as long as its vertex count was low enough to justify the loss of the post transform cache caused by the type of HW instancing being used.

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