Tree models available
- Falagard
- OGRE Retired Moderator
- Posts: 2060
- Joined: Thu Feb 26, 2004 12:11 am
- Location: Toronto, Canada
- x 3
- Contact:
Regarding SpeedTree and Prata - yes in theory each tree can be different. In practice you'd never do this because of the vertex buffer memory consumed.
Oblivion only used SpeedTree to generate a predefined set of tree models and didn't use on the fly procedural generation at all - they saved out the tree models as meshes and only had a handful of unique trees in the entire game. I won't go into details, but the mesh format just needs to store specific data for each vertex and then you use a shader to orient the billboards towards the camera and perform leaf rotation for wind shaking the leaves.
That is a nice looking tool by the way
Oblivion only used SpeedTree to generate a predefined set of tree models and didn't use on the fly procedural generation at all - they saved out the tree models as meshes and only had a handful of unique trees in the entire game. I won't go into details, but the mesh format just needs to store specific data for each vertex and then you use a shader to orient the billboards towards the camera and perform leaf rotation for wind shaking the leaves.
That is a nice looking tool by the way
- KungFooMasta
- OGRE Contributor
- Posts: 2087
- Joined: Thu Mar 03, 2005 7:11 am
- Location: WA, USA
- x 16
- Contact:
I think it would be most useful as tree generator that outputs .mesh files. Procedural generation of trees won't work so well in a networked application, especially if 2 clients are in the same scene right next to each other!
The trees look really nice!
So when can we use it? I'm interested!
KungFooMasta
The trees look really nice!
So when can we use it? I'm interested!
KungFooMasta
- KungFooMasta
- OGRE Contributor
- Posts: 2087
- Joined: Thu Mar 03, 2005 7:11 am
- Location: WA, USA
- x 16
- Contact:
-
- Bugbear
- Posts: 807
- Joined: Sun May 14, 2006 2:24 pm
- Location: Melbourne, Australia
- Jabberwocky
- OGRE Moderator
- Posts: 2819
- Joined: Mon Mar 05, 2007 11:17 pm
- Location: Canada
- x 218
- Contact:
That would work, but only if you generated trees in the exact same order. If, for example, you page in your trees based on the movement of the player, your trees would look different as soon as the players split up into different directions and started loading different terrain pages.kneeride wrote:yep random trees will produce the same trees using the same seed.
random generation for online games can be a great saver with bandwidth. ie terrain/trees can be stored and sent over the network as a single seed and then generated on the client
Although I guess you could do something fancy like download a random seed for each different page of trees. Or even base the random seed off the page coordinates. So yeah, it's a good solution - just a little bit tricky.
- Kojack
- OGRE Moderator
- Posts: 7157
- Joined: Sun Jan 25, 2004 7:35 am
- Location: Brisbane, Australia
- x 534
Asheron's Call uses procedural tree placement. Every landscape vertex had a 5 or so bit vegetation field. This field was used as a seed to generate tree and rock placement for the area around the vertex (actual type of trees / shrubs / plants / rocks was also based on terrain type). While the tree meshes were stored locally (not procedural), the actual placement existed only in ram.
Hacking the data for a region of land would cause the trees to be placed differently (and different numbers of them), but the server was still authoritative for collision so you'd collide with invisible trees. As long as the client and server have the same value, it works fine, and should work fine for procedurally generated trees too.
Hacking the data for a region of land would cause the trees to be placed differently (and different numbers of them), but the server was still authoritative for collision so you'd collide with invisible trees. As long as the client and server have the same value, it works fine, and should work fine for procedurally generated trees too.
- ScurvyKnave
- Gremlin
- Posts: 150
- Joined: Mon Oct 10, 2005 5:57 pm
- Contact:
Thanks for your comments, all.
With regard to random generation of trees... all you need is a single int value to seed the generator before generating the tree, using the same value always yields the same results. But creating an algorithm that generates nice looking trees is not easy, and even if you manage to do so, the results all tend to look fairly similar.
As was already mentioned, having 1000s of trees existing simultaneously is not feasible due to vertex buffer memory constraints. Disk space is not a concern, whereas efficient use of memory is, so storing many meshes on disk is really not a problem (compared to other game resources, meshes are tiny anyway), so the argument that we need to generate game assets on the fly to converse disk space is not really valid.
In my opinion, pure procedural generation is not the answer. I allow the user to guide the process by drawing a 2D 'template', and I convert the results to 3D (one can alter the results produced by modifying the seed in the application).
Am still deciding which course to pursue. Personally, I like the idea of simply exporting meshes. Then again, some sort of plugin that handles trees (and maybe other foliage), could be nice, but possibly not necessary (it would probably have to make some assumptions about how your scene is structured, which would limit its usefulness).
I'm thinking the best course of action is just to finish the editor, have it export meshes, and then include a demo that makes use of these. The demo would include code that does a lot of the management for you, so people could simply incorporate the code into their own projects if they wanted to, but would not be forced to do so.
Assuming I adopt this approach, I'm not entirely sure that releasing the source code would really benefit anybody at this stage, but I'm open to suggestion.
Regarding licensing, am still considering (will definitely be free for non-commercial use though).
How many polys per tree? Well, the first two screenshots were from my old version, where I still used billboards for leaves. On average about 500 triangles, and about 100 billboards or so per tree. I got very decent framerates using this approach. I find that using a straightforward approach of an entity for the trunk / branch structure and one billboard set per tree for the leaves gave good performance. Friends I've shown have commented that the vegetation in my forest demos is very thick and nice-looking, and I achieved decent frame-rates even without LOD reduction or replacing distant trees with billboards. In other words, even all-out brute force rendering of an excessive number of trees didn't bring my system to its knees.
The screenshots at the bottom (just the tree by itself) are from the newer version, and I used about 1000 triangles for the trunk / branches and another 1000 for the leaves - a bit excessive, I know, but it's easy to lower that in the editor (simply drag a slider and click 'generate').
With regard to random generation of trees... all you need is a single int value to seed the generator before generating the tree, using the same value always yields the same results. But creating an algorithm that generates nice looking trees is not easy, and even if you manage to do so, the results all tend to look fairly similar.
As was already mentioned, having 1000s of trees existing simultaneously is not feasible due to vertex buffer memory constraints. Disk space is not a concern, whereas efficient use of memory is, so storing many meshes on disk is really not a problem (compared to other game resources, meshes are tiny anyway), so the argument that we need to generate game assets on the fly to converse disk space is not really valid.
In my opinion, pure procedural generation is not the answer. I allow the user to guide the process by drawing a 2D 'template', and I convert the results to 3D (one can alter the results produced by modifying the seed in the application).
Am still deciding which course to pursue. Personally, I like the idea of simply exporting meshes. Then again, some sort of plugin that handles trees (and maybe other foliage), could be nice, but possibly not necessary (it would probably have to make some assumptions about how your scene is structured, which would limit its usefulness).
I'm thinking the best course of action is just to finish the editor, have it export meshes, and then include a demo that makes use of these. The demo would include code that does a lot of the management for you, so people could simply incorporate the code into their own projects if they wanted to, but would not be forced to do so.
Assuming I adopt this approach, I'm not entirely sure that releasing the source code would really benefit anybody at this stage, but I'm open to suggestion.
Regarding licensing, am still considering (will definitely be free for non-commercial use though).
How many polys per tree? Well, the first two screenshots were from my old version, where I still used billboards for leaves. On average about 500 triangles, and about 100 billboards or so per tree. I got very decent framerates using this approach. I find that using a straightforward approach of an entity for the trunk / branch structure and one billboard set per tree for the leaves gave good performance. Friends I've shown have commented that the vegetation in my forest demos is very thick and nice-looking, and I achieved decent frame-rates even without LOD reduction or replacing distant trees with billboards. In other words, even all-out brute force rendering of an excessive number of trees didn't bring my system to its knees.
The screenshots at the bottom (just the tree by itself) are from the newer version, and I used about 1000 triangles for the trunk / branches and another 1000 for the leaves - a bit excessive, I know, but it's easy to lower that in the editor (simply drag a slider and click 'generate').