grass rendering

There's an article in GPU Gems 1 about rendering grass which I think describes the most commonly used technique. You can see an implementation of it in the Codecreatures Benchmark (should be downloadable for free).

I guess nvidia uses the same effect here: http://developer.nvidia.com/object/nature_scene.html

Normally a modern implementation will use either instanced rendering of simple alpha masked models (such as the crossed quads) or a large number of batched billboards.

In my opinion a combination of these methods provides the best result with current hardware: use instanced models in medium density in a larger area around the camera, and batched billboards with a higher density close to the camera.

My appraoch gives you the 3D look and feel of models, and the high density possibilities of batched billboards.

I used the method described in GPU Gems 2 (which is slightly different from the on in GPU Gems 1. In said method, you just draw a bunch of screen facing transparent billboards. You then multiply the alpha value of the pixel by a component pulled from a gray scale texture. This creates a dissolve sort of effect so that you do not have to sort the blades by distance. I have not yet implemented these, but there is also a suggestion for lighting by using the normal of the ground below the grass. Also, one can put more than one grass image on the grass texture (like a texture atlas), and use that to add some variety to the blades. Grass seems to be pretty easy, and when it comes down to it, like most things it's about the quality of the texture. Here are the results of my implimination. I have not yet tied it into my quadtree, so at the moment, I'm just throwing a buffer full of 200,000 quads at the video card. I do my screen aligning in the vertex shader.

http://img.photobucket.com/albums/v453/SeraphicArtist/RadiantGrass02.jpg

http://img.photobucket.com/albums/v453/SeraphicArtist/RadiantGrass01.jpg

Hope that helps.

Quote:

Original post by Anonymous Poster http://www.vterrain.org/Plants/Modelling/index.html I also like the idea in: http://www-evasion.inrialpes.fr/Publications/2003/GPRFC03/

The last one the AP mentioned sounds quite interesting. Once I am so far with my engine I will implement this one, especially because of the interaction with objects, that adds a whole new dimension to gameplay

Quote:

Original post by Basiror The last one the AP mentioned sounds quite interesting. Once I am so far with my engine I will implement this one, especially because of the interaction with objects, that adds a whole new dimension to gameplay

Note that the algo doesn't handle dynamic (lod) terrain. Might be an issue if ou want to make huge prarie.

Well, I don t think LOD terrain is worth is for an FPS engine like mine.

Even Carmack said that doing LOD on terrain costs more managing power than its worth. I ll trust him on this one ^^

Quote:

Even Carmack said that doing LOD on terrain costs more managing power than its worth. I ll trust him on this one ^^

again, like mentionend in other threads,this is true for "smallscale" terrains but for largescale terrains(2km*2km[4096*4096quads]=1quad/0.5m) the polycount is just too high(33 million triangles!)for bruteforce rendering.

regards,
m4gnus

On a Xkm x Xkm you never render everything. If you have hills, moutains, etc. you can remove large parts of the terrain. I think using 16x16 static grid patches (or bigger patches) combined with and octree + occlusion query or some kind of PVS can really be used with current hardwares.

(sorry for the off-topice reply ^^)