[submitted] Real-time rendering of trees

Threads related to Google Summer of Code
Post Reply
Bananmos
Gnoblar
Posts: 22
Joined: Tue Jan 23, 2007 8:36 pm

[submitted] Real-time rendering of trees

Post by Bananmos »

I realize it's just a few hours until the deadline for submissions, and can only blame it on having other deadlines to consider. But I'd like to know if you find my project interesting enough for me to submit it.

I have just finished a computer graphics project course at my university, which focused on using shaders to render trees using the model described in "Creation and Rendering of Realistic trees" by Jason Weber and Joseph Penn. This is the same model that MeshTree, Arbaro and other similar tree generating projects have used. All of them, however, have generated a static mesh, and none have considered level-of-detail-schemes in detail. (no pun intended)

My approach has been somewhat different to theirs. I initially envisioned my project for the Geforce8, as a geometry shader would in theory let you render a single tree at any detail with just its position (and possibly orientation), tree type and a seed value (for the random number sequence to use) as the only parameters. But lack of such a card made me reconsider my ideas for a Geforce6 card.

A tree is rendered att full detail by drawing each stem as a segmented cylinder of specified detail and its vertices are modified in a vertex shader, to make it curve and taper its radius. I first chose to do away with random variations in the curvature, which allowed me to explicitly compute a vertex's position in the vertex shader linearly in time, but was not satisfied with the result, as curved stems without any random variation looked somewhat synthetic

My current solution is to use a big heavily quantized vertex texture as lookup table, which allows a fixed number of stems with random variations in curvature. The curvature is linearly interpolated when a stem sways in the wind, allowing the vertex texture generating code to quantize the maximum allowed curvature to just a handful of possible indices.

Leaves are drawn as a cluster for each stem, consisting of quads with identical positions, but differing with an index. This index is used to place them randomly around the stem. (which implies reading the same vertex texture as the stem vertex shader uses)

Here are pictures of the test tree with and without leaves:
Image
Image

The trunk, main branches and sub-branches all sway individually in the wind.

I have also implemented a level-of-detail-scheme. For this I first looked at SpeedTree's method, but deemed it unsatisfactory. While SpeedTree looks outstanding from stills, I personally find the heavy aliasing resulting from only using alpha-rejection disturbing. Also, SpeedTree's simplistic LOD scheme means that the illusion is shattered once you get too close to a tree so the camera-aligned billboards become obvious.

Instead, I chose a LOD-scheme taken from a thesis by Emil Jansson, where branches are increasingly replaced by textured billboards axis-aligned-billboards. (not camera aligned) I.e., once distance to the tree increases, the subbranches are replaced with billboards, then the main branches and finally the tree itself. (becoming the tree billboard we all know and love from any tree rendering software)

To be able to re-use the same stem textures somewhat more and also make them sway in the wind the same way the geometry it replaces does, I implemented the same formulae I used for bending stems in the pixel shader to bend the pre-rendered textures viewed from the side. (without the random variation though) These two pictures should give you an idea of what I mean:

Image
Image

And this is how it looks when the main branches are rendered as billboards:
Image
Image


Less symmetric results should be possible by rendering several billboards for each branch level.

The same pixel-bending could be applied to a tree which just consists of a single billboard. At that distance, you won't take notice of individual branches' movements, but still be impressed with seeing trees blow in the wind at a distance.

The billboard stem vertex shader is very similar to the leaves shader I described above, but each stem consists of four orthogonal quads, who are faded away (and then discarded completely) with increasing angle between the normal and the viewspace Z-axis.

Real alpha-blending is used to get anti-aliasing for free via mip-mapping, which does require some sorting. However, it isn't very noticable if the billboard branches are drawn in a random order since you're at a distance from the tree. Also, I think the vertex shader could be rewritten in a smarter way to take the viewing angle into account when placing the billboard stems so that the ones at the back of the tree are drawn first. (remember the quads have identical vertex data except for the index) So for the LOD where the trunk is geometry and all main branches are billboards, it would be enough to sort trees only.

For batches of billboard trees at a distance, I think you could get away with the same reasoning as for the branches and draw them unsorted if you eventually cross-fade them with a sorted billboard batch. But I haven't tested this in practice.

