David Luff writes: > > I've been having a poke about at the scenery and material managers with a > view to attempting to get dynamic scenery texture paging working at some > point.
> There's two things that the scenery management code can't (I don't think, > anyway) do now, that I'd like it to be able to do. The first is to be able > to overide the default texture for a local area. Eg MixedCrop might point > to one texture in the global materials file in FG_ROOT, but to another in > w010n50, which overrides it for that chunk. This could then be extended to > 1x1 deg minichunks, and even to tile level if required. Likewise, custom > scenery designers could put their own materials file in the base directory > for their scenery, and in the local area's subdirectories. An example > search path for a material name found in > JoeBloggsSceneryLtd/w010n50/w002n52/2925459.btg.gz might be: > > JoeBloggsSceneryLtd/w010n50/w002n52/2925459.xml > JoeBloggsSceneryLtd/w010n50/w002n52/materials.xml > JoeBloggsSceneryLtd/w010n50/materials.xml > JoeBloggsSceneryLtd/materials.xml > FG_ROOT/Scenery/w010n50/w002n52/2925459.xml > FG_ROOT/Scenery/w010n50/w002n52/materials.xml > FG_ROOT/Scenery/w010n50/materials.xml > FG_ROOT/Scenery/materials.xml > Red and white chequers! > > with the texture taken from the first matching instance found, and > FG_ROOT/Scenery being assumed to be specified as the default scenery path > in this instance. Ah.. the light shines in Britain too :-) http://baron.me.umn.edu/pipermail/flightgear-devel/2002-August/009981.html > The second thing is that I'd like it to be able to page textures in and out > efficiently at a fairly high rate when extensive areas of unique textures > are used, ie. to be able to keep up with the texture paging required for > photographic scenery. See link above Cheers Norman _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
