Re: Modifying $FG_ROOT/materials (was Re: [Flightgear-devel] Grand Canyon Demo)

[Curtis L. O. <cu...@fl...>]

David Megginson writes:
> In principle, I like to allow as much runtime configurability as
> possible, since it's much easier to experiment with changes at runtime
> than with changes at compile time (you don't end up pouring concrete
> all over your decisions).
> 
> I think that the key here is the materials file.  Right now, we have a
> 1:1 mapping between materials and textures, but it wouldn't be too
> hard to modify the file to specify different textures based on simple,
> nested constraints -- I'd recommend the following:
> 
> 1. Default (if nothing else applies).
> 2. Bounding box (lat/lon).
> 3. Slope range.
> 4. Elevation range.
> 5. Date range.
> 
> The math for calculating the slope of a triangle is pretty simple, and
> we could even pre-calculate it and save it in the scenery files if
> anyone thought that was a problem (I wouldn't waste time doing that at
> first).  For the bounding box and the elevation, we can arbitrarily
> apply it to only one of the triangle's points.
> 
> I think that I can do this in a week or two, though Curt might wake up
> in the morning to find $FG_ROOT/materials changed to
> $FG_ROOT/materials.xml if he's foolish enough to let me go ahead.
> Some clever bucketing at material load time should make this efficient
> even with a large number of alternatives.  My first implementation
> will leave obvious boundaries, but it will still be an improvement
> over 70degree mountain slopes covered in thick forest.

A couple comments.

1. This is interesting ...

2. If you wanted to assign textures to each triangle individually in
the scenery, you will have to break up fans/strips to do it with the
associated performance implications.

3. This stuff looks a lot nicer if you can blend smoothly between the
different texture types.  I'm not sure how that could be easily done
without a regular grid and a lot of transition textures.

4. I'm not sure if the materials file is the best place to handle
this?  Although if we ended up with a materials.xml, I wouldn't
complain about that.

5. If someone is actually going to look into this, they might also
consider how we'd impliment seasonal effects.  Again, I'm not sure if
the materials file is the best place to concentrate all the
configurability and options.  We might want to build some sort of
layer in between with all the actual smarts.

6. It maybe in the future that some scenery designers have picked
specific textures for specific reasons.  We wouldn't want a system
that always overwrote those choices arbitrarily using our own
heuristics.

Regards,

Curt.
-- 
Curtis Olson   Human Factors Research Lab       FlightGear Project
Twin Cities    cu...@hf...                cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org