An initial goal of mine was to provide a simple "TreeManager" class which would let you add different tree types to it and set the quantization and limits of the curvature vertex texture parameters. You could then "compile" this data to make it generate the vertex texture and build texture atlases of the tree barks and billboard stems. This class would also handle the drawing order, which needs to look like this:

* First draw all fully opaque geometry stems in the scene
* Then draw all batches of billboard trees back-to-front
* Then draw stem billboard clusters for billboard main branches for each tree, and draw the fading geometry stems for this tree
* Then draw stem billboard clusters for sub-branches

I have started work on this class but didn't finish it in time. I also haven't had time to optimize the shaders. There's a lot of work left to be done, and I was thinking it might make a decent candidate for the SoC. I envision an external library for OGRE where the game programmer can easily edit parameters of a generated tree like in meshtree studio, only in real-time this time. Then throw all the designed trees to the TreeManager and get the scene populated with lots of tree species and even more individual instances of each species where no instance is identical to the other.

Of course, there are drawbacks to the method I've described. The big question is if the lack of aliasing makes up for the performance loss when using alpha-blending and (approximate) sorting. And of course, the shader requirements are a drawback in itself. You might also question how much heavy use of instancing really bothers a player, and whether unique trees are really worth the effort. More testing and evaluation is needed for this, and a mid-term evaluation would likely consist of deciding on which features features are really worth the effort, or if the project ought to turn its focus to a simpler more SpeedTree-like scheme after all.



Phew, even less time left now. Tell me what you think about the proposal.
Last edited by Bananmos on Mon Mar 26, 2007 11:54 pm, edited 1 time in total.

buddy
Google Summer of Code Student
Google Summer of Code Student
Posts: 78
Joined: Tue Mar 29, 2005 3:35 pm
Location: USA

Re: Proposal: Real-time generation/rendering of trees

Post by buddy »

Bananmos wrote:I realize it's just a few hours until the deadline for submissions, and can only blame it on having other deadlines to consider.
Deadline was extended, see http://code.google.com/soc/
While I have no relation to the mentor team, I could say that adding milestones/timeline might be a good idea in your proposal ;).

User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2653
Joined: Wed Sep 24, 2003 8:07 am
Location: Haute Garonne, France
x 4
Contact:

Post by tuan kuranes »

Existing Ogre related Tree code here :
Mesh Tree - Alpha Demo .
Billboard clouds
And finally expansive forest.

Problem is not performance here, but really to end up with a finished, usable tool that help integrate Tree in any Ogre application.

Now if you come with a finished, usable, tool with GUI , you then have a valuable subject to submit.

IMHO: Shader optimized tree is only a bonus. (that you can still add into the project submission)

Example : User would submit a Terrain and you generates terrain coverage map in a binary format (could be an image), you provide code/addon that reads those coverage maps page per page, and handle the LOD automatically from Impostor (one billboard per tree), Billboard clouds, set of identical genererated Mesh, different generated mesh...

A detailed planning and deliverable list is needed.
Better to be realistic (so it ends with usable code) than focused in performance/features/etc...

Bananmos
Gnoblar
Posts: 22
Joined: Tue Jan 23, 2007 8:36 pm

Post by Bananmos »

Thanks for replying. I had a lot of use for MeshTree as a reference example during my project. However, as my focus was from the very beginning to move as much of the workload to the GPU as possible, I chose to re-implement the tree generation model myself rather than modify MeshTree's code. I had to get some detailed insight into the model anyway to be able to handle placement of the billboard stems on the GPU. Besides that, MeshTree only generates static geometry and has no support for wind sway, which is a drawback IMO. Of course, that could be added dynamic VBOs, but I still think the method I have already implemented has bigger potential.

The Billboard clouds project seems very interesting though, I can't believe I missed it during my project. It basically seems to be an refined variation on the method I used, in that parts of the tree are rendered to billboards. While I use a more explicit method where exactly one stem of a certain branch level (and its child stems of course) is rendered to a billboard in the texture atlas, the billboard clouds method renders an arbitrary part of the tree to the best fitting plane found via an expensive greedy algorithm.

