--- Tim Moore wrote:
> Curtis Olson wrote:
> | Definitely ... we could vary them in shape and appearance, not just
> | color. There is much that can be done.
Already supported. The current patch allows different shapes and appearance. The
reason that the trees currently just vary by colour is entirely due to my level
of artistic ability.
If you have a look in the data/Textures/Trees/ directory you will see that the
.rgb files are actually a strip of different trees, evenly distributed along the
x-axis. You can change them in any way you want, as long as you ensure that they
are evenly spaced, and you update the <tree-varieties> tag in materials.xml to
match.
In fact, it would be great if someone with some artistic skill could work on the
textures.
You can even vary the distribution of the different tree types by including
similar textures multiple times.
> | (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.
> The locations are computed when the tile is loaded. I think the blips you're
> seeing are
> caused by compiling a new shader program per chunk of trees. That problem
> should go
> away when the code is integrated into cvs.
I think the current patch has already fix this. A single osg::Program which
includes the Shaders is instantiated the first time any trees are generated, and
re-used after that point... unless OSG is doing something particularly silly, or
my code is bugged.
The blips are more likely due to the generation of the huge number of trees when
the tile is loaded. I haven't counted them, but we must be generating hundreds
of
thousands for some tiles.
BTW - the current patch is more efficient in this respect as well.
-Stuart
___________________________________________________________
Yahoo! Answers - Got a question? Someone out there knows the answer. Try it
now.
http://uk.answers.yahoo.com/
-------------------------------------------------------------------------
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
