Vegetation Rendering

I was looking at Far Cry's vegetation today. They use a small collection of hand-modeled trees and bushes. For a given model, they also have a set of billboards of the model rendered from several viewing directions. (They actually have a high- and a low-rez set of billboards for each model.) For a distant tree, they select the billboard that most closely matches the actual viewing direction. (If you strafe around the tree and change your viewing angle enough, you'll see the tree pop as it switches to a different billboard.)

When you get close enough to a billboard tree, it switches to the 3D model, but you don't see a pop! I would have expected a pop, since the billboard version of the tree is only in approximately the correct orientation. To avoid this, they orient the 3D model so that it matches the billboard. Then, as you approach the tree, the 3D model gradually rotates to the tree's "true" orientation.

Well, anyway, that was my impression of how their system worked. If you want to check it out for yourself, download the demo and focus on the "bent" palms along the beaches.

Hey, Winter Park is a few miles south of me. I suppose you're at Full Sail, yes? Just curious...

Nature Wizard has some interesting tips on plant geometry and l-systems. The Virtual Terrain Project is also a good source for informations like this.

Last but not least, there is the Convincing treesthread on this forum which contains very interesting tips about vegetation rendering (trees).

Eric: It almost looks like farcry is dynamically updating their billboarded trees. I believe this is why you don't see a pop. I was attending Full Sail, but I graduated last year.

Emannuel: I've read nearly everything I could find on the forums and vTerrain. Thanks for that Nature Wizard link though, seems like they may have some interesting technology.

I'm seriously contemplating implementing a dynamicly updated imposter system. So up close I would render the full mesh, then maybe use some geometry LOD techniques, and at a distance use render to texture to cache the billboard.

This should solve a lot of popping issues and have a relatively good performance as long as the number of imposters updated per frame is minimal. I suppose I could use a priority system and update during a timeslice.

Any questions, comments or concerns? Has this been done? I'm also wandering how I'd set up the transforms to rendre the tree to the imposter, any ideas?

[Edited by - Sages on August 10, 2004 12:22:55 PM]

Sages: Yann L describes a similiar system in this thread:

http://www.gamedev.net/community/forums/topic.asp?topic_id=157049

Regarding rendering... http://www.vrvis.at/TR/2003/TR_VRVis_2003_027_Abstract.html (the pdf paper is there also) has a summary of different techniques. The "interactive rendering of trees with shading and shadowing" mentioned in there looks the most interesting to me - although the cube map visibility could probably be replaced with some cheaper visibility calc in a vertex shader (eg, polynomial texture map except per-vertex, ambient occlusion, SH, shadow map, etc). Speedtree also looks interesting though not much info - downloading and looking at the valley demo can reveal alot though.

I am attempting to understand all the possibilities before I decide to implement a method. I am curious as to how you would calculate the view and projection transforms needed to updating the imposter texture. Any thoughts on this?

Here are some screen shots of the the project I'm implementing these features into. I've implemented all the tree and grass rendering features today, and they are in need of improvement.



[Edited by - Sages on August 11, 2004 6:29:33 PM]

That grass looks pretty sweet man, nice long-field type of grass - what method did you end up using for it? It looks like it might be moving in real-time too but I can't tell from the static shots too well.

-Mezz

The rendering is based on an article in GPU Gems, which discusses the technique used in the Code Creatures Benchmark. It actually looks pretty crappy IMO, since my current pixel shader just returns a constant color, and the animation is currently applied to all of the grass patches the same way.

All the grass currently animates exactly the same which definitely doesn't portray reality but the system is flexible enough that I could add per patch animation easily. There is a few methods discussed in the GPU Gems article, I just haven't implemented any of them.

Unfortuneatly, since the article is discussing a benchmark, the rendering method is meant to be taxing on the system. So, I've been reading several other articles to help decide how I'll do LOD. I have a method worked out that should be sufficient, but I won't be implementing it until I get the render to texure tree system implemented, as I think the trees will be more impressive to the end user (me).

