On Jan 27, 2008 12:50 PM, Tim Moore <[EMAIL PROTECTED]> wrote:
> You've got that right. The approach I'm taking in integrating Stuart's
> work is to not
> depth-sort the trees at all. Instead:
>
> crank the alpha test value up
> draw the trees after the terrain so the sky doesn't appear to poke through
> the terrain.
That's a good point. If the terrain is drawn first, then the blue-sky
fringe around the trees will all but go away.
Ultimately we might want to change the tree texture maps a bit.
Definitely ... we could vary them in shape and appearance, not just color.
There is much that can be done.
(I haven't dug much in the code for these trees, but ...) it appears that
the random locations are computed as areas come into view (or come close
enough to the viewer.) So each time a new chunk of trees are added, I see a
blip in the frame rates. If there are a lot of chunks that need to be
added, that translates into a lot of blips. Would it be possible to compute
the locations of the trees when the tile is loaded (in the load thread) and
always have these structures available when needed? Now that we can have
such wide tree coverage, we'll be burning the memory for these structures
anyway. Previously, David's code only built the random object structures
for areas close by because having all the random object structures for all
the tiles in memory simultaneously would be a huge waste. I suspect the
plib based random object scene graph structures were much more wasteful than
the structures needed by the OSG shader based approach.
Regards,
Curt.
--
Curtis Olson: http://baron.flightgear.org/~curt/
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
