Re: [Flightgear-devel] Regional textures merge request
On Tue, May 15, 2012 at 8:52 AM, Renk Thorsten wrote: Quick question to Stuart: Currently the conditionals for texture selection are done using /position/longitude-deg,... i.e. aircraft position. The actual tile position however is different from that by the visibility and an direction, which makes for some uncertainty. So, it'd be more consistent to place a condition on the position of the tile to be loaded rather than the aircraft - is that information exposed somewhere (or would it be difficult to do that)? Sorry for the delay in replying - I've been away. As Fred says, it would be possible, with some changes to the materials.xml format and the tile loader. However, I think we can do better. Martin Spott pointed out to me off-list that one could use a GIS shapefile to define a region. This would be much more flexible, allowing for non-rectangular areas to be defined. So, if we're going to change the tile loader, I'd want to go down that route instead. I doubt it would be too difficult, but as always it's a question of having enough time to do the coding. I'm probably going to have much reduced FG time for the next year or so, so I doubt I'll get around to it any time soon. -Stuart -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal performance
Thorsten
(Even if this works fine, please do not commit yet, I am not 100% sure
that I didn't create an instability somewhere).
Turns out I broke at least the visibility interpolation - to restore it,
uncomment line 726 in Nasal/local_weather/local_weather.nas
if (vis 0.0) {setprop(lwi~visibility-m,vis);} # a redundancy check
(there's a better way to deal with this, but for the time being that seems
to
solve the problem).
I have tested using only the test tile so far. The time spent in events is
dramatically reduced to around 70ms vice 210ms. There remains some odd
cyclical frames coming in, but the results are broadly in line with Basic
Weather. The details are here:
http://dl.dropbox.com/u/57645542/Adv-Weather-data.png
I tried some airborne tests using the test tile, and the visual results are
satisfactory, again comparable to Basic Weather. The spikes in framerate can
be measured, but are not too visually intrusive. Like you, I have been
unable to identify the source so far.
I extended the test by setting all settimer loops to 0.0. There was little
measurable change in either frame rate or stability.
I'm now going to test with more representative weather.
Vivian
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Regional textures merge request
On Tue, May 15, 2012 at 8:52 AM, Renk Thorsten wrote: Quick question to Stuart: Currently the conditionals for texture selection are done using /position/longitude-deg,... i.e. aircraft position. The actual tile position however is different from that by the visibility and an direction, which makes for some uncertainty. So, it'd be more consistent to place a condition on the position of the tile to be loaded rather than the aircraft - is that information exposed somewhere (or would it be difficult to do that)? Sorry for the delay in replying - I've been away. As Fred says, it would be possible, with some changes to the materials.xml format and the tile loader. However, I think we can do better. Martin Spott pointed out to me off-list that one could use a GIS shapefile to define a region. This would be much more flexible, allowing for non-rectangular areas to be defined. So, if we're going to change the tile loader, I'd want to go down that route instead. Hi Stuart Good point from Martin Spott off-list ;-) but anyway, has there ever been a proposal how this regions could be defined ? Is there a wiki, a readme or something ? I stumbled over an interesting system the last months, because I was looking for a landcover system with less inconsistency than corine or other systems ... and found a complete different approach which might be interesting for getting such materials/texture regions probably ? Not sure, but this could also lead to a new approach how to use textures at all with flightgear, but of course this is just a very vague assumption. LCCS is the only universally applicable classification system in operational use at present. It enables a comparison of land cover classes regardless of data source, economic sector or country. The LCCS method enhances the standardization process and minimizes the problem of dealing with a very large amount of pre-defined classes. Taken from here: http://www.glcn.org/sof_1_en.jsp Cheers, Yves -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Regional textures merge request
Hi Yves, flightg...@sablonier.ch wrote: Good point from Martin Spott off-list ;-) but anyway, has there ever been a proposal how this regions could be defined ? Is there a wiki, a readme or something ? Well, in case of doubt, a simple, easily maintained text list would serve the task of mapping country- or region-codes to the various texture sets. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal performance
I have tested using only the test tile so far. The time spent in events is dramatically reduced to around 70ms vice 210ms. There remains some odd cyclical frames coming in, but the results are broadly in line with Basic Weather. Okay, that's good news. I'll continue working along these lines then, although I expect that the rest is just cleanup work which will not gain that much performance any more. The biggest issue is that in this version the movement of the Cirrus clouds is broken, and under some (somewhat unusual) conditions that would show (since tiles themselves still move, there'd be a pileup of clouds in a given location in strong winds if the aircraft doesn't move much). But it seems the quadtree code to move them is simply too heavy - either a lighter scheme is needed, or some other solution. What's the prospect of adding hard-coded movement to models loaded from Nasal? AI models defined on startup can have a heading and an airspeed and these can even be changed at runtime - just models loaded from Nasal at runtime don't seem to have that feature, and so they require per frame position updates from Nasal. * Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] ..we can now build FG scenery with sumo-simulated road traffic???
Hi, ..this means we can now build FG scenery with sumo-simulated road traffic??? Source: http://sumo.sourceforge.net/ ..debian users: 'aptitude install sumo sumo-doc sumo-tools ', quick listing: arnt@celsius:/tmp$ dpkg -l |grep sumo ii sumo 0.15.0~dfsg-1 Simulation of Urban MObility (SUMO) ii sumo-doc 0.15.0~dfsg-1 Simulation of Urban MObility (SUMO), documentation and examples ii sumo-tools 0.15.0~dfsg-1 Simulation of Urban MObility (SUMO), tools and scripts arnt@celsius:/tmp$ arnt@celsius:/tmp$ man sumo arnt@celsius:/tmp$ sumo --help SUMO sumo Version 0.15.0 Copyright (C) 2001-2012 DLR and contributors; http://sumo.sourceforge.net A microscopic road traffic simulation. Usage: sumo [OPTION]* Configuration Options: -c, --configuration-file FILE Loads the named config on startup --save-configuration FILE Saves current configuration into FILE --save-template FILESaves a configuration template (empty) into FILE --save-schema FILE Saves the configuration schema into FILE --save-commentedAdds comments to saved template, configuration, or schema Input Options: -n, --net-file FILE Load road network description from FILE -r, --route-files FILE Load routes descriptions from FILE(s) -a, --additional-files FILE Load further descriptions from FILE(s) -w, --weight-files FILE Load edge/lane weights for online rerouting from FILE -x, --weight-attribute STR Name of the xml attribute which gives the edge weight Output Options: --netstate-dump FILE Save complete network states into FILE --netstate-dump.empty-edges Write also empty edges completely when dumping --summary-output FILE Save aggregated vehicle departure info into FILE --tripinfo-output FILE Save single vehicle trip info into FILE --vehroute-output FILE Save single vehicle route info into FILE --vehroute-output.exit-times Write the exit times for all edges --vehroute-output.last-route Write the last route only --vehroute-output.sorted Sorts the output by departure time Time Options: -b, --begin TIMEDefines the begin time; The simulation starts at this time -e, --end TIME Defines the end time; The simulation ends at this time --step-length TIME Defines the step duration Processing Options: -s, --route-steps TIMELoad routes for the next number of seconds ahead --no-internal-links Disable (junction) internal links --ignore-accidentsDo not check whether accidents occure more deeply --ignore-route-errors Do not check whether routes are connected --max-num-vehicles INTQuit simulation if this number of vehicles is exceeded --incremental-dua-step INTPerform the simulation as a step in incremental DUA --incremental-dua-base INTBase value for incremental DUA --scale FLOAT Scale demand by the given factor (0..1) --time-to-teleport TIME Specify how long a vehicle may wait until being teleported, defaults to 300, non-positive values disable teleporting --max-depart-delay TIME How long vehicles wait for departure before being skipped, defaults to -1 which means vehicles are never skipped --sloppy-insert Whether insertion on an edge shall not be repeated in same step once failed. --lanechange.allow-swap Whether blocking vehicles trying to change lanes may be swapped. Report Options: -v, --verbose Switches to verbose output -p, --print-options Prints option values before processing -?, --helpPrints this screen -V, --version Prints the current version -W, --no-warnings Disables output of warnings -l,
Re: [Flightgear-devel] Nasal performance
On 05/20/2012 10:17 AM, James Turner wrote: This is interesting - as far as I know, the current GC does not include a maximum delay and restart facility. If it did, that would entirely satisfy the current issues. At least by my understanding. Equally, I've looked at the current GC code and didn't notice any code to support this feature. Does anyone else have any further information about this? Since it would be far simpler and more robust than any other solution thus suggested. I was lucky enough to notice this come by. I wouldn't hold your breath. :) This was an experiment, and honestly I have no idea why I put it in the docs. The idea was to do the GC normally, check timestamps periodically, and then longtmp() out of it past some threshold, leaving the intermediate sweep stuff in place. But that's not enough, because now you need to track all mutated reference-storing objects in a separate list so they can be swept again. And you need to have some kind of heuristic for when it's OK to restart the sweep. I have a vague memory of being sure I'd cleverly solved this, but I never got it working and at this point, frankly, I suspect I was wrong. In my advancing age, I've come to believe that low-latency GC is just a pipe dream. You can have a realtime GC or you can have a production system, but you can't have both at the same time. Every managed runtime in the modern world has latency bugs in some application or another, every one of them. Andy -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal performance
On 05/20/2012 11:37 AM, Stefan Seifert wrote: Generational garbage collection is not that difficult. When you have a working mark sweep GC, extending it to be generational is rather straight forward and can greatly reduce GC runtime Runtime, yes, but not latency bounds. You still have to touch the whole heap eventually. But you're right: allocating objects into generations and only mark/reaping from the most recent one on most iterations is a straightforward optimization and will definitely make things faster. Andy -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal performance
Thorsten I have tested using only the test tile so far. The time spent in events is dramatically reduced to around 70ms vice 210ms. There remains some odd cyclical frames coming in, but the results are broadly in line with Basic Weather. Okay, that's good news. I'll continue working along these lines then, although I expect that the rest is just cleanup work which will not gain that much performance any more. The biggest issue is that in this version the movement of the Cirrus clouds is broken, and under some (somewhat unusual) conditions that would show (since tiles themselves still move, there'd be a pileup of clouds in a given location in strong winds if the aircraft doesn't move much). But it seems the quadtree code to move them is simply too heavy - either a lighter scheme is needed, or some other solution. What's the prospect of adding hard-coded movement to models loaded from Nasal? AI models defined on startup can have a heading and an airspeed and these can even be changed at runtime - just models loaded from Nasal at runtime don't seem to have that feature, and so they require per frame position updates from Nasal. Looks doable - but then everything does until the difficulties become apparent :-) I'm just doing a little experimentation here now on that. Vivian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ..we can now build FG scenery with sumo-simulated road traffic???
This is a strange feeling I have here this evening reading the above API..and tip from arnt I see a lot of future... After all my nephew is a truck driver amd introduce to hard maps need to navigate and plan route and indeed at 10 is kinda getting more the concept of headings etc ... Backseat driver spring to mind.. and he's in the air.. with autopilot.. So I think this sumo is cool, its a nice api, and seems I can knock out code.. gen.. And I think we can be even clever and fuzzy logic some time tables.. eg School buses will be there are 9am on a monday... and last.train from london etc.. == traffic love it.. But this is possible also to to make it a bit more REAL... We only need traffic routes planned On approach to the threshold.. eg landing at Heathorw from either end as a passenger means u see traffic a[[roaching and crossing and stuff crosing on the motoway.. Same in EHAM, and a few other airports.. KSFO does not fall into this case as is water approach.. So what do we do next ? So the Question I have really is .. there must be a way for the data to dictate if an aircraft is passing below 100ft and on an approach to an airport AND crossing a motorway.. then we could create some time traffic.. On Tue, May 22, 2012 at 6:02 PM, Arnt Karlsen a...@c2i.net wrote: Hi, ..this means we can now build FG scenery with sumo-simulated road traffic??? Source: http://sumo.sourceforge.net/ ..debian users: 'aptitude install sumo sumo-doc sumo-tools ', quick listing: arnt@celsius:/tmp$ dpkg -l |grep sumo ii sumo 0.15.0~dfsg-1 Simulation of Urban MObility (SUMO) ii sumo-doc 0.15.0~dfsg-1 Simulation of Urban MObility (SUMO), documentation and examples ii sumo-tools 0.15.0~dfsg-1 Simulation of Urban MObility (SUMO), tools and scripts arnt@celsius:/tmp$ arnt@celsius:/tmp$ man sumo arnt@celsius:/tmp$ sumo --help SUMO sumo Version 0.15.0 Copyright (C) 2001-2012 DLR and contributors; http://sumo.sourceforge.net A microscopic road traffic simulation. Usage: sumo [OPTION]* Configuration Options: -c, --configuration-file FILE Loads the named config on startup --save-configuration FILE Saves current configuration into FILE --save-template FILE Saves a configuration template (empty) into FILE --save-schema FILE Saves the configuration schema into FILE --save-commented Adds comments to saved template, configuration, or schema Input Options: -n, --net-file FILE Load road network description from FILE -r, --route-files FILE Load routes descriptions from FILE(s) -a, --additional-files FILE Load further descriptions from FILE(s) -w, --weight-files FILE Load edge/lane weights for online rerouting from FILE -x, --weight-attribute STR Name of the xml attribute which gives the edge weight Output Options: --netstate-dump FILE Save complete network states into FILE --netstate-dump.empty-edges Write also empty edges completely when dumping --summary-output FILE Save aggregated vehicle departure info into FILE --tripinfo-output FILE Save single vehicle trip info into FILE --vehroute-output FILE Save single vehicle route info into FILE --vehroute-output.exit-times Write the exit times for all edges --vehroute-output.last-route Write the last route only --vehroute-output.sorted Sorts the output by departure time Time Options: -b, --begin TIME Defines the begin time; The simulation starts at this time -e, --end TIME Defines the end time; The simulation ends at this time --step-length TIME Defines the step duration Processing Options: -s, --route-steps TIME Load routes for the next number of seconds ahead --no-internal-links Disable (junction) internal links --ignore-accidents Do not check whether accidents occure more deeply --ignore-route-errors Do not check whether routes are connected --max-num-vehicles INT Quit simulation if this number of vehicles is exceeded --incremental-dua-step INT Perform the simulation as a step in incremental DUA --incremental-dua-base INT Base value for incremental DUA --scale FLOAT
Re: [Flightgear-devel] ..we can now build FG scenery with sumo-simulated road traffic???
And can we just paint the shadow and not the vehicle.. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Regional textures merge request
As Fred says, it would be possible, with some changes to the materials.xml format and the tile loader. However, I think we can do better. Martin Spott pointed out to me off-list that one could use a GIS shapefile to define a region. This would be much more flexible, allowing for non-rectangular areas to be defined. So, if we're going to change the tile loader, I'd want to go down that route instead. Well, I don't want to be greedy, I just wanted to know if it's trivial to do - what we have now is quite a bit better than what we had previously - it's just not perfect and still has some issues. But if that's how it stands, I'll create a merge request for my Hawaii project as it is (i.e. including the visibility-range dependent artefact generated by the transition from lush green to volcano red in shrub and tundra). I think it's still nice to fly Hawaii with the regional scheme. Hi Thorsten Sorry for my impatience, but I think before one start to have tousands of custom scenery textures in fgdata we should discuss if such limited custom scenery changes makes sense to be in the (already heavy) fgdata repository. What I like about conditioning on position is that it's simple - everyone can do it, and it already seems to inspire some to try to use the scheme: http://www.flightgear.org/forums/viewtopic.php?f=5t=16418 I may rot in custom scenery hell for what I write down here because I still have some kind of world scenery in mind ... Something I really fear meantime is a git-exploding texture folder in fgdata because of focus on better textures for small custom scenery projects. Yes, its just as simple as this more or less useless comparison in this first post at the forums. The only thing that needs to be done here is improving landcover shapefiles to get more details, later changing some textures and materials.xml and providing a custom scenery project, trought whatever channel ... but when I look at this, why not being consistent and just go for detailed photo scenery at the end ? Looks wow all the time. (But once you will realize with photoscenery youre only flying at noon for the rest of your flightgear scenery life ;-) I think that wouldn't be so easy with a GIS shapefile (I would not know how to start that way for instance). But if we ever move to a more faithful solution, e may have all the texture sets for various parts of the world already in place :-) - so we're not losing anything. The GIS shapefile might be easy, but this will first need some new sg/fg and probably terragear code for such meta coverage. And more proposals, ideas and some kind of a scenery master plan. Here I will add a note to the concept of the transition shader I introduced a longer time ago. Stupid, but the idea was to have LESS texture files at the end to free resources. It was inspired by the idea of having natural structures, giving (transitional) patterns with different colour schemes, following water/clima/temperature or whatever parameters. (The code for the texture/shader handling with transition shader was simply based on an idea of Tim Moore and an uncited/unknown contributor for the old but working crop shader). Parallel to the transition shader I had the idea for an improved texture system based completely on transitions, having a texture folder with some small structures and another with colour schemes, following some newly introduced meta-vegetation-parameters. Ok, I never finished this task because Im not able to introduce the new parameters to sg/fg code. But personally I vote against having a big bunch of rural textures in a wow-fgdata for the moment. I would really like that new overall shader/texture concepts are tested and discussed well and gives proposals and roadmaps to all the scenery projects, eating less resources when possible. Otherwise I guess we will end up with a heavy archive of temporary custom scenery approaches. Cheers, Yves -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