So contrary to my method, there is no 1-to-1 correspondence between stems and billboards. This has some obvious advantages to my method, as it can achieve a lower polygon count this way. However, it also has some drawbacks. Holes in the billboard cloud come to mind. More importantly, there seems to be no way to make a billboard cloud sway in the wind, and the authors are quick to point this out. So it would really only be usable at at distance where wind sway isn't noticable any more. If there's a lot of wind, that distance might be large.

Besides that, I think my method would allow for more re-use of billboards since trees of the same species don't have to be identical instances. Of course, the importance of this may be debatable.

The paged geometry project seems to be wise to build on for handling the actual scene and the LODs of trees. However, it seems to be orthogonal to the tree modelling method and LOD scheme used, so any method for rendering trees should be possible to incorporate into it.

I'm not saying my methods are the best solution. There are a number of different solutions for rendering trees in real-time, and the only way to judge if an idea is better than another is to implement it and compare the results.

I'm sort of getting the feeling you're asking me to ditch the ideas I'm working on in favor of continuing the earlier projects you mentioned, and part of my reasons for considering the SoC was so I could try them out further and refine them. I'm willing to reconsider and pursue different goals, but before doing that I'd like to be convinced that my own ideas are not worth considering.
Problem is not performance here, but really to end up with a finished, usable tool that help integrate Tree in any Ogre application.

Now if you come with a finished, usable, tool with GUI , you then have a valuable subject to submit.
No, I don't have a usable tool with GUI at this stage. I was thinking this would be the result from the SoC project. Are you saying I already need to have this done to even bother applying?

User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2653
Joined: Wed Sep 24, 2003 8:07 am
Location: Haute Garonne, France
x 4
Contact:

Post by tuan kuranes »

I'm not saying you must continue old project or already have usable tool. I'm pointing at you that we aim at a finished, usable, documented, possibly with gui project at then end of Gsoc.

Put another way, at the end of summer :

"A finished project is better than an uber cool work-in-project demo that no one will ever use"

So better come with a realistic planning and deliverable list aiming at results directly usable, rather than a huge list of feature that will never be completed.

Bananmos
Gnoblar
Posts: 22
Joined: Tue Jan 23, 2007 8:36 pm

Post by Bananmos »

I fully understand the point you're making that usability is the key issue. On the other hand however, you need a foundation worth basing the tool on.

If the projects you mentioned had reached this stage, I'm convinced they would have been continued already. But MeshTree doesn't handle the LOD problem at all. The billboard clouds method does, but I'm not convinced it's the way to go, since trees can't be dynamic.

The methods available for creation and real-time rendering of trees are quite different. SpeedTree is in many ways an artist's tool, which gives them freedom to manually create optimized models by hand and tweak them. This is good for professional game companies with dedicated artists, but most of them won't even have to bother since the license includes a library of thousands of models.

Making a SpeedTree clone wouldn't be too hard, but to compete with it on the same level requires lots of carefully designed low-poly trees IMO. And seeing how much trouble the OGRE community has even with getting some content for the demos, I don't think these resources are available here.

The billboard clouds method is on the other side of the spectrum, being a fully automated process once you have a high-resolution tree. But it has its own share of problems, which I pointed out earlier.

Making a finished usable tool isn't a good goal until you know how all parts fit together. Since modelling and LOD-generation may be heavily tied to the real-time rendering engine, you need to have the big picture clear before making that neat GUI you aim for. Otherwise, you'll spend most of your time re-writing it once you begin to question your solution.

