Making trees

Amorya
Unregistered
 
Post: #61
Is there a downloadable demo for this? I had a glance through the thread and couldn't see one, but I may have missed it...
Quote this message in a reply
Member
Posts: 29
Joined: 2004.11
Post: #62
This looks amazing? Do you have any dev tools, etc for building levels or is it just a scenery engine at this point. I would love to see a game made in this!

Ghost

P.S. A Downloadable build would be nice......
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #63
NicholasFrancis Wrote:That looks nice. I'm really impressed with how waterlike you can make the waves look by doing a signed add of two ocean ripple textures. Could I get you to share some insights on how you perturb the texture coords? I would like to include something like it in Unity as a low-end water shader

Woo!

Well, it's actually really crude. Here's a 1000 foot view of how it's put together. I have a main class called "Water" which is a non-drawing entity, added to the world. The Water maintains the vertex mesh and manages the textures and overall state ( like the wave function ).

I then have 3 classes which draw the water. Water::Cell, which draws the solid geometry, Water::ReflectionCell which draws the cubemap ( as second pass ) and Water::EdgeCell which draws the foam at the edges. Each is a drawing GraphEntity, which means it's a first-class AABB bounded entity in the SceneGraphs.

I build them by creating "patches" ( which are just a struct with indices for the vertex arrays and so on ) from the water vertices and adding those patches to the cells, with jiggery pokery to create cells and add them to the scenegraph when needed ( based on the bounding box of the uniono f the cell's patches ) and to add patches to existing cells when a cell's already in the scenegraph.

This way I get my water drawing fully managed by the scenegraph but only one object, the "Water" instance, manages the memory.

The cells have an ordering override to the scenegraphs visibility set determination that causes them to be sorted and drawn in this order:

Water::Cells get drawn first
Water::EdgeCells get drawn second
Water::ReflectionCells get drawn last

My VisibilitySet class sorts objects such that objects which report requiring the same gl state to display are contiguous, so I can minimize state changes when drawing batches of similar objects. But their respective "drawing order" is still respected.

When any are drawn, the notify the Water object that it needs to update the wave function. It then calls updateGeometry on the cells, only the base class Water::Cell actualy modifies the geometry but it updates the vertex arrays for the subset of the water that is visible.

Regarding the texture coords, I actually just have two add-signed units with a pretty decent texture I drew in photoshop ( using Ocean Ripple filter on a perlin noise background, then duplicate the layer, invert it, gaussian blur it, than set opacity to 50% -- this gives me a good detail image with no low-frequency patterning -- which I then merged and clone-stamped until it wrapped nicely ).

The two texture units both draw the same image, texgenned along XY, with offset varrying along with the wave function.

The cubemap is just a vanilla cubemap, but I scale the vertex normals z-values by 0.5 before normalizing so I get a more visible rippling.

I'll post code soon, but it's not complicated. Really, it's just a matter of good textures and good choises of color. There's a lot going on with color to cause "reflection" of the sky color, a lot of code...
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #64
OK, I was (mostly) away from the internet for the holidays, but now I'm back. Here's the source for the water in case you're still interested, Nicholas.

http://zakariya.net/shamyl/Water/src/

The main class Water has several inner classes, which are defined in Water.h but are implemented in the files Water_innerclassname.cpp.

There's a fair amount of magic behind the scenes being done by my scenegraphs and that code isn't included, but will be when I'm ready. 99% of the important stuff for low-end display is in Water_Cell.cpp's setupState() and updateGeometry() methods.
Quote this message in a reply
Member
Posts: 47
Joined: 2004.07
Post: #65
Nice Code... If only all of Unity was so easy to read ;-)

It's weird that you get such a good effect using only texgen... I'm impressed...

I know you didn't ask for any advice (and don't really seem to need it, either), but have you considered moving all glTexParameter calls into your Texture class? The thing is that these stick with the texture you're applying them to. Hence, you don't need to set them anew each time you want to use the texture, saving quite a few OpenGL calls....

Doing this in Unity allowed us to clear up a lot of code - at first, I was sceptical of not being able to change texParameter calls between uses of a texture, but when I thought of it, I could think of only pathological cases where I'd want to do that.

Nicholas Francis
http://www.otee.dk
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #66
NicholasFrancis Wrote:Nice Code... If only all of Unity was so easy to read ;-)

Thanks!

Quote:It's weird that you get such a good effect using only texgen... I'm impressed...

I appreciate the sentiment, but frankly, it still looks like ass compared to a proper system using shaders and real reflections. But, I just don't care that much since my powerbook has a 5200 and it simply doesn't have the horsepower.

Quote:I know you didn't ask for any advice (and don't really seem to need it, either), but have you considered moving all glTexParameter calls into your Texture class? The thing is that these stick with the texture you're applying them to. Hence, you don't need to set them anew each time you want to use the texture, saving quite a few OpenGL calls....

Doing this in Unity allowed us to clear up a lot of code - at first, I was sceptical of not being able to change texParameter calls between uses of a texture, but when I thought of it, I could think of only pathological cases where I'd want to do that.

Yeah, that's something that I've spent quite some time in consideration of. My issue is that when I try to clean it up, I often end of with weird artifacts where some tex unit is using spheremapping or something else weird because a previous display routine didn't clean up properly.

