Re: [Flightgear-devel] scenery loading cleanup
Hi, On Saturday, March 24, 2012 09:29:41 James Turner wrote: > Tangental, but, yes please! > > This and a few other similar options, like generating a low-detail terrain > node 'automatically' for distant tiles, were some ideas I considered last > year to allow further draw distances. Yes, the spt loader does this currently. but the lower level of details still lacks altitude information. And the basic texture is just the croase whole world texture even in the mid lod case. That's what I currently use for developing a seperate hla viewer that can be attached to any hla object. I can currently safely sit on top of the ogel generated on the sphere in san diego flying over LOWI. Works fine here :) So, short, I have never described the spt loader, but it is able to provide a scalable whole world paged scenery. This is similar to google earth or osg's marble or the like. The scenegraph is done with a quadtree/octree structure that in the end fits our tile structure of stg files. That should be fast to cull. We have currently three levels of detail one of which with the recently added earth texture and croaser tiles. One in between that still uses the same texture but should use a set of higher detailed ones in the future. and the third level then contains the stg files. So what needs to be done here is provide a set of earth textures for the mid level of detail together with may be associated altitude textures for both lod's. Then extend the croase ground tile implementation either in a vertex shader or in static load time geometry generation to make use of the altitude information. This could in a next step replace the high detailed btg/stg tiles for far away tiles. And this should build the ground work for seriously enable using really high detailed btg files but still being scalable. All that would then need a lot of tuning and improovements the high detail scenery so that paging happens smooth. Well, I for myself do not plan to work on this in the near future but this could just be a sketch of how this could be extended probably somehow easy. Whoever wants to work on that please stay in touch with me, as I already have a lot of hooks in place. Greetings 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
Re: [Flightgear-devel] scenery loading cleanup
On 24 Mar 2012, at 08:54, Mathias Fröhlich wrote: > 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. Tangental, but, yes please! This and a few other similar options, like generating a low-detail terrain node 'automatically' for distant tiles, were some ideas I considered last year to allow further draw distances. James -- 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
Re: [Flightgear-devel] scenery loading cleanup
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 .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///.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: T
Re: [Flightgear-devel] scenery loading cleanup
Hi Jon, On Tuesday, March 20, 2012 17:27:52 Jon Stockill wrote: > Except a bunch of scenery developers pointing out it completely breaks > their method of working. > > Merging the work into an existing tree isn't really an option - the > ability to completely erase a tree and rebuild by script during testing > is pretty much essential. I think, the current checked in version should address this problem. At least I think I have addressed this. Please, tell me if I have still missed something? 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
Re: [Flightgear-devel] scenery loading cleanup
On Thu, 15 Mar 2012 18:38:34 +0100, Mathias Fröhlich wrote: > Good Evening, > > Ok, no feedback to my comments here except Martin who tells me that > the > current checked in version behaves as expected. Except a bunch of scenery developers pointing out it completely breaks their method of working. Merging the work into an existing tree isn't really an option - the ability to completely erase a tree and rebuild by script during testing is pretty much essential. > I personally can understand that people want to have a local > seperated > directory for their own personal additions. Let it be additions to > the scenery > that are just being developed and not yet ready or may be just the > personal > garden gnome before your house that you are living in. > > OTOH, reestablishing a completely unterminated accumulation behavior > like we > had before is problematic IMO since you will get duplicated models > for really common use cases. A discussion with a number of scenery developers resulted in *nobody* ever having experienced what you describe, and I suspect the setups we use are prime candidates for causing it. Alternatively we've read the documentation and done something to avoid this (though precisely what I honestly have no idea). In trying to duplicate the problem the only scenario we could come up with to result in what you describe was including the same objects tree twice in the scenery path before any terrain. I really don't know what to suggest. -- Jon Stockill li...@stockill.net -- 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
Re: [Flightgear-devel] scenery loading cleanup
I fully agree with Jacob. I thought that is why we have seperate Terrain/Object/Airport folders in the first place... Eric On 03/17/2012 11:15 PM, Jacob Burbach wrote: > On Sat, Mar 17, 2012 at 4:57 PM, Martin Spott wrote: > >> Anders Gidenstam wrote: >> >> >>> 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. >>> >> Well, to put it a bit harsh, if you ask every user, you'll probably >> have to implement two dozend exceptions from the rule. This doesn't >> make neither the developer happy nor the users, because it's getting >> too confusing - and the same users will start complaining again >> >> Let me explain it this way: >> Nowadays we/you are confronted with a steadily growing number of >> private Sceneries. There might be a scenario for France, one for Great >> Britain, one for Germany and, because everybody needs to have their own >> Scenery kingdom and these were the only ones left, one for BeNeLux and >> one for Denmark. Because it's easier to maintain, the boundaries of >> all these scenarios are aligned with full degrees. All these scenarios >> are added to the scenery path. >> Now think of an item which is situated somewhere in the German Bight in >> a tile which doesn't have terrain, how often is every single windmill, >> oil rig, buoy, light ship or whatever else going to be drawn in >> FlightGear ? ;-) >> >> Therefore I'd say the only really consistent way of dealing with the >> scenery path is to stop searching the path whenever a terrain _or_ an >> object tile is found in a scenery path item. >> > Seems logical to me that objects and terrain should be considered > separately. The loader should not stop looking for an object bucket > just because it finds a terrain bucket...and vice versa. The loader > knows what bucket it is looking for, so should just need to look > through each path until it finds the first existing bucket of each > type (or none) and load the data for that bucket/type as appropriate. > Once it has found a particular type of bucket it no longer looks for > it anymore, but continues looking for the other types until it finds > one, or not. Seems simple enough to me, avoids any problem with things > loading twice, and gives a very logical and expected behavior for > loading..no? > > cheers > Jacob > > -- > 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 > > > -- 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
Re: [Flightgear-devel] scenery loading cleanup
On Sat, Mar 17, 2012 at 4:57 PM, Martin Spott wrote: > Anders Gidenstam wrote: > >> 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. > > Well, to put it a bit harsh, if you ask every user, you'll probably > have to implement two dozend exceptions from the rule. This doesn't > make neither the developer happy nor the users, because it's getting > too confusing - and the same users will start complaining again > > Let me explain it this way: > Nowadays we/you are confronted with a steadily growing number of > private Sceneries. There might be a scenario for France, one for Great > Britain, one for Germany and, because everybody needs to have their own > Scenery kingdom and these were the only ones left, one for BeNeLux and > one for Denmark. Because it's easier to maintain, the boundaries of > all these scenarios are aligned with full degrees. All these scenarios > are added to the scenery path. > Now think of an item which is situated somewhere in the German Bight in > a tile which doesn't have terrain, how often is every single windmill, > oil rig, buoy, light ship or whatever else going to be drawn in > FlightGear ? ;-) > > Therefore I'd say the only really consistent way of dealing with the > scenery path is to stop searching the path whenever a terrain _or_ an > object tile is found in a scenery path item. Seems logical to me that objects and terrain should be considered separately. The loader should not stop looking for an object bucket just because it finds a terrain bucket...and vice versa. The loader knows what bucket it is looking for, so should just need to look through each path until it finds the first existing bucket of each type (or none) and load the data for that bucket/type as appropriate. Once it has found a particular type of bucket it no longer looks for it anymore, but continues looking for the other types until it finds one, or not. Seems simple enough to me, avoids any problem with things loading twice, and gives a very logical and expected behavior for loading..no? cheers Jacob -- 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
Re: [Flightgear-devel] scenery loading cleanup
Anders Gidenstam wrote: > 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. Well, to put it a bit harsh, if you ask every user, you'll probably have to implement two dozend exceptions from the rule. This doesn't make neither the developer happy nor the users, because it's getting too confusing - and the same users will start complaining again Let me explain it this way: Nowadays we/you are confronted with a steadily growing number of private Sceneries. There might be a scenario for France, one for Great Britain, one for Germany and, because everybody needs to have their own Scenery kingdom and these were the only ones left, one for BeNeLux and one for Denmark. Because it's easier to maintain, the boundaries of all these scenarios are aligned with full degrees. All these scenarios are added to the scenery path. Now think of an item which is situated somewhere in the German Bight in a tile which doesn't have terrain, how often is every single windmill, oil rig, buoy, light ship or whatever else going to be drawn in FlightGear ? ;-) Therefore I'd say the only really consistent way of dealing with the scenery path is to stop searching the path whenever a terrain _or_ an object tile is found in a scenery path item. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- 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
Re: [Flightgear-devel] scenery loading cleanup
On Thu, 15 Mar 2012, Mathias Fröhlich wrote: Good Evening, Ok, no feedback to my comments here except Martin who tells me that the current checked in version behaves as expected. Hi, 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. 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. 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). 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. Cheers, Anders -- --- Anders Gidenstam WWW: http://gitorious.org/anders-hangar http://www.gidenstam.org/FlightGear/-- 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
Re: [Flightgear-devel] scenery loading cleanup
Good Evening, Ok, no feedback to my comments here except Martin who tells me that the current checked in version behaves as expected. I personally can understand that people want to have a local seperated directory for their own personal additions. Let it be additions to the scenery that are just being developed and not yet ready or may be just the personal garden gnome before your house that you are living in. OTOH, reestablishing a completely unterminated accumulation behavior like we had before is problematic IMO since you will get duplicated models for really common use cases. A terminated read accumulation sequence would help those who complained about the current behavior. Terminating the read accumulation sequence can happen reliably on solid ground with an unmodified scenery. On sea this is not possible without modifications to the scenery that I cannot do myself. So, I will now push something that is IMO not a real solution, since parts of the duplicate model problem is not solved correct. But it should cover most common use cases and enables people like Jon to continue developing scenery models without messing with outside provided files. If somebody wants to change this behavior to something really reilable go ahead. But, since I will do further modification to the implementation of these code areas, please coordinate such changes with me for the next few weeks, else we will probably get needless merge conclicts. Greetings 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
Re: [Flightgear-devel] scenery loading cleanup
Hi, On Sunday, March 11, 2012 21:07:37 Martin Spott wrote: > Mathias Fröhlich wrote: > > The problem is that these sea tiles (Objects/e000n60/e001n61/2975201.stg > > for example) with models never contain a base tile line where we could > > know when to stop seraching the FG_SCENERY directory sequence. > > So for this kind of tiles we could probably place someting into the stg > > file that signals that we should stop seaching here and finish with a > > sea tile. May be we could place a > > > > OBJECT_BASE .seatile > > > > into the above drilling platform stg tile example to terminate the > > search. > It's unclear to me wether you mean adding the above line into the > respective .stg-file in the "Terrain/" folder or into "Objects/" ? > > If you propose to add it into the "Objects/" folder, which is how I > understand your idea, then the procedure to create the "Objects/" > directory structure would be required to know wether there's a terrain > tile or not - a dependency which I'd recommend not to introduce. I could imagine putting this into any stg file. I also have some yet untested code here that implements something like that: for p in FG_SCENERY load p/Objects///.stg load p/Terrain///.stg if found OBJECT_BASE in one of the above break done So, the whole thing is to have a propper termination point where to stop accumulating non disjoint scenery models from different sources probably also not exactly matching the elevation of the loaded base tile. I am more guessing what you mean by that dependency? The current process to export all the collected models for the svn scenery is independent from the knowledge if there is a matching Terrain stg file? And you want to preserve this property? Any solution that gets rid of the ugly duplicated models is good. Better solutions do not introduce even more implicitness into the loading process than we currently have. Any simplification would be good also. Better ideas welcome. Greetings Mathias -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] scenery loading cleanup
Mathias Fröhlich wrote: > The problem is that these sea tiles (Objects/e000n60/e001n61/2975201.stg for > example) with models never contain a base tile line where we could know when > to stop seraching the FG_SCENERY directory sequence. > So for this kind of tiles we could probably place someting into the stg file > that signals that we should stop seaching here and finish with a sea tile. > May be we could place a > > OBJECT_BASE .seatile > > into the above drilling platform stg tile example to terminate the search. It's unclear to me wether you mean adding the above line into the respective .stg-file in the "Terrain/" folder or into "Objects/" ? If you propose to add it into the "Objects/" folder, which is how I understand your idea, then the procedure to create the "Objects/" directory structure would be required to know wether there's a terrain tile or not - a dependency which I'd recommend not to introduce. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] scenery loading cleanup
Anders Gidenstam wrote: > This change breaks my setup. I consider it a feature that FG used > to load objects from all scenery directories visited up until the first > one that contains terrain for the tile. The current item in the scenery path may be defined either by having the requested terrain tile without objects or by having the objects tile without terrain (we're having lightships and buoys without terrain) - or by having both. Therefore if you need to have shared models, just put them into the respective scenery directory where they're being used. Basically by reworking the tile lookup sequence Mathias just fixed a flaw in the loader which wasn't supposed to exist. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] scenery loading cleanup
Hi Mathias, I know a lot of users who use this kind of organisation about scenery folder, and these users aren't "scenery developpers". I think your change will breaks a lot of users configuration with the next release (2.8.0) I'm convinced that your change is a good improvement (if I understand correctly: your changes avoid to read useless folders) and I hope you will find a good compromise. Cheers, Clément -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] scenery loading cleanup
Hi Jon, On Friday, March 09, 2012 10:43:55 Jon Stockill wrote: > Can you explain exactly how the loading now works, and if it's still > possible to use extra local objects trees in the way I describe? Thanks for the response. Well, I guess this hits the same problem that I try to solve now with the previous mail. Greetings Mathias -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] scenery loading cleanup
Hi, On Thursday, March 08, 2012 23:13:56 Clement de l'Hamaide wrote: > Without this little tweaks the tile can't be loaded. In conclusion, with > your change we need to associate Object AND Terrain folder. It's just a > feedback of my experience, don't take it as a critics ;) That's fine. Have written something longer in response to Anders. I think this maches your problem as well. So I guess we are on the way ... Greetings Mathias -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] scenery loading cleanup
Hi,
On Friday, March 09, 2012 21:37:32 Anders Gidenstam wrote:
> This change breaks my setup. I consider it a feature that FG used
> to load objects from all scenery directories visited up until the first
> one that contains terrain for the tile. It made it possible to have
> scenery object directories with extra objects by just putting them early
> in the path (useful not least for keeping work-in-progress object
> placements separate from terrasync data). It appears you removed that.
>
> Can you clarify what the new behaviour is?
>
> Is the first object .stg found for a tile the only one that is loaded now?
The problem with accumulating all stg files' content is that you get duplicate
models.
So the situation that I was trying to fix is as follows:
Assume you have the base package installed and assume you have terragears
scenery installed. Terragear has some improoved models from buildings included
where the older models already are contained in the from the base package.
What you would observe are models that are technically just needlessly drawn
twice and if the models are not identical or may be placed at different
altitudes because of the base tile providing a sightly different ground
elevation you will at best see some kind of z fighting between the two models
and at worst two shifted models in each other with occasionaly z fighting.
You can see this with a lot of buildings in San Francisco.
Now you might argue that I should omit the FG_ROOT/Scenery from FG_SCENERY
since it already contains all that the base package contains. Then I take an
other example with reversed coverage of the scenery:
I have terragear worldwide and the nice innsbruck scenery. And both include
some of the hangars at the airport. You will in this case see that described
z-fighting for the tyrolean writing on the wall of one of the most east airport
buildings.
For the uglyness in the scene and for the needles model duplication for draw I
do not think that we want that.
Ok, the lookup for stg files is as of today:
for path in FG_SCENERY
probe tiles files in path/{Objects,Terrain}///.stg
if one is there, stop probing.
end
Why do I stop at the first found file/file pair:
I got told that some scenery tiles do contain sea tiles there we only have an
Objects directory with offshore windmill models for example. If I do not want
them in the same way duplicated like described above you need to stop at some
point.
With the windmill example I tend to say, ok, let's just duplicate them. We do
not have so much models on the sea. So then we could start accumulating all up
to the point where we find either a base tile or run out of serach path.
But I think a complex oil drilling platform on the northsea breaks this
argument a little.
Ok, I get an idea:
The problem is that these sea tiles (Objects/e000n60/e001n61/2975201.stg for
example) with models never contain a base tile line where we could know when
to stop seraching the FG_SCENERY directory sequence.
So for this kind of tiles we could probably place someting into the stg file
that signals that we should stop seaching here and finish with a sea tile.
May be we could place a
OBJECT_BASE .seatile
into the above drilling platform stg tile example to terminate the search.
An other alternative might be to also probe for a Devel directory structure
for a given scenery path extending the search to
for path in FG_SCENERY
path/{Devel,Objects,Terrain}///.stg
...
An third alternative could be that we explicitly flag stg files that should not
terminate the FG_SCENERY search. So you could just put that flag into your
development stg files.
The first alternative would require modifications to those scenery files, but
it
works today as good/bad as it worked yesterday and it works fine if the
terminating OBJECT_BASE is inserted.
The second one would be a code only change.
The third one would be a change only for those people that develop scenery.
Does this match your concerns? Would it solve? Thoughts?
And sorry for breaking at first ...
Mathias
--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] scenery loading cleanup
On Thu, 8 Mar 2012, Mathias Fröhlich wrote: Hi, Also for the breginning of the development cycle, I started working on improoving fgviewer and cleanup scenery/model loading. I have now checked in a change that should fix some long standing problems with modelss that appear to have z-fighting. This change should not harm and works so far for all I have tested. But it slightly changes the way stg files paths are handled. So if this really introduces a problem, please tell me. Hi, This change breaks my setup. I consider it a feature that FG used to load objects from all scenery directories visited up until the first one that contains terrain for the tile. It made it possible to have scenery object directories with extra objects by just putting them early in the path (useful not least for keeping work-in-progress object placements separate from terrasync data). It appears you removed that. Can you clarify what the new behaviour is? Is the first object .stg found for a tile the only one that is loaded now? Cheers, Anders -- --- Anders Gidenstam WWW: http://gitorious.org/anders-hangar http://www.gidenstam.org/FlightGear/-- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] scenery loading cleanup
On Thu, 8 Mar 2012 23:13:56 +0100, Clement de l'Hamaide wrote: > I've encountered a problem about this change but I fixed it. Some > explanation : > I use 5 sceneries folders and some of them add some data to the > precedent scenery folder. > I use this argument : > > --fg-scenery=/home/clement/Scenery_test:/home/clement/fgdata_paf/Scenery:/home/clement/Scenery_elmaxo:/home/clement/Scenery_papillon81/Scenery:/home/clement/Scenery_italy:/home/clement/Scenery > In order to fly at LFHU (France) I use these data: > ~/fgdata_paf/Scenery/Object/e000n40/e006n45/3056064.stg > ~/Scenery_elmaxo/Terrain/e000n40/e006n45/3056064.stg > ~/Scenery_elmaxo/Terrain/e000n40/e006n45/3056064.btg.gz > ~/Scenery_elmaxo/Terrain/e000n40/e006n45/LFHU.btg.gz > > Since you have changed I need to move associated Terrain in the same > Scenery folder of Object folder. So I copied/pasted Terrain data in > the same Scenery folder contains Objects and now I use these data: > ~/fgdata_paf/Scenery/Object/e000n40/e006n45/3056064.stg > ~/fgdata_paf/Scenery/Terrain/e000n40/e006n45/3056064.stg > ~/fgdata_paf/Scenery/Terrain/e000n40/e006n45/3056064.btg.gz > ~/fgdata_paf/Scenery/Terrain/e000n40/e006n45/LFHU.btg.gz I have something similar in that my scenery path has /export/LocalScenery:/export/Scenery The LocalScenery directory contains only an objects directory which adds extra objects that I'm currently working on. Previously these objects would be displayed along with the objects and terrain from the /export/Scenery directory but now I just get the objects and no terrain. Removing the first directory from the search path brings the terrain back again. Can you explain exactly how the loading now works, and if it's still possible to use extra local objects trees in the way I describe? -- Jon Stockill li...@stockill.net -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] scenery loading cleanup
> Hi, > > Also for the breginning of the development cycle, I started working on > improoving fgviewer and cleanup scenery/model loading. > > I have now checked in a change that should fix some long standing problems > with > modelss that appear to have z-fighting. This change should not harm and works > so far for all I have tested. But it slightly changes the way stg files paths > are handled. > So if this really introduces a problem, please tell me. > > Greetings > > Mathias Hi Mathias, I've encountered a problem about this change but I fixed it. Some explanation : I use 5 sceneries folders and some of them add some data to the precedent scenery folder. I use this argument : --fg-scenery=/home/clement/Scenery_test:/home/clement/fgdata_paf/Scenery:/home/clement/Scenery_elmaxo:/home/clement/Scenery_papillon81/Scenery:/home/clement/Scenery_italy:/home/clement/Scenery In order to fly at LFHU (France) I use these data: ~/fgdata_paf/Scenery/Object/e000n40/e006n45/3056064.stg ~/Scenery_elmaxo/Terrain/e000n40/e006n45/3056064.stg ~/Scenery_elmaxo/Terrain/e000n40/e006n45/3056064.btg.gz ~/Scenery_elmaxo/Terrain/e000n40/e006n45/LFHU.btg.gz Since you have changed I need to move associated Terrain in the same Scenery folder of Object folder. So I copied/pasted Terrain data in the same Scenery folder contains Objects and now I use these data: ~/fgdata_paf/Scenery/Object/e000n40/e006n45/3056064.stg ~/fgdata_paf/Scenery/Terrain/e000n40/e006n45/3056064.stg ~/fgdata_paf/Scenery/Terrain/e000n40/e006n45/3056064.btg.gz ~/fgdata_paf/Scenery/Terrain/e000n40/e006n45/LFHU.btg.gz Without this little tweaks the tile can't be loaded. In conclusion, with your change we need to associate Object AND Terrain folder. It's just a feedback of my experience, don't take it as a critics ;) Cheers, Clément -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] scenery loading cleanup
Hi, Also for the breginning of the development cycle, I started working on improoving fgviewer and cleanup scenery/model loading. I have now checked in a change that should fix some long standing problems with modelss that appear to have z-fighting. This change should not harm and works so far for all I have tested. But it slightly changes the way stg files paths are handled. So if this really introduces a problem, please tell me. Greetings Mathias -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
