Presenting XNA Procedural Trees, a natural tree generator for XNA.
Download is at bottom of post, but first some screenshots.



The four screenshots above show the four different tree profiles I am providing. A tree profile is an XML file with information about how to generate a random tree. The trees a generated using a profile and a random seed, making for an endless amount of possible tree models.

The leaves you see on the trees are a kind of billboard - on the willow (lower right screenshot) they are axis-aligned, and on the others they are free. Leaves are also part of the tree profile. Wind blowing against the leaves is not supported, but I have it in mind for a future release.

The code is freely available under the MIT License, which means that you can do almost anything you like with the code.

Since XNA does not have its own scene graph, implementing it general enough for everyone to use it has a bit of a challenge, but you shouldn't have problems using it once you understand how the classes are structured. The supplied TreeDemo application is a great point of reference for seeing how to use it.

How to use XNA Procedural Trees in your project (only a partial reminder list):

1. Add the FeldthausTrees project to your solution.
   
2. Add a reference to FeldthausTrees in your main project (right-click on References in the solution explorer)
   
3. Add the tree profiles (XML files found in Content/Trees), to somewhere in your Content folder.
   
4. Select the XML files, open Properties, and set "Copy to destination folder" to "Copy if newer".
   
5. Add the textures. Set the bark textures' content processor to "XNA - Texture (mipmapped)". Leave the leaf texture at "XNA - Sprite".
   
6. In your code, create a ParticleCloudSystem during LoadGraphicsContent.
   
7. Create a TreeGenerator for each tree profile you want to use.
   
8. Use GenerateTreeMesh to generate a tree.
   
9. Set TreeMesh.Trunk.Projection to the projection matrix.
   
10. Use TreeMesh.Trunk.Draw and TreeMesh.Leaves.Draw to draw the tree.

For those interested in creating their own tree profiles, I wrote a small tutorial you can use, and the XML format is not that hard to guess by looking at the existing profiles. If you do make a new tree profile, I would be very happy if you would post it here for everyone to see :)

• XNATrees project at CodePlex
• Download XNATrees Source
• Download XNATrees Demo Program (standalone)
  

Comments are more than welcome. I hope this was the right forum to post in - none of the others seemed to fit this kind of post.

I feel humbled yet again.  That is simply amazing!  Thanks for the amazingly generous share!

Wow thats some fantastic work right there.

Good job.   

...You could make money off of that, you know.

Wow. That's fabulous. This is when the "community" side of the "XNA community" comes through... when people provide stuff as cool as that for free. Gives me a warm, glowy feeling inside.

Very nice. Thanks for sharing this.

This looks really cool - I don't think I've seen a tree component yet. Yay!

If you feel so inclined CodePlex is a very easy site to use for adding Wiki-Style tutorials, screenshots, releases, source code, etc... Pretty much everything you have in this post.

In the words of the immortal Keanu...  "Whoaa!"

Nicely done.

Hot Stuff!

I haven't looked deeper into it yet: Does this support (hardware | shader) instancing, or does it output some sort of Model file? If the latter, then that'd be fine, too.

I'm not sure what you mean by instancing. It does not output any file - by generating a tree you get a TreeModel object, with the tree's mesh and its leaves, ready for rendering. If you look at the example I think you will easily find your answer, though.

it Works very well, good job,

but if vou want to make it work in france (like me ) replace all "."  by "," in all xml files....


thanks

Wow, this is just what i have been lokking for :D. I just have one problem. After adding your trees to my game, all my models and terrain started to look funny. I think this part of your shader creates the problem

AlphaTestEnable = false;

AlphaBlendEnable = true;

BlendOp = Add;

DestBlend = InvSrcAlpha;

SrcBlend = SrcAlpha;

CullMode = None;

ZWriteEnable = false;

How can this be fixed?

Just enable the depth buffer again and disable alpha blending in your component's draw code.

I have now created a project on CodePlex named XNATrees, like John suggested. The CodePlex Client was a hell to set up, but I got it working. The license had to be changed to MIT License since CodePlex does not like ZLib :(

@Chicou:
Thank you for bringing this to my attention. I have added that to the issue tracker at the CodePlex project, and I hope to fix it soon.

@steffenp:
This is generally a problem in XNA - it has no mechanism for saving the current renderstate (as far as I know). It would be nice with a way to "push" the current renderstate, kind of like glPushAttrib that OpenGL programmers probably are familiar with - but for now you just have to set it all back manually, like Melvil suggested.

Very cool stuff! I look forward to making my own trees! Thanks for the hard work! Keep us updated with changes.

I'm not sure if this is possible because I haven't yet been able to get into this deeply yet but is it possible to keep the same tree permanently after it has been generated? If not I think serialization would be a great solution here. This opens up great modding possibilities like different shrubbery.

Klasker:

This is generally a problem in XNA - it has no mechanism for saving the current renderstate (as far as I know).

Sure there is: this is what the StateBlock class does.

There are just two problems with using StateBlock, though:

• Saving and restoring all render states is SLOOOOW!
• Saving and restoring all state doesn't actually solve anything in any case. Or rather, it doesn't solve the general problem. It is a good solution for just two components ("A messes up B, so get A to save and restore the states needed by B"), but it does not scale at all as soon as you add a third component ("A messes up B, then C wants a third set of states, so now what ought A to restore when it is done?").
  

It is better (both faster and more scalable) to just explicitly set whatever states you need before each piece of drawing code.

@Caetris:
All you need is the random seed. If you generate a tree using profile X and the seed 12345, you will always get that same tree with profile X and seed 12345, on any computer at any time. The only possible exception to this is if you move a new version of XNATrees.

I'm surprised that Shawn Hargreaves didn't mention this, as I found it a fascinating read recently, and surely can provide some interesting thoughts about the problem mentioned by steffanp : Bitfield renderstates

An updated version is available, which fixes the issue with systems using comma as decimal separator.

Klasker

Firstly, this is awsome.  I've integrated your trees into OctaneX, the second beta for which we'll be releasing over this weekend.  So thanks!

However

I've found a small, but rather significant problem, which I'm not sure how to fix.  I need to scale the trees down to about 0.05 of their starting size to make them fit my game. 

However, the problem is that the leaves don't scale with the tree trunk, so I end up with a big green ball of BIG leaves in my scene, and I can't see the tree (if I don't render the leaves I can see the scaled tree fine).

Same in reverse, if you scale the tree up, then the leaves look tiny.

Any chance you can take a look at this problem when you get a chance?  I think it lies in the particle cloud FX file, as I've had a root through the project code and can't see anything else that might be making this happen (I'm not too ofay with shaders atm, I leave that to Nemo).

Thanks.  And I'll obviously be sticking your name in the credits for OctaneX from now on!

 

Yes, I'm getting the same problem. I'm having to scale my trees down to 0.02 to fit in my game world (scale of metres) and that works fine for the trunk, but not the leaves - the leaf shader doesn't seem to deal with scale at all.

(I'm also finding that drawing one tree cuts my frame rate from 1300Hz to 100Hz, but I'll have a check for myself to work out why and how to avoid that).

Apart from that, very effective, very easy to get into the game, very well commented code - top stuff!

Andy Patrick:

Yes, I'm getting the same problem. I'm having to scale my trees down to 0.02 to fit in my game world (scale of metres) and that works fine for the trunk, but not the leaves - the leaf shader doesn't seem to deal with scale at all.

Apart from that, very effective, very easy to get into the game, very well commented code - top stuff!

Cool, glad it's not just me, I thought maybe I was doing something wrong :-)

Klasker, really can't wait to see an update to this component, it's awsome.

 

Version 1.2 is now available which should fix the problem of leaves not scaling.

Uniform scales are now supported, but non-uniform scales are not. The reason is that billboards do not really have a sensible reaction to non-uniform scales if they are to face the camera at all times. I walked the middle-ground by simply using the WorldView matrix's X-scale and assuming that the matrix is scaled unifomly using that scale.

If you are making water reflections of the trees using a negative Y-scale, this might give you problems, but I think you should be ok as long as the absolute Y-scale is equal to the X-scale (e.g. 0.05 and -0.05 should work).

And by the way, thank you all for your comments (and bug reports). I appreciate the feedback.

That sorted it - brilliant, and thanks!

Any comments on perf? I've not profiled it to see which bits are taking up time yet, but from 1300Hz to 100Hz to draw one tree is a serious hit. I'll let you know what I find as I investigate more, of course.