So yes, I would do my best to make a GSoC result in a finished usable tool. But trying to accomplish that before questions regarding the LOD handling are sorted out wouldn't make it a good tool anyway. You can't just leave some things for later consideration, since a choice of LOD handling may make some future goals impossible. (the billboard clouds' apparant inability to handle wind sway is an example)

Like I said earlier, I am more than willing to openly discuss which goals a LOD system should pursue, as this can be quite subjective and ultimately the vote of Joe Gamer is the only one that really counts.

So what are your suggestions? Is the possibility to have wind sway not a priority in your opinion? Or do you have some ideas of your own on how it could be pulled off while still using the earlier works on billboard clouds? Please be more specific on what goals are the important ones in the LOD handling, since describing the finished tool's interface doesn't say much on what to focus on in the visuals. And again, I don't think a problem you intend to solve can be neglected for the time being if you don't have an idea on how to do it at a later stage.

Bananmos
Gnoblar
Posts: 22
Joined: Tue Jan 23, 2007 8:36 pm

Post by Bananmos »

So I've made a submission now, with reasonable goals. Hope to get some feedback on it.

Abstract:
Many different strategies have been used to render trees and other vegetation in games, but none have been sucessfully implemented in OGRE yet. Those that have been tried out in OGRE have lacked an efficient and convincing method for reducing level-of-detail at a distance. I wish to try out an unexplored alternative, which should not only provide convincing LOD transitions, but also reduce aliasing.

Proposal:
I would like to develop a method for rendering large number of trees in real-time using OGRE, coupled with a tool to create different types of trees. (typically what you'd refer to as "species", but since you might need to create different types for different ages and seasons "tree type" is a better word for it)

The tree generation model to be used is from the paper "Creation and rendering of realistic trees" by Jason Weber and Joseph Penn. Other people have successfully implemented this model for generating meshes. One of them, MeshTree, is an incomplete tree generator for OGRE. I have used this code as a reference implementation for my own work with this model, which focused on two goals:

- accelerating the rendering by using shaders, to allow for wind sway (and possibly other dynamic effects)
- creating a LOD scheme described in a masters' thesis by Emil Jansson, where stems and their sub-stems are pre-rendered to three orthogonal billboards, which are rendered in place of the stem geometry at lower detail levels. These are rendered using true alpha-blending to avoid aliasing noise in the semi-transparent textures, and sorting is only done for clusters of billboards around a trunk/stem rather than individual ones. This is hardly noticable at the intended distance. Alternatively, simple alpha rejection could be used on lesser hardware at the cost of aliasing problems.

My previous work has been focused on implementing as much of the tree generating code itself in the vertex shader, to allow for totally unique trees in real-time. This meant it required shader model 3 and really yearned for the geometry shader in shader model 4 as there were many problems left that are difficult to solve without it.

For this GSoC, I will shift my focus and aim more for flexibility and compatibility with older hardware and the OGRE engine in general rather than dedicate time to invent new shader tricks. Work on shaders will mostly focus on improving and optimizing the texture bending that I've implemented in my previous work.

As the scene manager system is going to change significantly in the next version of OGRE and I have no experience with scenemanagers, I do not intend to make a ready-to-use scenemanager. Rather, I will focus on writing code for rendering trees and batches of them at different LODs that could easily be incorporated into a scene manager later on. I will look at incorporating this into the PagedGeometryManager for the time being.

LOD handling of trees is a vast area for research and experimentation, and there are other techniques Besides the method I wish to try, each having their specific trade-offs. SpeedTree accomplishes very nice results with carefully designed low-poly models, but suffers from aliasing problems and a too simplistic LOD scheme. Billboard clouds are a fully automated technique for converting highly detailed tree models to arbitrarily aligned billboards, but wind sway does not seem possible with this method. I intend to devote some initial time to compare these alternatives to my own, and hope to get feedback from the OGRE community on which goals are the most important to focus on as far as visual quality is concerned.

Why?
Though previous work has been made in this direction, there still is no usable plugin for rendering large numbers of convincing trees of different species in OGRE. I hope to bring us a little closer to this goal, with an alternative method to the ones already known.

Why me?
I am a 27 years old swedish student studying applied physics and electronic engineering for far too many years, but finally getting close to my masters degree. Although my "official" studies has been focused on physics, mathematics and electronics, I have always had a big passion for real-time graphics, and one reason why it's taken me so long to complete my studies are all the extra courses I've taken in this field. I'm considering work in this field as my masters thesis and have just completed a smaller project I wish to build upon.

A drawback is that I'm not very experienced with the OGRE engine yet, and my recent work consisted mostly consisted of fighting it to access the low-level rendering myself. But I believe my progress get will be smoother now that I'll concentrate on doing things in more conventional ways using OGRE for what it was intended for, rather than using it to experiment with shaders.

Proposal-in-6-lines:
1. Implement code for generating trees with OGRE, or improve the existing one known as MeshTree
2. Implement a convincing strategy for simplifying them to different LODs
3. Render large number of trees in real-time using OGRE
4. Make a tool with GUI for generating trees, or improve the existing one known as MeshTree studio
5. Make a tool for planting trees on a terrain map, preferably visualizing the results instantly
6. Provide documented code that will be easy to integrating this with a scenemanager such as the paged geometry manager

Schedule:
28/5 - 3/6
An my last exam takes place on the 4th of june, I can only work half-time this week and intend to spend it trying to compare the alternative approaches to LOD handling that exist, and involving the OGRE community in an open discussion on what the important goals should be.

4/6 - 10/6
Fill in the missing gaps in the tree generation, starting from either my own code or MeshTree's, Both use the same model, but MeshTree implements more of its features while mine is more familliar to me.

11/6 - 17/6
Complete my "TreeManager" class. This is a class that will register different tree types to be used, and then "compile" these settings, which involve building texture atlases for the bark texture and stem billboard textures at different levels. Implement all intended LODs. Add normal map generation for per-pixel lighting and add this to the shaders.

18/6 - 24/6
Further work on the TreeManager, focusing on how many different billboard textures to render at each stem. Try to decide whether each stem of a tree type should have its own unique billboard or if billboards could be re-used while still maintaining visual quality of trees.

25/6 - 1/7
Implement correct drawing order for trees. Implement batching of trees at the billboard LOD. Implement fading between LODs.

2/7 - 8/7
Try to improve the texture bending technique, possibly looking into if more advanced image warping techniques might be applied in the pixel shader.

9/7 - 15/7
Buffer time for completing mid-term goals. If time is plentiful, try to add dynamic shadows to nearby trees.

16/7 - 22/7
Recreation week at Camp Burn Yourself

23/7 - 29/7
Work on program with a GUI for generating different tree types, possibly re-using previous code from MeshTree studio.

30/7 - 5/8
Recreation week at the European Juggling Convention

6/8 - 12/8
Work on a program (preferably with GUI) that generates a coverage map from a terrain texture and tree type distribution settings. Preferably integrated with the forest rendering, so the result can be visualized instantly.

13/8 - 19/8
Cleaning up code

20/8 - 26/8
Buffer time for completing previous goals. If time is plentiful, try to add static shadowmaps to the terrain for distant trees.

27/8 - 31/8
Documentation

buddy
Google Summer of Code Student
Google Summer of Code Student
Posts: 78
Joined: Tue Mar 29, 2005 3:35 pm
Location: USA

Post by buddy »

Proposal-in-6-lines:
heh, this one is getting popular ;).

User avatar
Julius
Kobold
Posts: 35
Joined: Tue Mar 22, 2005 10:53 pm
Location: Germany
Contact:

Post by Julius »

Wow this looks extremly nice! Would be cool if it was accepted for Gsoc.

A few suggestions though:
1. please keep the tree algorithm as flexible as possible, it should be still possible to make everything between small scrubs over palm trees up to big jungle trees.
2. Trees grow different when growing in a forest, lots of tree engines forget that and their "forests" look like many single trees but nothing like the real thing.
3. Would be cool if a high resolution shadow-map for projecting underneath the trees would be auto generated also (including wind swaying).

thx
FreeGameArts<-back online!

User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Post by jacmoe »

Unfortunately, SoC is in action.

Would be cool if this project was taken on, anyway. :wink:
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.

User avatar
stoneCold
OGRE Expert User
OGRE Expert User
Posts: 867
Joined: Fri Oct 01, 2004 9:13 pm
Location: Carinthia, Austria
x 1

Post by stoneCold »

jacmoe wrote:Would be cool if this project was taken on, anyway. :wink:
Agreed :D
my tweets | www.fuse-software.com | home of vektrix (Flash GUI for Ogre3D) and caspin (ActionScript 3 Virtual Machine Wrapper)

User avatar
Julius
Kobold
Posts: 35
Joined: Tue Mar 22, 2005 10:53 pm
Location: Germany
Contact:

Post by Julius »

Any update on this?

Maybe it would be possible to integrate your code into a more generic project like Opentree, Arbaro or ngplant (no particular order)?
http://opentreelib.sourceforge.net/
http://ngplant.sourceforge.net/
http://arbaro.sourceforge.net/
FreeGameArts<-back online!

User avatar
Aladrin
Orc
Posts: 465
Joined: Fri Mar 10, 2006 10:22 pm

Post by Aladrin »

I don't think the Summer of Code has officially started yet. I could be wrong about that.

As for the plants... The ones from Arbaro look awesome! I got 2/3 down the page and had a Monty Python flashback, though: "The LARCH!" lol (From the 'How to recognize trees' episode.)

http://www.ibras.dk/montypython/episode03.htm

User avatar
Falagard
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2060
Joined: Thu Feb 26, 2004 12:11 am
Location: Toronto, Canada
x 3
Contact:

Post by Falagard »

Arbaro's trees are identical to MeshTree by Sputnick posted here on the forums, and MeshTree Studio which uses the MeshTree library to generate trees. It's based on the exact same whitepaper.

The problem with MeshTree is that it generates too many leaves to be viable in a realtime game - unless however you're willing to use very large leaves that have a texture mapped to them that is a "cluster" of leaves, similar to SpeedTree leaves except that they won't always face the camera. This is a decent solution, but there are other problems - such as you want to generate multiple levels of branches so the leaves are in the right place, but have an option of exporting only the first 2 levels even though 4 levels have been created. You'd also want another option to export as something like .obj file so it can be imported into a 3d package like 3ds max or Maya so you can perform some tweaks to it.

I may be working with Sputnick to add some of these features as well as a leaf billboarding option similar to SpeedTree that uses a shader to orient leaves towards the camera.

User avatar
Praetor
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 3335
Joined: Tue Jun 21, 2005 8:26 pm
Location: Rochester, New York, US
x 3
Contact:

Post by Praetor »

I've used arboro trees in Ogre before. They are really great looking, but Falagard is exactly right. There is no clustering of trees and it is way too much. I was running a few willows in my program, and when I turned leaves on it was just too much. Some work over and above tree generation needs to be done to group leaves and branches.

Bananmos
Gnoblar
Posts: 22
Joined: Tue Jan 23, 2007 8:36 pm

Post by Bananmos »

Thanks for your interest Julius. To be honest, no further work has been done on this project after my GSoC application was declined. Right now I'm busy with another project, implementing fluid simulation in CUDA.

The project might be revived if I do decide to base my master's thesis on this topic. But I haven't made a decision on that yet.

StillmatikX
Halfling
Posts: 67
Joined: Sat Nov 17, 2007 12:36 am

Re: [submitted] Real-time rendering of trees

Post by StillmatikX »

Bananmos wrote:I realize it's just a few hours until the deadline for submissions, and can only blame it on having other deadlines to consider. But I'd like to know if you find my project interesting enough for me to submit it.

I have just finished a computer graphics project course at my university, which focused on using shaders to render trees using the model described in "Creation and Rendering of Realistic trees" by Jason Weber and Joseph Penn. This is the same model that MeshTree, Arbaro and other similar tree generating projects have used. All of them, however, have generated a static mesh, and none have considered level-of-detail-schemes in detail. (no pun intended)

My approach has been somewhat different to theirs. I initially envisioned my project for the Geforce8, as a geometry shader would in theory let you render a single tree at any detail with just its position (and possibly orientation), tree type and a seed value (for the random number sequence to use) as the only parameters. But lack of such a card made me reconsider my ideas for a Geforce6 card.

A tree is rendered att full detail by drawing each stem as a segmented cylinder of specified detail and its vertices are modified in a vertex shader, to make it curve and taper its radius. I first chose to do away with random variations in the curvature, which allowed me to explicitly compute a vertex's position in the vertex shader linearly in time, but was not satisfied with the result, as curved stems without any random variation looked somewhat synthetic

My current solution is to use a big heavily quantized vertex texture as lookup table, which allows a fixed number of stems with random variations in curvature. The curvature is linearly interpolated when a stem sways in the wind, allowing the vertex texture generating code to quantize the maximum allowed curvature to just a handful of possible indices.

Leaves are drawn as a cluster for each stem, consisting of quads with identical positions, but differing with an index. This index is used to place them randomly around the stem. (which implies reading the same vertex texture as the stem vertex shader uses)

Here are pictures of the test tree with and without leaves:
Image
Image

The trunk, main branches and sub-branches all sway individually in the wind.

I have also implemented a level-of-detail-scheme. For this I first looked at SpeedTree's method, but deemed it unsatisfactory. While SpeedTree looks outstanding from stills, I personally find the heavy aliasing resulting from only using alpha-rejection disturbing. Also, SpeedTree's simplistic LOD scheme means that the illusion is shattered once you get too close to a tree so the camera-aligned billboards become obvious.

Instead, I chose a LOD-scheme taken from a thesis by Emil Jansson, where branches are increasingly replaced by textured billboards axis-aligned-billboards. (not camera aligned) I.e., once distance to the tree increases, the subbranches are replaced with billboards, then the main branches and finally the tree itself. (becoming the tree billboard we all know and love from any tree rendering software)

To be able to re-use the same stem textures somewhat more and also make them sway in the wind the same way the geometry it replaces does, I implemented the same formulae I used for bending stems in the pixel shader to bend the pre-rendered textures viewed from the side. (without the random variation though) These two pictures should give you an idea of what I mean:

Image
Image

And this is how it looks when the main branches are rendered as billboards:
Image
Image


Less symmetric results should be possible by rendering several billboards for each branch level.

The same pixel-bending could be applied to a tree which just consists of a single billboard. At that distance, you won't take notice of individual branches' movements, but still be impressed with seeing trees blow in the wind at a distance.

The billboard stem vertex shader is very similar to the leaves shader I described above, but each stem consists of four orthogonal quads, who are faded away (and then discarded completely) with increasing angle between the normal and the viewspace Z-axis.

Real alpha-blending is used to get anti-aliasing for free via mip-mapping, which does require some sorting. However, it isn't very noticable if the billboard branches are drawn in a random order since you're at a distance from the tree. Also, I think the vertex shader could be rewritten in a smarter way to take the viewing angle into account when placing the billboard stems so that the ones at the back of the tree are drawn first. (remember the quads have identical vertex data except for the index) So for the LOD where the trunk is geometry and all main branches are billboards, it would be enough to sort trees only.

For batches of billboard trees at a distance, I think you could get away with the same reasoning as for the branches and draw them unsorted if you eventually cross-fade them with a sorted billboard batch. But I haven't tested this in practice.

An initial goal of mine was to provide a simple "TreeManager" class which would let you add different tree types to it and set the quantization and limits of the curvature vertex texture parameters. You could then "compile" this data to make it generate the vertex texture and build texture atlases of the tree barks and billboard stems. This class would also handle the drawing order, which needs to look like this:

* First draw all fully opaque geometry stems in the scene
* Then draw all batches of billboard trees back-to-front
* Then draw stem billboard clusters for billboard main branches for each tree, and draw the fading geometry stems for this tree
* Then draw stem billboard clusters for sub-branches

I have started work on this class but didn't finish it in time. I also haven't had time to optimize the shaders. There's a lot of work left to be done, and I was thinking it might make a decent candidate for the SoC. I envision an external library for OGRE where the game programmer can easily edit parameters of a generated tree like in meshtree studio, only in real-time this time. Then throw all the designed trees to the TreeManager and get the scene populated with lots of tree species and even more individual instances of each species where no instance is identical to the other.

Of course, there are drawbacks to the method I've described. The big question is if the lack of aliasing makes up for the performance loss when using alpha-blending and (approximate) sorting. And of course, the shader requirements are a drawback in itself. You might also question how much heavy use of instancing really bothers a player, and whether unique trees are really worth the effort. More testing and evaluation is needed for this, and a mid-term evaluation would likely consist of deciding on which features features are really worth the effort, or if the project ought to turn its focus to a simpler more SpeedTree-like scheme after all.



Phew, even less time left now. Tell me what you think about the proposal.

Hey, just wondering how thes cylinder segments were created...?....Thanks.

Post Reply