Obviously, I should clean up better, and I *do* try to. But since I'm a neophyte in GL, I've had better luck with completely excplicity setup and teardown, and I trust in my scenegraph to sort the display of objects to minimize the need to call setupState and teardownState. Which is to say, if in a scene I've got 20 Water::Cell instances to display, my scenegraph will display them contiguously, and only call Water::Cell::setupState and Water::Cell::teardownState once.

Fortunately, I've got a basic interface ( from which GraphEntity derives ) called SimpleSetDrawable which will automatically generate unique GL state identifiers for entities based on how they want to display ( based on a basic set of drawing features, like primary texture, detail texture, shading model, litghting, fogging, transparency, blend modes, etc etc etc ). So, I can have 100 trees using one set of bark and leaf textures, 100 more using other textures, 500 rocks using one texture and detail, and the scenegraph ( after determining the visible set ) will only have to run setupState and teardownState 3 times -- it's all automatic ( and fast, too, since the STL set algorithms rock ).
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #67
New trees!

I finally accepted that my foliage algorithm for the trees sucked, and I made a *much* better version this morning. I also, finally, made a proper texture for leaves.

[Image: Screenshots-2006-01-05-01.png]
[Image: Screenshots-2006-01-05-03.png]
[Image: Screenshots-2006-01-05-04.png]

Finally beginning to actually look like a tree... Rasp
Quote this message in a reply
Moderator
Posts: 384
Joined: 2002.08
Post: #68
Just lovely.

Has the poly count increased a lot with this algorithm? Seems like a lot more geometry on the tree, but maybe not.

KB Productions, Car Care for iPhone/iPod Touch
@karlbecker_com
All too often, art is simply the loss of practicality.
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #69
It has -- I went from a triangular cross-section to octagonal. The number of leaves is up a little, but not too much. A well populated tree has, perhaps, 25 to 50% more leaves than before.

I'm planning on having the trees store a low-poly variant ( generated off the same seed, but using triangular cross section like before ) for drawing at a distance.
Quote this message in a reply
Moderator
Posts: 916
Joined: 2002.10
Post: #70
*cries and paws at the trees*

so beautiful
Quote this message in a reply
Member
Posts: 47
Joined: 2004.07
Post: #71
Looks nice - a few suggestions:
Precalculate world vertex lighting. Since the world lighting is not going to change, you can get more polies in if you precalc the lights. Not a huge benefit in itself, but does lend the way to this:

Implement self-shadowing. For each vertex, cast a ray towards the sun. Make the branch block the ray and each leaf reduce the lighting by a certain percentage. While seemingly minor, leaf self-shadowing makes a huge difference to the percieved depth of the tree.

Have you considered billboarding the trees. The have a great trick in Far Cry: You're not allowed to rotate the trees. This means that all trees of a given type are seen from the same direction (as they are very far away). This works really well and keeps the billboard numbers down. Also, allowing scaling of trees will give you a lot of variety without having to store the meshes. Scaling doesn't affect billboarding.

You could still rotate trees, though.. AFAICS from their editor, they split trees into 2 types: Clumps of trees (for forests) or smaller (let's call them "key" trees). Key Trees were just normal meshes.

Nicholas Francis
http://www.otee.dk
Quote this message in a reply
Member
Posts: 196
Joined: 2003.10
Post: #72
Just gorgeous. More screenshots, more often!

*can't wait for gameplay*
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #73
NicholasFrancis Wrote:Looks nice - a few suggestions:
Precalculate world vertex lighting. Since the world lighting is not going to change, you can get more polies in if you precalc the lights. Not a huge benefit in itself, but does lend the way to this:

Implement self-shadowing. For each vertex, cast a ray towards the sun. Make the branch block the ray and each leaf reduce the lighting by a certain percentage. While seemingly minor, leaf self-shadowing makes a huge difference to the percieved depth of the tree.

Trouble is this -- the tree's are "cloneable" in that I can have 500 trees share one geometry, collision mesh, and foliage instance. Meaning I have to have dynamic lighting in the foliage. I will probably, however, lrp the leaf color to ambient based on its depth in the tree.

Quote:Have you considered billboarding the trees. The have a great trick in Far Cry: You're not allowed to rotate the trees. This means that all trees of a given type are seen from the same direction (as they are very far away). This works really well and keeps the billboard numbers down. Also, allowing scaling of trees will give you a lot of variety without having to store the meshes. Scaling doesn't affect billboarding.

You could still rotate trees, though.. AFAICS from their editor, they split trees into 2 types: Clumps of trees (for forests) or smaller (let's call them "key" trees). Key Trees were just normal meshes.

I'm considering it, actually. Performance is hit real bad when I've got a lot of trees, even though the scenegraph culls most of them and draws them sans texturing or lighting if they're beyond the fog plane.
Quote this message in a reply
Moderator
Posts: 1,560
Joined: 2003.10
Post: #74
Looking really good from the trunk up, but I think it would add a lot if you would do something to the ground around the trunk to make it more believable. A few roots visible here and there, transition from grass to dirt closer to the trunk, etc.
Quote this message in a reply
DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #75
Awesome trees. I like the whole GUI, can you elaborate a bit on how the interface is implemented?

Two years ago, when I was doing my BSc, a group doing computer graphics in the same lab where I was working were making large forests with billboarding. I remember they had whole forests running in real-time.

They came up with stuff like this:
http://www.iit.bme.hu/~szirmay/tree2.pdf
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  3d trees for game spinner 5 7,296 Oct 25, 2006 06:34 AM
Last Post: spinner