Jump to content

  • Log In with Google      Sign In   
  • Create Account

Storing grass patch data (terrain system)


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
1 reply to this topic

#1 Juliean   GDNet+   -  Reputation: 2722

Like
0Likes
Like

Posted 25 August 2013 - 04:59 PM

Hello,

 

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!



Sponsor:

#2 nonoptimalrobot   Members   -  Reputation: 416

Like
1Likes
Like

Posted 25 August 2013 - 07:33 PM

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.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS