Hi, I had a busy week, so sorry for the delay.
On Saturday, March 17, 2012 10:07:07 Anders Gidenstam wrote: > I have not had time to consider the proposal carefully, but I agree that > the ocean tiles are problematic in the old (old) scheme if you have > object directories with overlapping objects rather than jaust additional > objects. I have not tested the new changes at all yet. At first, is the current state something you can currently work with? It should stop opening stg files once a base object is hit. > While the (old) new behaviour is as Martin expects it is not what most > that has read Docs/README.scenery would expect (I'd think). However, I > would not consider Docs/README.scenery a normative source (i.e. not how > it should be but rather how it was) - but Martin's expectation (as far as > I know about it) is also not the behaviour I'd like or want. I agree with that. The aim to clean up technically the scenegraph lead me to this area and looking at the implementation I found plenty of stuff that was dangling from the osg switch I think - so the old source could not considerred normative either. I feared that it did much more than it should do. So, I was looking for documentation and somebody who knows about that. What I did at first sounded plausible somehow but missed your needs for your workflow. IOW I can well see the need for reading from more than one directory for your workflow. > In the old old scheme entries in the path could point to just terrain or > just object trees in addition to "full" scenery directories containing > both Terrain, Objects and (more recently) Airports and Models > subdirectories. Both those options are useless with the stop-at-once > behaviour (you get either terrain and no objects or just objects). > > Could a working middle way be to merge objects from path entries > containing only the Objects (and maybe Models) tree encountered before the > first "full" scenery directory for the tile in question? > > That way an ocean tile in a "full" scenery directory would terminate the > search. (How to decide that a scenery directory is "full", that is, > considered to contain both terrain and objects for a particular tile, > may need more thinking). Yes, all boils down to this question. So currently full means 'I have found a BASE_OBJECT'. Which is something that will not happen for sea tiles. So one of the proposals was to be able to explicitly generate sea tiles by putting them into the BASE_OBJECT line. That does not mean that every sea tile must be explicitly triggered, but a sea tile *could* in this model be explicitly triggered to get a propper termination point. This can happen by a <id>.seatile metafile or an other keyword in the stg file for example. > Similar questions most likely arise for the files in the Airports and > Models directories, and for terrain only scenery directories (but there > soft links to the desired Objects, Models and Airports directories may help > to turn a terrain only directory into a "full" scenery directory). > > E.g. for ground net development I would like to be able to have a local > Airports directory (containing just the files I'm working on) that would > be searched before the one in the "full" (e.g. terrasync) scenery > directory. I don't know exactly what happens currently for the Airports directory. But yes I see. This must work the same than the scenery object search as the stg/btg files need to match with the taxiway descriptions. But that means that finding the matching groundnetwork files must also follow the same complex stg file algorithm. Or even more, this one also needs to look *into* the stg files to scan for an OBJECT_BASE line and take the files from the matching Airports directory beside? Do you think it is possible to define 'full' scenery by the plain presence of a Terrain/<id1>/<id2>/<id3>.stg file in the Terrain subdirectory? This would at least reduce the need to look *into* the stg files to barely looking for the existence of an stg file to see where to stop? For the sea tiles this would mean that those tiles with object need a terminating Terrain/... file, sea tiles without dont need anything as it is today. This question is motivated by the scenegraph structure we currently generate. I can imagine improovements to scenery paging with this kind of change. What I want to try is not put individual model files into own level of detail nodes or paged nodes, but put all models in one tile into a single paged osg node. This node is then paged in later/paged out earlier than the bare Terrain node that we need even for far tiles. If I try to do the same with the current semantics, I need to execute the same search sequence by opening the stg files multiple times. Not sure yet I gain something here, but willing to ask if this is at least possible. Ideas? Comments? Thanks Mathias ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
