sort the terrain polygons and tree shadows by depth (distance from camera)
draw far objects first
this way, if a hill is in front of some shadows, it gets drawn on top of them.

Quote:Original post by daniel_i_l
Anyone? And isn't there a way to do it without the stencil buffer? For example, is it possible to color the texture on only one side, or make the side oppisite the normal not show up?
Thanks.

No, it's not possible. That's what happens when you disable the depth buffer. You have a couple of other options, but I don't think you're going to like them.

As the AP above mentioned, you can simply sort *all* polygons (the trees and the terrain) yourself. This might fix your problem, but it won't be perfect where the shadow polygons intersect the terrain. Sorting by polygon means using a point on the polygon (usually the midpoint) to determine which one to draw first. In an overlapping situation, this is a never-win situation. Even if you did implement it, the performance cost of sorting would be too slow and there is no way you could render the same number of polygons that you have now at the same FPS.

As for the other option, I presume you are drawing your shadows "straight out" -- as in the quad's vertices all have the same Y value? You could adjust the Y vertex of the shadow polygon by checking the height value of the terrain at that X,Z location, so the shadow polygon would never intersect the terrain. If you implemented this, you should re-enable depth testing, and then render: terrain -> tree shadows -> trees. That should hopefully give you the same effect you're looking for.

The only downfall with this method is if a tree is on flat ground but its shadow is on a hill -- the shadow polygon will be rendered floating above the ground. It might look bad, it might not. Depends on how close the camera gets to the ground, I guess.

You can work around that problem by either planning the locations of your trees well so that never happens, or splitting the shadow polygon into multiple pieces so it has less of a chance of being rendered at a noticable angle.

Quote:Original post by bpoint
Even if you did implement it, the performance cost of sorting would be too slow and there is no way you could render the same number of polygons that you have now at the same FPS.

Hello Im the AP

Regarding Sorting,
you can do it, but you have to be clever, otherwise its going to be prohibitively expensive

I'd like to point out, that assuming your terrain is a heightfield, that the polygons in it are *Already Sorted* - the 2d grid structure itself contains order information. While details of distance to camera are not accounted, the rows and columns themselves have an order, and simply ensuring on a row by row basis that rows in front render first, should be enough to cover the overlapping hill problem.
So depending on what direction your camera is facing, you can simply transverse the heightfield in forward or reverse ordered triangle list, to change their effective rendering order. (there are special cases where you might need to do it in two sections with different fwd/rev order, but thats the general idea)

Additionally, since a heightfield is grid based, each tree can be located and tracked as being placed on a cell of this grid. by rendering each tree immediatly after we render its associated heightmap cell, we can apply the 'free' sorting of the heightmap to the trees as well.