On Mon, 11 Feb 2008 10:05:20 +0000 (GMT) Stuart Buchanan wrote: > > I have been thinking for a while that it would be good to have some way > to have a finer granularity within materials.xml. > > For example: > - Towns and villages in different countries/continents are quite > different in terms of the buildings, and it would be good to reflect > this. > - Tropical forests are quite different from that of temperate climates > - I did a virtual flight over Denali recently, and due to the > limitations of the current terrain definitions, large parts of it were > "forest".
I've wanted this for years. There's more, too. For instance, farmland
looks different in different countries -- when we went to the more
photorealistic textures a couple of years ago, we dumped a texture
that I think Erik Hofman had created for farmland that, on one hand,
looked less like a photo and more like art, but on the other hand, looked
*much* more like farmland as you would see it in England and parts of
northern Europe. And I remember Paul Surgeon creating one that looked
*exactly* like farmland in places like Indiana/Illinois/Iowa, but not
like in the western U.S. and definitely not outside the U.S. Middle
Eastern/central Asian cities look different than western ones. And
there ought to be different parts of cities -- the types of buildings
you see in the inner city (and their frequency) should be different
from the types you see in suburbs, and both sets should be different
in different places around the world.
The problem is . . .
> I think that as well as a property defining the season, it would be
> good to have a set of properties based on the geographical region, for
> example:
>
> /sim/geography/continent (africa, europe...)
> /sim/geography/climate (tropical, temperate, arctic...)
>
> I'm sure we can think of some more.
>
> If we could define these regions based on lat/lon (in an XML file?), FG
> could set them, and they could be easily used within materials.xml.
. . .I don't think defining by lat/lon is sufficient. I guess some of
these issues could be improved that way; but lines of constant latitude
or longitude aren't really correct, even for the ones they would improve.
The region boundaries won't look realistic.
The right way to do it is to use GIS data in TerraGear, and to expand
the groundcover types coming out of TerraGear. Once upon a time, it was
actually in the works to start creating those groundcover types/material
definitions, in advance of actually labelling ground polys with them in
TerraGear, so that people could experiment with setting them in fgsd;
but I was gone for a while and I don't know what the status of any of
that is now.
-c
--
Chris Metzler [EMAIL PROTECTED]
(remove "snip-me." to email)
"As a child I understood how to give; I have forgotten this grace since I
have become civilized." - Chief Luther Standing Bear
signature.asc
Description: PGP signature
------------------------------------------------------------------------- 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