I just read a white paper discussing something called a 'coverage map'. I think I'll take this idea and automatically generate the flora layout based on a texture that represents what type and how many plants cover a given area.

I think this method could work well, for multiple plant types. I might even be able to use the terrain texture maps directly, albeit with less control over the final outlook.

As always I'm looking for feedback. Has nyone ever implemented this or know of a project uses this method? Questions? Comments? Concerns?

Quote:

Original post by Sages The rendering is based on an article in GPU Gems, which discusses the technique used in the Code Creatures Benchmark. ... Unfortuneatly, since the article is discussing a benchmark, the rendering method is meant to be taxing on the system.

I'm thinking of using this grass technique. Do you know roughly the number of polys you're outputing for the grass per frame ? You're viewpoint looks like it's outside the grass so perhaps the bottleneck would be polys ? In my case the eye will probably be (in/at the top of) the grass so fillrate might be worse due to the close grass (even though alpha-testing removes alot of pixels I'd imagine the raw rasterization of multiple ~screen-size quads would be a hit) - in which case grass geometry for close grass (for each blade like Yann does) might help.

Quote:

So, I've been reading several other articles to help decide how I'll do LOD. I have a method worked out that should be sufficient

Does it involve reducing grass polys in distance or using grass geometry up close or both ? Is it anything like the animating prairies article ?

Quote:

Do you know roughly the number of polys you're outputing for the grass per frame ? You're viewpoint looks like it's outside the grass so perhaps the bottleneck would be polys ?

Well, unfortunately I haven't benchmarked the grass without everything else running, and I'm already fill rate limited due to my poor water implementation. I'm assuming that I would be fill rate limited, but I'll run some tests when I get a chance and posts the results.

Quote:

Does it involve reducing grass polys in distance or using grass geometry up close or both ? Is it anything like the animating prairies article ?

I have read that article, and have taken some of the concepts it uses into consideration. I'm not sure if I would benefit from the full algorithm as it is discussed in the paper, but I'm sure I'll use portions of it.

I plan on releasing a detailed article in the next ShaderX or GPUGems (Haven't decided yet) that describes some very good techniques to do foliage. :)

[Edited by - Zelex on August 12, 2004 10:35:56 PM]

Zelex: That looks nice. Care to comment on any of your techniques?

Doing the randomly-oriented-quad-with-a-nice-texture method works surprisingly well most of the time.

The best trick I've learned with that method is that you can decrease the grass density the further you get from the camera because of the perspective projection. Essentially you get a constant screen-space density of grass. As long as you nicely fade in more quads as you get closer it looks great.

Quote:

Original post by Sages Zelex: That looks nice. Care to comment on any of your techniques?

As I have been told, I don't think i am allowed to do any pre-publication publication on the algorithm. But, I can say that it is unique and works very well. I'll do a post closer to the release of the article. :)

No idea if any of this will be helpful, but here are a couple of approaches that suggest some possible solutions. Most deal with tree and vegetation textures applied to terrain models.

Most of the tutorials include the necessary tools. You'll need Painter or Paint Shop Pro to complete them, but you can download the free PSP demo and use that if you don't already have it.

Tree: http://www.gardenhose.com/bigoak.htm

The poly count might be too high for games using this approach, but you guys would know better than I.

Terrain foliage: http://www.gardenhose.com/coyote.htm

Same as above. Works well for oblique and overheads, but poly count may be problematic here too.

Grasses: http://www.gardenhose.com/kansas.htm

The combat image is really nice. So, I don't know if this demonstration offers much.

Conifer forests: http://www.gardenhose.com/conspik.htm

May or may not have value.

Here's my disclaimer. Most of these tutorials are old an may not be relevant anymore. You'll know that better than I.

Since I make the rendering tools, I'm not exactly a disinterested party. That said, you can make your own. I'm basically an artist, http://www.gardenhose.com/rainforest-4.htm The point being, I hope my post doesn't offend anyone.