James Turner wrote:
> On 30 Mar 2010, at 16:46, Frederic Bouvier wrote:
>
>> What about putting subset of the current materials.xml inside the
>> scenery tree ? The material library could search either, in that order :
>> 1- ./tile.mat.xml ( along with tile.stg and tile.btg.gz )
>> 2- ./materials.xml (shared for the 1x1 area )
>> 3- ../materials.xml (shared for the 10x10 area )
>> 4- $FG_ROOT/materials.xml
>
> Interesting idea - I await Stuart and Martin's opinions with interest!
I think we're having plenty of options to add whichever sort of
'marker' based on the specific geographic region of where a tile
'lives'. One that we or at least I have been thinking about is to
diversify the material type at build time, 'simply' by altering the
material name strings in the tile.
This _could_ be done via a simple suffix to the material name which
gets resolved by distinct entries in the 'materials.xml'. Or
differently .... ;-)
Aside from that I'd generally prefer to use a technique that allows us
to carry specific material and/or surface conditions inside the scenery
tile via some extended metadata set - not right now, but the next time
we're touching the terrain file format - without having to predefine
every possible characteristic in the Base Package. If' we'd keep this
in mind as an option, then the consequence - as far as I see - would be
_not_ to hardwire the diversification into the FlightGear core.
Adding or changing some material name suffix (or prefix or whatever)
automatically at build time could, btw., be scripted into the toolchain
we already have. We just need to define a set of geographic regions.
The biggest difficulty, to my opinion, is to realize some sort of
smooth transition, since the real-live vegetation isn't cut into
rectangular tiles ;-)
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
