Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[oli_chose123]

Hello, I was wondering how your trees are generated. Are they models or do you generate them?
I'd also like to know what are your plans for the vegetation and to get that feel of variety.

I just finished my course in programming and had plans to create my own little "forest" engine, and would love to hear how you'll take care of it.

[cameni]

Hi,
The trees are just billboards, but we will be also switching to models up close. I guess there can be around 200,000 of such trees rendered in an average forest scene, maybe more - maximum density is ~44,000 trees per square km, one tree in one 4.8x4.8m cell. Performance depends on the actual density of the trees on the visible terrain tiles - for the areas that are almost completely covered by trees that that would make 400-500 thousand trees rendered.

Billboards are generated at run time by a geometry shader from a tree coverage map (per terrain tile). The map is computed using local terrain properties like elevation, slope and curvature, combined with fractal noise values to get the fractal-like distribution of trees in nature.

As for the plans - the vegetation will be derived from land type layer with 500m resolution. Each land type defines probabilities of occurrence of distinct vegetation types, which will be generated and mixed using fractals in a way that preserves the probabilities. The attainable variety of vegetation should be sufficient, problem will be to collect data for all the vegetation types for all the land classes we'd like to have.

[Crashy]

HI, sorry to bump a two years old topic, but I'm trying to implement a technique similar to the one you described in this topic.

I've made a geometry shader that samples a coverage map to generate two triangles per tree, for the moment the tree denstiy is less than the density I can see on your screenshots, but the framerate is really low(I've got an AMD HD 4870 video card), and the triangles aren't even billboard-ed. I get better performances with triangles batched in a vertex buffer and billboarded with a vertex program, but your technique has flexibility benefits I'd want to have in my engine.

I'm new at geometry shader programming so I may have done something unoptimized, is it possible to have more infos/hints about how you're doing this?

Thanks.

[cameni]

Geometry shaders are relatively slow, the only reason that we can use them with an advantage is because the computation of atmospheric lighting can be performed for the whole tree in a geometry shader, instead of executing it four times in a vertex shader. But if you can't drag enough of common code from VS into GS to compensate for its penalties, it will be slower. We are probably going to optimize it by computing the atmospheric parameters to an auxiliary texture (for every taken tree position) and then using it from VS - that could be a bit faster, avoiding GS entirely.

Other than that, we aren't sampling the coverage map from GS, instead we create a vbo containing all the info about trees - mainly the ground level and type info, and bind it as an input stream for the shaders. GS then quickly rejects the nodes without trees; the same can be done by collapsing the geometry in VS for instances with no trees.

[Crashy]

Okay I understand then.

Thanks a lot for your help, it's quite rare from people as skilled as yout to give such detailled informations:)

[foxfiles]

did you experiment with this technique for some of your trees/objects representations?
http://www.antisphere.com/Research/VolumetricBillboards.php

[angrypig]

I know this paper and there are more similar papers on the internet. I didn't experiment with similar techniques yes but i am thinking to try GigaVoxels for middle range trees because GigaVoxels with sparse octree structure should be less demanding for memory than slices in 3d texture or impostors. And the second possible technique is the one used in Erick Bruneton's engine but it has to be modified/simplified because it needs a lot of memory and is slow.

http://maverick.inria.fr/Publications/2009/CNLSE09/

http://www-evasion.imag.fr/Membres/Eric.Bruneton/

[PRiME]

those look very very cool, not sure what performance hit is but may be a good solution for semi-close trees before they go full 3d (which you would expect to consume considerable more processing power)

[foxfiles]

I look forward to seeing your trees 
and I am sure they will be of better natural aspect than proland's-ones

[angrypig]

It is not about better nicer or something like that it is about performance. Trees are not the only thing in the scene, so the primary goal is the performance...

[PRiME]

You should slap in a couple close/near tree rendering techniques in the options menu and let users try out each and offer feedback.

[Spudly]

You should slap in a couple close/near tree rendering techniques in the options menu and let users try out each and offer feedback.

I think this would be cool, but "slap in" is probably not the right term for something that would take months...

[ChookWantan]

You should slap in a couple close/near tree rendering techniques in the options menu and let users try out each and offer feedback.

I think this would be cool, but "slap in" is probably not the right term for something that would take months...

A reeeeeeeeeally slow slap, then?

[PRiME]

They actually have them mostly done from what I can tell, there are screenshots and even a movie I think of them in action. I believe that its more of a performance reason why its not in yet, perhaps they will ad it in as a option in the graphics settings at some stage for testing. Allot of people are still using quite old hardware btw.

[cameni]

It's more because the integration isn't complete yet, trees don't transform into corresponding billboards in the distance. But we will probably put it into the WIP section after the objects are done, for people to play with. It should be the next thing after the objects anyway.