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. I'm not terribly familiar with this bit of the code, so I'd like to jot down a couple of my thoughts here in the hope that someone will correct or advise me before I go to far wrong!
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. 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. I suspect that this means paging from disk to memory using a separate thread, before handing over to the render thread to send it to the card. As I say, I've had a poke around in the code a bit. I don't think the first is too difficult, if the current approach of not ditching unused textures from memory is used to start with. The tile management code which knows about positions etc is in FG, whereas the material management code which doesn't lives in SG. As far as I can see, two approaches to the problem look feasable. The first is for the material library manager to know about the hierarchy of searching described earlier, and presumably something about the tile number of where the current material name of interest is from, and to do the hierachical search. This could get really ugly when it comes to tiles from non-default scenery trees (JoeBloggs etc) since then the materials code couldn't rely on the bucket coding, but would have to either check or be told where a particular tile came from. The second is for the tilemanager to maintain a number of material libraries for each recursive level for which materials files are found, and then do the hiearchical searching through them in order until the material was found. Obviously only the global one would be allowed to generate the default lighting! I *think* I prefer the second approach of multiple matlibs, but I'd *really* appreciate some comment on that point before starting anything. As for the second point, handling more textures than can fit in memory, that's just going to be plain hard, especially if done as a separate thread, since the raw object loading is done down in leaf.cxx, where its mixed up with plib structures that must be kept in the render thread. I think I'll maybe tackle the first bit first!! The last Friday before Christmas was probably the wrong time to post this, but any comments would be appreciated. Especially one from someone saying they've already done it and just need to tidy the code and post it so I don't need to bother :-) Cheers - Dave _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
