Re: [Flightgear-devel] procedural bridge generation
On Sunday, September 22, 2013 12:34:32 Thomas Albrecht wrote: > With my python coding for OSM buildings in FG coming along nicely, I > recently thought about creating semi-generic bridges. Is anyone else > working on this? Or is anyone aware of an open source procedural bridge > generator? Searching the net mostly turned out stuff for Houdini etc. > > Tom Hi Tom, I think this came up before, and the conclusion was that it's difficult to do this outside of Terragear, since the tile structure only stores the polygons and their types, not neighbours (yet). So this should start somewhere in the clipper, but Terragear has underwent a heavy refactoring recently, and I'm no longer familiar with the code. I'm speaking as the guy who coded tens of python scripts to bring real AI schedules into Flightgear, so I'd wish it was possible to do this in Python. Cheers, Adrian -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. http://pubads.g.doubleclick.net/gampad/clk?id=64545871&iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Upcoming Random Buildings changes
On Friday, September 20, 2013 13:04:32 Stuart Buchanan wrote: > > If I implement a PagedLOD approach, it might reduce the memory > footprint sufficiently that we could switch back to the OSG > primitives. > I think one of the problems is that most of our objects have no concept of different LOD's. If we had objects with say 3 LOD, it would ease memory and graphics load. It should be possible to take an object and generate multiple LOD's for it automatically, but I have almost no knowledge about 3D objects. Might be worth checking it out. Cheers, Adrian -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Upcoming Random Buildings changes
On Wednesday, September 18, 2013 19:05:22 Stuart Buchanan wrote: > I did take a look at the PagedLOD approach - Matthias' code made a great > template to work from. > > > -Stuart Stuart, this is totally unrelated, but what would be the price to pay to have collision with generated buildings, and Rembrandt shadows? Adrian -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Upcoming Random Buildings changes
On Wednesday, September 18, 2013 18:45:09 James Turner wrote: > (BTW Adrian proposed something which achieves a similar end result back in > February, the problem with his approach is it doesn't work via the OSG > paging mechanism, and hence I don't think we should pursue it - ultimately > we need to be letting the OSG Pager handle all our loading and unloading, > instead of trying to fit our own LOD systems above / below it) > > Regards, > James I had a private exchange about that in December with Mathias, his method is way better, hence I didn't pursue this any further. I'm still using my code here for the memory benefits but that's related to my radio code. PagedLOD is the way to go, case closed :) Cheers, Adrian -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textures separation, cleanup
On Wednesday, September 18, 2013 21:06:48 Renk Thorsten wrote: > > - a baseline texture set that is of adequate, but not high quality > > > > (e.g. max 1024x1024 size for landcover, or something else agreed to be > > good enough) to be included by default in the installers > > > > (this would also be friendly to people on older hardware with limited > > > > VRAM) > > > > - high res (and even, ultra-high res) sets, plus a DDS set for those > > > > who want it, which can be downloaded + updated later via terra-sync. > > > > (of course we can have discussions about if the default set should be > > > > really low quality or quite high - but the point is to have levels we > > can switch between centrally ) > > > On the other hand, if ALS is not supposed to be default, I wouldn't save > harddisk space by reducing the visual quality - we want to make a good > first impression for the user. So I would get rid of redundant lowres > textures which have a hires equivalent then. > > I suppose dds can be factored out in any case, as there seems to be a > strong sentiment that dds cannot be default as it doesn't run on Linux > systems with non-proprietary drivers. > > In general, I would definitely like to keep as many textures as possible in > the devel version - when designing regional textures, I find that I really > need material to work with, and many textures can be applied to a > different purpose after a color transformation. Also, it's going to be > rather difficult to package regional textures region by region as many of > them are shared across different regions. > > Hm, I guess in the end I work too much with terrain textures to be really > comfortable with a major change in the way we distribute them - I can see > the redundant lowres bits go, and I can see that the dds set is easily > separable, but I don't really see a grand design beyond. May be just my > personal bias. > > * Thorsten Hi Stuart, Thorsten, Since I'm the author of most of the high-res PNG textures, I'd like to explain why the texture resolution is not the same for every texture type, and to share my opinion on this subject. When I first started to make textures, I looked for the highest resolution aerial photos which could be used with GPL. Unfortunately, not all ortho imagery had the same quality. Some sets were really good, with high resolution, while others had color balance issues or lower resolutions. For some types of terrain, like wooded areas, crop fields, towns, mixed wood- crop, I have found good images, but in some cases I was not able to extract all textures at the same resolution due to visible artefacts or items which would repeat visibly in an unpleasant way. Rock is a special case since I used my own photos which had a high enough resolution to extract a quality texture. So in the end, we end up with texture sizes ranging from 512px to 2048 px. Of course, ideally we would have all high-res textures the same size, and all low-res textures just scaled versions of the high-res ones. Unfortunately, that was just not possible. Finally, I opted for keeping 2048px textures at this resolution, while other textures had 1024 or even 512px resolution, according to their source. I think that today, with every modern game shipping on full-size DVD's, there should be no problem keeping the high res textures at their original, intended size. The size increase is not dramatically large. At the same time, I'd like to state my opinion that PNG counterparts of all DDS textures should be available in the git repo for development purposes. Even if this increases the size of the repo, I think it's a must since DDS is not an open format easily and losslessly convertible to PNG. My 2c on this matter, Adrian -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] --jpg-httpd command line option
On Tuesday, September 17, 2013 20:52:16 Curtis Olson wrote: > If someone decides to jump into this, another feature that would be cool > would be to stream the display out as a video stream which could then be > played by any number of video players on a remote computer (like mplayer.) > ffmpeg probably would provide library support to make this pretty > straightforward, but I haven't had a chance to dive in and see how > easy/hard it would be. > > One area where this feature could be useful is in UAV research and > simulation where you'd like to emulate a live video feed back to a ground > station. It could also be fun for sharing/broadcasting your simulator > session and probably could be made to work with a web video server. > > In my own experimentation I've been able to sort of do this by using ffmpeg > to capture an area of the screen, encode it as h.264 and send it off to a > remote destination as a udp video stream, for example: > > ffmpeg -f x11grab -s vga -r 15 -b 100k -preset ultrafast -tune zerolatency > -maxrate 100k -i :0.0+1,58 -f mpegts -vcodec h.264 udp:// > remote.host.name.org:1234 > > But this requires careful manual sizing and placement of my flightgear > window and it would be cool to have this built right in... I've seen other > apps that can do this so I know it's technically possible, and I imagine > not too much coding once you figure out the magic to make it happen. > > Curt. > Hi, there, VLC does this better than ffmpeg, so it's probably a good idea to study it's codebase for streaming code. Also, MJPEG is nice, but as a container I'd choose Ogg/Theora instead of H264 since they're entirely open. Cheers, Adrian -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear voice communication
On Tuesday, August 20, 2013 01:08:42 Clement de l'Hamaide wrote: > Hi all, > > I've finished FGCom integration, fg/flightgear and fg/fgdata repo are ready > for test. On FlightGear side there is a -DENABLE_IAX variable set to ON as > default. In order to use the new feature you must add --enable-fgcom (or > --prop:/sim/fgcom/enabled=true ) > > You can find more detail on the wiki : > http://wiki.flightgear.org/Integrating_FGCom > > Feedbacks are welcome, I'm not able to test on Windows or MacOs, for our > Windows tester, Jenkins is able to provide the feature from now. > > A new domain name has been setup "fgcom.flightgear.org", for now this > server is hosted by me at home, I hope my Internet connection will be > sufficient, else I would need to ask for help (maybe Dirk would be happy > to host it once he upgrade his server ?) > > Thanks to Geoff, James, Gijs, Vivian and others who helped me in this > effort. > > Regards, > Clément Nice work Clement and all, I'll make sure and check it out and see whether I can integrate my code with fgcom in the future. Meantime, just to keep you on your toes, there's another promising related project, albeit with no code yet, but could do very well if maintained properly: FGspeak, look for it on Gitorious and check out the README. Since last time I looked at FGcom I had some headaches trying to sort out how to implement a hook for my radio routines, I may focus on Fgspeak as well, if it's development has a good pace. Cheers, Adrian -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear voice communication
On Thursday, August 15, 2013 22:52:34 Clement de l'Hamaide wrote: > > - As main problem I see in the ranges of frequencies: > In the new integrated FGCom ranges is dynamically calculated depending of > the altitude of the pilot/ATC in accordance to this formula : > http://fr.wikipedia.org/wiki/Radiocommunication_a%C3%A9ronautique#Port.C3. > A9e_et_propagation (sorry only french page has the formula) > > > > Regards, > Clément Hi guys, Clement, If you'd use my new radio propagation code, which is an improvement over what's already in git, range would be as close to reality as possible for all type of radio comms, be they VHF voice, VOLMET, ACARS, ADS-B, VOR/DME, radar, etc. My code takes into account not only terrain obstruction, altitude, distance, but also frequency and standard equipment capabilities. Now, IMHO, for the future it would be desirable to integrate voice comms into Flightgear itself, without the need to use Asterisk or other external tools. Some other simulators have this as default, minus the realistic propagation of course. Cheers, Adrian -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] internal telnet weirdness
On Friday, August 09, 2013 15:47:57 Curtis Olson wrote: > For a work project I ended up modifying a qt program (C++) to talk to the > FlightGear interface. I pulled in the plib socket routines and used those, > mostly because I was unaware of/unfamiliar with the qt socket routines. My > approach maybe wasn't quite as clean as doing everything in already > available qt functions, but I haven't had any problems with the > communication. > > Regards, > > Curt. > Hi Curtis, I might consider that, but for the moment I'd like to keep my project clean of other dependencies besides Qt. If there's no other way, I'll consider using another socket library, of course. Thanks for the suggestion. Btw, since we're on this subject, my patch for src/Network/props.cxx never got merged, so there's no useful way to execute a Nasal script stored in a property, with the command "nasal /sim/radio/waypoint/nasal" for example. I found last year the command in the docs, but it was probably never used before? Let me know if you'd like to get the code for that, I'm using it in my projects and it's a one or two line change. Or you could run a diff between my clone on branch radio_next and your master tree. Cheers, Adrian -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] internal telnet weirdness
On Friday, August 09, 2013 13:21:45 James Turner wrote:
> Qt sockets are very thin wrappers around BSD / Windows sockets. More likely
> to be a character set / encoding issue? Remember you need to be explicit
> about encoding when going from 8-bit representation to a QString.
>
> That said I've no experience with the FG telnet code. If you want to post
> your client code I'm happy to quickly look at it.
>
> James.
Hi James,
You're quite correct, I also think it's an encoding issue. Qt 4.8 had a
toAscii() translation, while Qt 5.1 has got rid of that and supposedly it's
functionality is enclosed in toLatin1().
Basically I've reached a state where out of ideas I'm just reading the
response one char after another, then appending it to a QString.
QString line;
while(!_socket->canReadLine()){}
...snip...
while ((!endOfLine)) {
char c;
int bytesRead = _socket->read(&c, sizeof(c));
...snip...
line.append( c );
Then after testing for a '\r' char which signals the end of line, I'm
returning the QString to it's user.
I have to use a blocking approach due to the already existing structure, but
it's not a problem, since this is on it's own thread. I think the encoding is
the problem here, but I don't have a clue why the Python wrapper does it right
while Qt doesn't.
Cheers,
Adrian
--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] internal telnet weirdness
Hi all, I'm writing an application which uses a socket to connect to Flightgear's telnet interface, and I have encountered the following issue: Writing to Flightgear is fine, but while reading the socket, some properties have weird values, and some characters are getting replaced (L is sometimes replaced by 0 etc.). I am using "data" mode to read from the socket. I have noticed that the Python Flightgear telnet interface uses "prompt" when reading. I'm wondering if someone else has encountered this, or is this some Qt socket issue I have to sort out on my own. Thanks, Adrian -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery manager
On Sunday, December 16, 2012 23:11:44 Mathias Fröhlich wrote: > Hi, > Hi all, I have added my new code for far-tiles in a merge request for flightgear and simgear. You can now test the code, and also check whether texture resizing is necessary for materials which are not inside the near tiles (during an osg cache cycle). Piggy-backing on this is the map display used for testing. Feel free to use or discard that code. I used it for testing, and have a property check to switch it on or off, but I didn't mess with the GUI in fgdata. Cheers, Adrian -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery manager
On Sunday, December 16, 2012 23:11:44 Mathias Fröhlich wrote: Hi Mathias, > Ok, for that, I can see a lot of solutions. > > Having one that is may be close: > Use the BVH tree that is used in fgelev or fgai. The fgelev one is > parametrized like you probably need today. There is one hacky switch in the > BVH paging that only loads terrain into a bounding volume tree. I'm just using the get_elevation_m function from the scenery subsystem, inspired by Torsten's terrain sampler, but in a different way. This tests for nodes with SG_NODEMASK_TERRAIN_BIT set, which trees, houses, random buildings also have. Therefore I added a special bit only for surface SG_NODEMASK_TERRAIN_BIT, and accounted for it everywhere SG_NODEMASK_TERRAIN_BIT was referenced. This way subgraph traversal are an order of magnitude faster since they don't use other stuff generated by the BTG loader which have that bit set. If you want me to, I can place a simgear merge request and see what I changed and where wrt. traversal masks. > > Have two different bvh trees and making sure that these nodes are not > cached for scenery loading - since they are incomplete in the sense of > the visible viewer - would provide you what you need. > > Since you are doing radio stuff I expect that your main workhorse is a line > segment intersection which should be done best with this kind of structure. > True? > May be you need an other line segment visitor which measures the distance > that is covered by material. The principle is: have a general direction towards the radio station, go in that direction X meters (100-500 depending on setting) and get an elevation profile point. After acquiring a complete elevation profile for a path line, this is fed to the real algorithm which does all the hard calculations. > > Ok, what might block this approach is the amount of static variables that > is spread around. Already in face of reusability almost every > global/static variable can be a serious problem ... > > Look into fgelev and fgai and look for BVHPAger and its > getBoundingVolumes(sphere) method. > May be flightgear is not really ready for this kind of shared usage, but > the basic building blocks are there ... I'll have another look next week, it's a while since I studied that code. I don't think I need something more custom for now. The radio code is working just fine right now, but I'm definetly going to improve it in some areas, once it's merged. Featurewise, I'm not yet done either. I am also planning to get rid of the scenery subsystem dependency if possible. > Ok, in the end you might need an other custom approach. But just off my > head what I think is probably best algorithmically. > > Also keep in mind that tuesday is the deadline for new features for the > next release. I know, hence the whole discussion about this feature that took most of the mailing list space lately. Sorry about that. Let me know if you are interested in the traversal mask stuff that I have added to separate surface only, models, trees, random buildings etc. I can place a merge request tommmorow, but it has to go simultaneously in fg and simgear, since the traversal masks are used in both. Cheers, Adrian > > Greetings > > Mathias > -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery manager
On Sunday, December 16, 2012 22:38:41 Mathias Fröhlich wrote: > Hi, > > On Sunday, December 16, 2012 22:02:15 Adrian Musceac wrote: > > I am aware there are better systems out there, I'm just doing what I can > > within the restrictions of the BTG format. I'd be more than happy to have > > a real terrain LOD, but right now that means lots of changes in > > Terragear and simgear. > > Well, I suspect that this effect is easy to get without any additional > manager. Not to speak about sophisticated continous lod. > > Mathias > Hi, Suspect you're right, now after reading the required information :) Would need to be a completely separate thing from our Terragear, and I'm not sure how Stuart's trees and buildings would fit in. Not to mention the lights. But I see it possible now. I'll have to do a lot more reading though, this is definetly not my area. Cheers, Adrian -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery manager
On Sunday, December 16, 2012 21:18:10 Stuart Buchanan wrote: > On Sun, Dec 16, 2012 at 11:44 AM, Adrian Musceac wrote: > > It' basically very simple. Far tiles no longer compute anything other > > than it's own geometry, and also use a very low resolution texture set, > > obtained by running a batch resize on the regular texture set. > > OK. So you don't load anything other than the BTG file (e.g. no placed > objects)? > > I'm surprised there's any benefit to using a very low resolution texture > set. Surely the normal textures are already loaded by OSG and it's cheaper > just to refer > to those rather than loading some more textures? Or are we not > sharing our textures > between tiles? > > -Stuart Stuart, James, I'm actually not 100% sure about textures, but I have provided my explanation for the case of having x,y,z materials within the inner tiles, and a,b,c materials within the outer tiles (intersections between them are irrelevant, since are loaded anyway). I'd prefer having a,b,c which are not supposed to be seen at high res, being small size, until the materials enter the inner tiles and load the large textures (if not already in cache). My explanation may be wrong, I don't stand by it 100%. My main interest with terrain was a) having longer distances available, and b) having separate traversal masks only for surface. All for use in my infamous now radio code. This lead to what I have now, an improvement in memory usage and view distance. All this has gotten me interested again in LOD systems. I'd like to see the day when the whole earth can be rendered like Mathias said. Cheers, Adrian -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery manager
On Sunday, December 16, 2012 21:37:37 James Turner wrote: > On 16 Dec 2012, at 19:18, Stuart Buchanan wrote: > > I'm surprised there's any benefit to using a very low resolution texture > > set. Surely the normal textures are already loaded by OSG and it's > > cheaper just to refer > > to those rather than loading some more textures? Or are we not > > sharing our textures > > between tiles? > > Right, I had exactly the same thought. > > Of course, if by some terrible mistake we aren't sharing textures, that > would be a very big bug, but hopefully easy to fix! > > James > I'm replying to multiple messages here: James: I have no clue how and if the textures are shared, or if the osg cache is related to this. All I know is that I can see a difference. I could explain it in my simplistic view: the current position holds the large textures for all material within the inner zones. If there are materials within the outter zone which are not within the inner zone, their effect is using a smaller texture, at least until they pass into the inner zone. So I could explain it like this: I have Road, DeciduousForest, DrypastureCover in the high res zone, and BroadleafForest,NeedleForest, Rock, Marsh Bog etc in the outter zone. No need to have high res Bog for a triangle 100 km away (keep in mind I also use large res textures, some of which were kindly commited by ThorstenR in the regional set). Regarding the osg cache, I am not familiar with the way it works, and how it shares textures, so forgive me if I can't answer this. Mathias, Stuart, yes I'm only loading the bare surface from the BTG, and not performing any tree, building, model calculations from them (they would be invisible at 20-30 km away, but the osg::LOD just hides it from view, does not prevent from loading in RAM all the objects). Besides reduced scenegraph, the loading speeds for an outer tile are faster. The tilecache model is also changed, so it does not look like a long tail behind the flightpath, but mostly as a rectangle around the plane. I reckon the tower view losing terrain should be dealt by disabling tower view when outside a reasonable distance from the tower. The memory gains are those I spoke about before, and allow me to fly a long time in custom SRTM terrain without running out of RAM. I'd estimate a 1.5 - 2 times improvement in memory cost vs. view distance, at a slight cost of increased disk IO (which is not noticeable, at least running in multithreading mode). I am aware there are better systems out there, I'm just doing what I can within the restrictions of the BTG format. I'd be more than happy to have a real terrain LOD, but right now that means lots of changes in Terragear and simgear. I'll publish the modifications tomorrow, If I can get around to clean the code a bit. Cheers, Adrian -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery manager
On Sunday, December 16, 2012 18:39:47 Mathias Fröhlich wrote: > Hi Adrian, > > The same idea is behind the osg lod based whole world model. > Where do you store the elevation data? > > Greetings > > Mathias > Hi Mathias, It's actually nothing really special about it, I'm just modifying a little the tile manager to define "inner tiles" and "outer tiles". The elevation data is inside the same old BTG files, which are actually lists of polygons making a tile mesh, hence why it's hard to simplify on runtime this mesh. The Terragear team might now more about this. This is just a "few lines" of code modification to decrease memory usage by really detailed scenery and allow a greater terrain loading range. So nothing's changed about the terrain format itself. Cheers, Adrian -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery manager
On Sunday, December 16, 2012 12:35:20 Stuart Buchanan wrote: > Hi Adrian, > > On Sun, Dec 16, 2012 at 4:32 AM, Adrian Musceac wrote: > > I am presenting an experimental (WIP) method to reduce memory consumption > > by scenery with 30%, while increasing the visibility distance 4 times. > > This method relies on some kind of LOD system, without mesh > > simplification. People smarter than me can come up with a safe algorithm > > to do that, but I'm afraid it requires changes to Terragear. Right now > > mesh simplification was not > > Could you explain how your system works? > > Presumably you are making some change to the tiles for the low > resolution version? > > -Stuart Hi Stuart, It' basically very simple. Far tiles no longer compute anything other than it's own geometry, and also use a very low resolution texture set, obtained by running a batch resize on the regular texture set. This allows me to have 2.5 times larger view distance in high detail (SRTM) terrain with same memory consumption. There is of course a slight increase in disk IO, but I have only tested this with multithreading enabled on a dual core CPU. Load times for far tiles are actually smaller, since no calculations other than geometry and effects are performed on them. Inner tiles close to the viewer position are normal tiles, nothing changed. That's basically it. I need to refactor the code a bit before I can show it, I wrote it fast and while half asleep. Now, the really big stuff would be load-time mesh simplification, and I have read a couple of papers that seem to suggest that's possibile, but would require some changes to the BTG format. I leave that up to the Terragear guys, I am not very familiar with the way their mesh construction works. Cheers, Adrian -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Scenery manager
Hi all, I am presenting an experimental (WIP) method to reduce memory consumption by scenery with 30%, while increasing the visibility distance 4 times. This method relies on some kind of LOD system, without mesh simplification. People smarter than me can come up with a safe algorithm to do that, but I'm afraid it requires changes to Terragear. Right now mesh simplification was not a priority. The need arised from my frequent flights in SRTM + Corine high-res terrain, where running out of memory was a frequent event (quite terminal on a 32bit machine unfortunately). So I took the liberty today and modified the scenery manager a little. It now works by having an inner circle of high-res tiles, surrounded by an outer circle of low-res tiles. You will be able to spot that on the map in the second picture. Memory savings range from 30% to 50%. I have not yet been able to figure out why, when leaving a detailed mesh zone, memory consumption does not drop and remains the same. This behaviour was present before my patch. Re-entering a high definition zone should not increase memory any further. I have performed a test with the UFO, setting visibility to 80 miles, LOD distance bare to 12 meters, and climbing to 3 ft aka 1 meters. FPS observed was 21, no doubt because of the complexity of the mesh. Maximum memory consumption after waiting for the loading threads to finish was 2800 MB, out of which 680 were other system apps. Terrain was entirely SRTM + Corine. The tile cache behaviour was modified too, it will no longer have a "heavy tail" history, but stay mostly rectangular around the aircraft. Once I find out how to deal with the tower view, I plan to disable any tower view as long as the aircraft is not within a reasonable distance of the tower (say 3 km). This should prevent terrain loss problems. Could use some pointers on where to find the tower view settings in the code. And last, a couple of screenshots for reference: http://wiki.flightgear.org/File:Terrain_loading1b.png http://wiki.flightgear.org/File:Terrain_loading2b.png Sorry about the ugliness of the screens, but Thorsten's atmospheric scattering interferes with the view distance, so I had to disable most nicer shaders. The code, as James would put it, is downright ugly, but it fulfills my needs in this case. Any comments? Cheers, Adrian -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Real-Time Radio Propagation
On Friday, December 14, 2012 18:09:04 Torsten Dreyer wrote: > Hi Adrian, > > you are doing an excellent job at marketing your product ;-) > > As I do not have the time to proof you wrong, you deserve the chance to > proof me wrong! I'll shut up now and stop objecting against merging your > code. I won't be able to merge it myself before we enter the feature > freeze but probably someone with commit rights takes care of it. > > I hope I find some time to test the LOWI approach which had the chance > to do in RL recently... > (http://data.x-plane.com/Docs/LOWI.pdf) > > Thanks, > Torsten > Hi Torsten, Sure, no problem. I hope you will find it useful in the future too, otherwise I would have kept it for myself :) Thanks for all your help last year and your patience for my noobishness in Flightgear inners. Cheers, Adrian -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Traversal mask, was: Real-Time Radio Propagation
On Friday, December 14, 2012 15:05:59 Stuart Buchanan wrote: > The trees were definitely both casting and receiving shadows under > Rembrandt in the > past. I remember this as I was pleasantly surprised that it worked! > > I haven't tested recently though, so it's possible that it has been > broken since. > Ok, I've just tested this with current Git, and buildings except random models, as well as trees, don't cast shadows, but receive them. I do remember a time when buildings cast shadows too, I think. I'll try to research this further. Cheers, Adrian -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Traversal mask, was: Real-Time Radio Propagation
On Friday, December 14, 2012 15:05:59 Stuart Buchanan wrote: > The trees were definitely both casting and receiving shadows under > Rembrandt in the > past. I remember this as I was pleasantly surprised that it worked! > > I haven't tested recently though, so it's possible that it has been > broken since. > > The random buildings I'm less certain about. The 2.8.0 version > certainly both cast and > receive shadows. I'm not sure I've tested shadows since I changed > them to an instantiation > model post 2.8.0. > > Sorry I can't be more definitive. > Ok, let me revert to next and test again. I don't normally enable Rembrandt since it's very slow on my machine, but when I did, I couldn't believe how much it can changed the scene and how nice it looked. So far, I think we agree trees shouldn't have the TERRAIN_BIT set, and random buildings are still up for debate, but random models should definetly set this bit. I will test the shadows again and report which bits are working in latest simgear and which are not. BTW, random models cast shadows, I saw that clearly. Cheers, Adrian -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Traversal mask, was: Real-Time Radio Propagation
Oh one more thing, The random buildings and trees definetly receive shadows, but they don't cast it. Is that the way it should be? Asking because I'm about to push the modifications to my simgear clone. Cheers, Adrian -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Real-Time Radio Propagation
On Friday, December 14, 2012 13:09:54 Stuart Buchanan wrote: > Hi Adrian, > > I haven't looked at your code, and I'm sure you've already taken care > of this, but: > > The use of the SG_NODEMASK_TERRAIN_BIT by the random trees and buildings > is probably due to my ignorance when writing the code, and I certainly > agree that the trees shouldn't have this bit set. Hi Stuart, I am much more ignorant than you are when it comes to the way trees are created :) I have modified the code in simgear now, so that they don't have the bit set. Also, I noticed they have the SG_NODEMASK_CASTSHADOW_BIT | SG_NODEMASK_RECEIVESHADOW_BIT bits set (for Rembrandt), but they don't cast shadows, probably due to their geometry, you probably know better. Should I remove them? > > The v2.8.0 random buildings were a simply geometry built at runtime, > and IIRC people > were enjoying landing helicopters on the top of them. However, the current > git random buildings use a shader instantiation approach very similar to > the trees. I > think that means that the shouldn't be considered with the > FG_NODEMASK_TERRAIN_BIT > either, as the geometry itself isn't placed correctly in the scenegraph. > > Therefore, I think they shouldn't be considered in the > get_elevation_m/groundcache/bounding > box code. Same goes for "random" buildings, which thanks to texture mapping are now not so random :) To my surprise, they also didn't cast shadows. Now I understand why. Should those bits go too? Can Fred give his input too on this issue? About bounding boxes, perhaps there's a way to have that too, but again, I'm very ignorant on your method which relies on shaders. > > I think the random objects _do_ need to be included so they can be included > in collision calculations. Agreed. As it is now, I have added a new bit only for terrain surface, SG_NODEMASK_SURFACE_BIT , and the rest of terrain objects which do have bounding boxes will keep the SG_NODEMASK_TERRAIN_BIT. When performing scenery elevation calls, I believe the best way is to add another parameter which can toggle SG_NODEMASK_TERRAIN_BIT on and off. The speedup in this case is pretty important, there are fewer nodes to be traversed. I think Thorsten's weather would benefit from this as well, since it needs to sample only the surface (elevation, type of terrain). > > On the more general subject, I have two comments, both as a layman so > take with a suitable pinch of salt! > > 1) I think the most important attribute of the radio code is that one > can complete a published > approach. I assume that approaches are specifically designed and > built such that > there in sufficient signal strength within some volume around the > "perfect approach". Normally yes, I am not a pilot, but I assume that there would be no approach charts that would tell you there is localizer/gs signal behind the local mountain. Same goes for VOR etc. The published volume is one thing, but if terrain features come into play, the signal may or may not go, and that's the most interesting part of it, it adds a little uncertainty when you are at low altitude, in mountainous areas, at the limit, etc. I just had a very satisfying flight yesterday using the code, and it made me understand why there are so many VOR's in some areas, and how you need to tune from one to the other as you go through terrain at lower altitudes. I should add that I fly in SRTM terrain mostly, and I have very accurate radio signal predictions. > > My concern with any advanced model is that invalid/inaccurate > terrain/elevation input into the > model might mean that we get too low a signal, and some approaches > might no-longer be > possible to fly due to (incorrectly) low signal strength. The reverse is likely. The values will be most unforgiving with SRTM/high definition DEM, and most forgiving in low res terrain. Fortunately, I have a property which can be set by the user, depending on the type of terrain which is flying. This is the elevation resolution the code should expect. In low res terrain, this property can be set to 200-300 meters between profile points, and then you won't even notice the CPU footprint. > > Adrian: Is that a reasonable concern, or are approaches designed such > that there is always > line-of-site between the station and the aircraft on the approach (and > therefore any terrain > interaction is irrelevant within the approach volume)? I believe all approach charts respect terrain, and judging from nav.dat, there is a good reason some VOR's use greater power, or some ILS stations pump greater power in their antennas etc. To do otherwise and not keep the terrain in mind would be foolish, and I don't think the guys publishing the charts are fools. > > 2) Assuming we're only interested in terrain effects, then it would > seem that the signal strength > at a given point (lat/lon/alt) for a given station is invariant. > > Would it be possible to avoid the runtime hit by
Re: [Flightgear-devel] Real-Time Radio Propagation
On Thursday, December 13, 2012 12:44:00 Torsten Dreyer wrote: > Hi > - Performance > The most important limiting factor for radio propagation on VHF and up > is question "line of sight" or "obscured by terrain". Hi again Torsten, Apologising for keeping this subject up, but I rather enjoy technical discussions, especially based on tested mathematical models and data gathered in the field. Here is what technical knowledge has to say about "line-of- sight" at VHF (or even higher frequencies): ### Terrain features, and buildings, usually attenuate signals. (NB in some circumstances knife edge diffraction can enhance propagation beyond the horizon)### (from http://goo.gl/1la6M ) You can read more about Longley Rice there, especially the part where "Longley Rice has been adopted as a standard by the FCC". Now for real data gathered by me in the field, which is consistent with ITM plots generated for the same locations. Case #1: Have one radio repeater station on 145 MHz, completely obstructed by a mountain edge. Distance between repeater site and mountain edge: ~40 km. As determined by me, acceptable and readable signal was present as low as 500 meters below the mountain edge: single horizon diffraction case. The mountain edge had no vegetation. Case #2: Have one radio repeater station on 440 MHz, completely obstructed by a mountain edge. Distance between repeater site and mountain edge: ~50 km. As determined by me, acceptable and readable signal was present as low as 300 meters below the mountain edge: single horizon diffraction case. The mountain edge had no vegetation. In both cases, no line of sight was ever present between the mobile station and the fixed station, and reflection was not possible. All signal was received from diffraction. Double horizon diffraction is possible too, depending on many factors, including how much power are you pumping into the transmitter. Sidney Shumate's improvements to the ITM, published in the latest IEEE Broadcast society newsletters, make this model the most reliable for irregular terrain. Unfortunately his modifications have a non commercial clause, but you can download, compile and test against the classic versions. Diffraction results will coincide with physical data gathered even more. I think we can close the "optical line-of-sight" debate now. Cheers, Adrian > > Regards, > Torsten > -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Real-Time Radio Propagation
On Thursday, December 13, 2012 15:04:16 Renk Thorsten wrote: > > Somewhat related to the above - *if* the radio propagation model could be > shown to be more realistic - what framerate loss would this be worth as > compared to a faster, less realistic model? And does this question matter > at all if this is implemented optionally - should not the user decide > this? > Hi Thorsten, Torsten, all, Regarding the performance, you are correct, the user can decide on what to spend the CPU cycles. But for the sake of documenting this issue, I have performed a test: The test is performed in standard condition: on ground, all terrain finished loading, visibility set to 40 miles, LOD range bare 6 meters, 3 stations tuned, each at limit of loaded terrain, approx 100 km medium distance to them. First image shows subsystem enabled, second shows subsystem disabled. I have highlighted with red the relevant areas in the images. As always, click for details. http://wiki.flightgear.org/File:Radio-perf7b.png Radio subsystem enabled. http://wiki.flightgear.org/File:Radio-perf9b.png Radio subsystem disabled. Notice DME indication has appeared. In both cases, the FPS observed was 39. In long flight tests, the FPS difference is more like 3-5 from disabled to enabled. Now, regarding terrain influence, modes of propagation, and clutter influence on diffraction at different frequencies, you can observe the details on the upper left of the images. I won't get into details anymore, because I have done that already in a couple of messages. If anyone wishes to add more information on the subject of performance, I invite you to use the wiki page: http://wiki.flightgear.org/Talk:Radio_propagation I'm open to any other technical questions regarding the radio propagation algorithms used. Cheers, Adrian -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Real-Time Radio Propagation
Hi Torsten, Regardless of the fact that you support or not the inclusion of this new radio code, I have to clear up some statements which are wrong. See below. > I spent an hour or two reviewing your code and I still think your > implementation should not be merged into the code base. Let me explain why. > - Realism > Your algorithm takes into account many factors responsible for radio > probagation. Most of those factors are unknown in our data set and we > have to use assumptions for their values. The less data we have and the > more assumptions we have to use, the more unrealistic the algorithm's > result become. My definition for realism is: Does the simulator compute > the same value as I would expect in the same situation in real life? I > strongly doubt the algorithm together with our limited set of data can > provide this. In some cases, the used algorithm is plain wrong as we > know by definition (ICAO rules) the propagation of the radio signal. The Longley Rice algorithm also known as the "Irrregular Terrain Model" is not plain wrong, since it is used in many applications that perform signal prediction on irregular terrain, with good accuracy. As far as I know, only Splat! is open-source, but a lot of commercial software uses this model, which has valid results between 40 MHz and 20 GHz. To call the algorithm "plain wrong" is a mistake in my opinion. The unknown factors and the assumptions you are referring to are mostly about radio gear: output power, receiver sensitivity, antenna gains. I have spent a lot of time reseaching avionics radio products to gain specs in order to cover these unknowns. > > - Performance > The most important limiting factor for radio propagation on VHF and up > is question "line of sight" or "obscured by terrain". Not quite true. According to frequency, radio signals can be significantly diffracted over obstructions. The Longley-Rice model makes a clear distinction between these propagation models: Line of Sight, Single Horizon Diffraction, Double Horizon Diffraction, and Tropospheric Scatter. At frequencies below 140 MHz, signals behave very differently to what you call "line of sight". True "line-of-sight" also has to take into account Fresnel zones, and can only be talked about at 1.5 GHz and up. > Your approach is > to perform terrain samples along the line between the sender and > receiver which is expensive. True, but there is no other way to use the ITM algorithm to obtain a good result. I need to obtain a terrain profile, which is the reason for the performance issues. I have also written a simplified function which does not take terrain into account, for use on very long distances where terrain would not be a factor anymore. > My idea for the newnavradio was to traverse > the scenegraph along the straight line between sender and receiver and > probe for ground intersection. This is basically the functionality as > the probe for ground elevation, which could be reused. The difference of > performance impact is dozens or even hundrets of scenegraph traversals > compared to just one. You are correct. However your results would not be the same, and would be more inaccurate to those generated by ITM calculations. > - Landcover > Landcover contributes only neglible compared to terrain obscucarion to > the loss of signal strength. Correct on lower VHF frequencies, incorrect as we move up into UHF. Can provide results and research papers to prove this. As far as the signal is line-of-sight, only intrusion into the first Fresnel zone is of interest. When diffraction over terrain edges are involved, I can assure you landcover plays a big role. > - Coding style > * You copied parts of the terrain sampler from advanced weather. Better > reuse existing code, probably modify so it suits both usecases. > * Using long chains of if/else or switch/case makes code hard to read > and is usually a good indication for a flaw in the software design. > * I prefer named constants instead of numbers to imporve readability. I will not discuss coding style here, only functionality. > This implementation only adds a pseudo-realistic radio propagation > simulation due to lack of real data It is the most realistic radio simulation that can be obtained. Please explain more about "lack of real data", so I know what to research further. > at the cost of cpu intensive > calculations and a complex new subsystem that has to be maintained over > the time. It's true, it's CPU intensive, and quite complex. Are you thinking only about recreational usage of Flightgear, or other purposes as well? I'm thinking of other applications besides recreational usage, but in any case, enabling this subsystem causes a 3-5 FPS drop on my 5 year old machine. > The same pseude-realism could be achived by implementing an > approximation for signal attenuation for line of sight and obscured > propagation paths (probably as simple as distance-squared and > distance-t
Re: [Flightgear-devel] Real-Time Radio Propagation
On Thursday, December 13, 2012 01:03:45 Vivian Meazza wrote: > Don't we need radar altitude for buildings etc. for radar altimeters, but > probably not trees? > > A radar altimeter needs to sample both the terrain and "hard" objects on > it. > > However, I watch this work with interest: I think it might make it worth > reviewing the AG radar that I abandoned due to the impact on frame rate, > and lack of realistic range because not enough tiles were loaded, > > > Vivian > > Vivian > Yeah... to be discussed. I don't know much about trees, except that they are nodes made out of a couple of vertices (I think Stuat can correct me on this). But you're right about the buildings and radar alt. I suggest changing the signature of FGScenery::get_elevation_m to include a flag: surface only, and set the traversal mask accordingly. I will do just that today and report the results. I want this to be retro- compatible and no changes to other code that relies on get_elevation_m. Like I mentioned last night, not having to traverse all the random buildings, trees and whatnot speeds the intersect visitor result quite a lot, if only terrain elevation is desired. Any comments? Cheers, Adrian -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Real-Time Radio Propagation
On Wednesday, December 12, 2012 09:16:50 Renk Thorsten wrote: > >> My suggestion is to include this feature, leave it off, and let anyone > >> interested turn it on. > > +1 > > There may be many reasons to reject code, but they roughly fall into two > categories: 1) the idea itself which is coded is not acceptable or 2) the > actual implementation is not acceptable (unstable, degrading > performance,...). Adrian has invested a fair share of time to make it > work, and he introduced the project early on in this list. I think > fairness asks that any argument of type 1) against including the code > should have been given earlier. Otherwise the message sent to possible > future contributors is quite negative. > > > That said, I think doing realtime radio signal propagations is much more > > that we need and much more than we want. At least unless we are > > multi-threading and have a spare CPU for those computations. > > Personally I don't need such a feature, since I'm not so much interested in > IFR. However, I think in many situations we do have spare CPU capacity (I > usually do - with lots of shader work on, GPU speed seems the limiting > factor), and I also think it should be up to the user how he wants to burn > his hardware performance - VFR sightseeing people like me want detailed > shaders, IFR people may want to turn terrain eye candy off but spend the > framerate for radio signal propagation. So including the code as optional > feature seems entirely fine to me, I don't think there's such a > well-defined 'we' with the same wishlist. > > So I would also suggest to include it unless there are issues about > stability, performance degradation if not running, which I'm not > qualified to judge. > > * Thorsten Hi Thorsten, everybody, Thanks for the support messages. I have worked pretty hard to get this feature as stable and performant as possible. Regarding performance of the radio subsystem, I would like to make a technical statement. As most of you know, the main performance issues come from having to repeatedly sample terrain elevation for a large number of points. This is done though and osg::NodeVisitor, which traverses all nodes within the scenegraph which have a certain mask set (in our case, it's SG_NODEMASK_TERRAIN_BIT) Unfortunately, not only the terrain surface has this mask set, but also random objects, random trees, and 'random' buildings. They all share this mask, so an _get_elevation_ call will have to traverse through litterally thousands of nodes which are not related to the terrain surface. In order to improve the performance of the _get_elevation_ method, I have added a new mask, SG_NODEMASK_SURFACE_BIT, which is set only for the surface geometry loaded by the BTG loader. Of course, some other minor code had to be modified, especially for groundcache et al. Very minor modification, basically taking into account of this new nodemask. The BVH bounding boxes stuff has been accounted for (I think I didn't miss anything) Right now, I've modified the _get_elevation_ method to use only this new mask. The performance difference is almost twice as fast, if not more. However, since this might introduce unwanted changes in parts of the code that rely on having radar altitude also from buildings etc., I can write a new function to be used specifically for sampling terrain. I have performed a regular test, with the following parameters: terrain load distance set to 60 km (LOD bare), 3 stations tuned in (2 VOR, 1 VOR-DME), 10 or more minutes of flight. Result here: http://wiki.flightgear.org/File:Radio-perf2.png (enlarge for details). As you might notice, the radio subsystem is not the CPU cycle hungry monster it used to be. The amount of tiles loaded is shown on the map. With less view distance and less terrain, the system will be very CPU friendly but also give innacurate results. Keep in mind that are various other methods to reduce even further the CPU footprint: sample fewer points for an elevation profile, poll a station less often (what polling time would be reasonable for a mean speed of 200 kts?) and disabling landcover influence. Cheers, Adrian -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Real-Time Radio Propagation, Was: Sqlite location
On Tuesday, December 11, 2012 00:40:16 Torsten Dreyer wrote: > Hi, > > let me chime in here with a personal note, hoping it's not offending > anybody. Hi Torsten, and thanks for your detailed message. Let me explain below why realistic radio propagation should be inside Flightgear, and aleviate some of the fears about performance (leaving aside the fact that I would leave the system disabled by default, except for those who are really interested, like flying in an area which requires realistic radio factors). > > Although I like having accurate and detailed computation of our > real-world simulation, I'm not really a friend of the radio propagation > code with the level of detail given. Please let me explain why that is > the case: > The radio stations used for aviation purpose certainly follow the same > physical laws as any other radio station does. However, their > performance have to adhere to some specific rules, mostly set up by the > ICAO. Service volumes is on of these rules, a straight ILS final track > is another etc. If real life's environment disturbes the performance of > the radio stations, the operator has to work hard to override these > environmental impacts. As we usually do not have any detailed > information about how the radio station is set up (and I doubt, we will > ever get those), it's close to impossible to correctly model radio > probagation of a specific station. Well, it certainly is possible to take into account terrain, free-space loss, diffraction over mountain edges and other such stuff the ITM algorithms allow for. All I know is that now, sitting on the ground 88 km away from a VOR station, with hills in between, I have needle deviation. Impossible. Please consider that having realistic radio navigation according to terrain would be as far as I know a unique feature for any flightsimulator I've seen. To refuse to add such a realism enhancing feature would be quite illogic to me. > Adding envirionmental factors besides > terrain and terrain cover and the factors of aircraft installations will > result in a wide range of uncertainty, spoiling all the detailed > computation of the radio signal propagation. Terrain, terrain landcover, and frequency of station are exactly the factors involved in my calculations, the rest comes from published data and equipment specs available all over the web. If needed, I can bring on board a specialist, but I'd rather await request. If needed by a research project, any station can be tuned like in the real world, and evaluated within the simulator. > > As a pilot, I am usually just interested in the factor, if I am within > the service volume of a radio station. If so, I'd expect a clear and > correct indication, probably with the well-known system errors applied. > If I am outside the service volume, the systems may show "something", > but I do not really care about what exactly an ILS indicator (as an > example) is showing. I will make my case with just two screenshots, available from the wiki article, re: published volumes. http://wiki.flightgear.org/images/e/e0/Vor_no_itm.png no real radio http://wiki.flightgear.org/images/c/c6/Vor_itm.png realistic radio Or consider for DME equipment, which is very much more affected by terrain than VOR, due to the 10x times higher frequency: http://wiki.flightgear.org/File:Vor-no-dme.png :VOR with no DME due to propagation over edge of mountain for lower VHF freqs. http://wiki.flightgear.org/File:Vor-dme.png :VOR with DME measurement, once obstruction was cleared. > > From real life experience, I can say that barely two stations behave > the same if you are outside their published range. Sidelobes of a > localizer may appear at on site and may not at another site. False > glideslopes appear here but do not show up somewhere else. It depends > heavily on the local setup of the base equipment (and to some degree on > aircraft installations). However, I have seen the shoreline effect of > ADF stations deflection my ADF needle heavily and I have seen effects of > nearby thunderstorms and lightning on the instruments. I'd love to see > these effects modeled. If I remember correctly, Flightgear used to be used also in university projects, ARINC, etc. Has that changed? The ILS with it's two components is modelled rather simplistic right now. But still it's not possible to receive if obstructed by terrain, trees, buildings etc. Also, the fact that GS uses a higher, therefore more prone to terrain/clutter interference than LOC, is included. How would you feel to make an approach 10 km with a mountain turn like some airports in Swiss, and have ILS indication even while behind the mountains? > > That said, I think doing realtime radio signal propagations is much more > that we need and much more than we want. At least unless we are > multi-threading and have a spare CPU for those computations. Thanks to your patient advice and a lot of time spent tuning the system, I
Re: [Flightgear-devel] Sqlite location
On Monday, December 10, 2012 00:39:23 James Turner wrote: > I did a review of the code, but was travelling all last week with very > erratic Internet access. My feeling is the code is not suitable to be > merged as-is, due to serious structural issues. (Unrelated to the actual > simulation math, which looks plausible but is beyond my expertise). > > In particular the way the code is using subsystems and properties seems > very strange to me. Hi James, I need to know more specifics about what is offending you about the code. The way it's structured now, and meant to be accessed by way of setting properties only, is due to a long mail discussion I've had with Torsten Dreyer, who explained that this is the better way for the future, because it is the most flexible way to have multiple stations with different characteristics. Otherwise, the only other subsystem the radio-system is interacting with is the FGScenery, for obvious reasons (terrain sampling). The radio subsystem, even if you think it has rather ugly code, was optimized for best performance and ease of access from both outside C++ code, and inside main code. It is working and provides the expected results for all types of stations: ATC, VOR, DME, ILS, TACAN. Of course I intend to add more stuff and rewrite some old remnents, but neither Flightgear was perfect when it started, was it? > My proposal is, I'll take your patch as inspiration, > and write a dummy version which does a no-op simulation, but which > interacts with the radio code in a way I think fits with the rest of the > sim. Once I've done that, you can convert your functional code to fit that > structure, and it can be merged. If you are referring to the code inside the navradio, dme, and tacan files, I'd be rather curious if you see a better way of doing things. If you are referring to the radio subsystem (radiosystem.cxx), I'd rather you don't waste your time with that, but instead provide some little clues on what you find wrong. I'm unlikely to massively rewrite the radio subsystem which is tried and tested for over 10 months. > > Hope that sounds reasonable. If you have any questions about the internals that bother you, please feel free to email me in your spare time, and I will either explain, or change the code if a better way exists. Cheers, Adrian > > James > -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Sqlite location
Hi, Can I suggest moving the sqlite amalgamation somewhere in simgear, if it's not too much of a bother? It seems like the proper location for it, doesn't it? I have also transitioned some of my code to use a sqlite database, especiallly for the landcover properties: the names are still those found in materials.xml, but additionally any user can define clutter height and radio density attenuation with a simple sqlite GUI tool. For example a city block may have a mean height of 30 meters and attenuate a radio signal at 108 MHz by 0.7 dB/100 meters. I've used sqlite since the materials files are now very very spread over multiple files and directories, and don't want to touch them for my own purposes. Cheers, Adrian PS: is there anyone willing to check my new radio code in before the feature freeze, even disabled at all, or do I have to wait until next summer? I'd appreciate an honest answer. -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain sampling for elevation
On Saturday, December 01, 2012 19:19:14 geneb wrote: > On Sat, 1 Dec 2012, Adrian Musceac wrote: > > Hi, > > > > Right now, due to some rather encouraging results I've had so far with my > > little terrain sampling experiment, I've started a wiki page on this > > topic: http://wiki.flightgear.org/Terrain_sampling > > I've included a screenshot with a demo of three radio stations each about > > 100 km away from the plain, and the relevant output from the performance > > debug window. > > The perfomance hit I'm seeing is quite similar to the scenery method, > > except it's not as reliable, and the sqlite result can take sometimes > > more time to be retrieved, sometimes less time, being thus quite > > "jumpy". > > This is a very cool feature Adrian. Great job! > > g. Thanks! I'm still not quite happy with the performance of database queries. Having a couple of navaids tuned in and the ocasional ATC transmission does not make much difference, but in a typical ground radar station scenario, there would be tens of aircraft that would need to be polled every couple of seconds. At the current state that would require too much cpu time. Still, I'm searching for ways to improve performance. The good news is that long range terrain sampling is possible even without having tiles loaded. I will keep the wiki page updated and the code in my repo. Perhaps there's someone out there who has dealt with high performance sqlite queries before. Cheers, Adrian -- Keep yourself connected to Go Parallel: INSIGHTS What's next for parallel hardware, programming and related areas? Interviews and blogs by thought leaders keep you ahead of the curve. http://goparallel.sourceforge.net ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain sampling for elevation
Hi, Right now, due to some rather encouraging results I've had so far with my little terrain sampling experiment, I've started a wiki page on this topic: http://wiki.flightgear.org/Terrain_sampling I've included a screenshot with a demo of three radio stations each about 100 km away from the plain, and the relevant output from the performance debug window. The perfomance hit I'm seeing is quite similar to the scenery method, except it's not as reliable, and the sqlite result can take sometimes more time to be retrieved, sometimes less time, being thus quite "jumpy". Feel free to contribute opinions if you are interested in this subject. Cheers, Adrian -- Keep yourself connected to Go Parallel: INSIGHTS What's next for parallel hardware, programming and related areas? Interviews and blogs by thought leaders keep you ahead of the curve. http://goparallel.sourceforge.net ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Musings on FG on Linux/Windows
> Problem is, there are no project leaders. And that worked remarkably > well for quite a while. I think everyone involved in FlighGear is busy > working on other things right now. I know I am, and for a good reason; I > learned the hard way FlighGear isn't going to pay my bill so I spent all > of my time to projects that do. > > So let me be very clear: lack of response has nothing to do with > disrespect or anything like that, until FlightGear provides means to pay > any bills this situation isn't going to chance. > > I know this may feel frustrating sometimes but it's just the fact of life. > > Erik I know I'm a nobody compared to you on this list, but I've given hundreds of hours of time to Flightgear (Durk can testify to that) so I feel I should have a voice. I don't think Fligthgear will EVER provide any means to pay any bills until you (the leaders, whoever feels responsible for the project) stop trying to compete with MSFS and X-Plane in the "mild entertainment" department and start marketing to the big league. I know there are some guys who are trying to do something about that, and some are not even core developers. It's also what I'm trying to do with the realistic radio code, and I will continue to do so until I run out of speed and altitude and I crash and burn. My 2 cents, whatever that's worth these days. Also, thanks ThorstenB for a continuous stream of commits, bugfixes and enhancements, thanks ThorstenR for a great weather system. Keep your speed up and increase your AGL for a while. Cheers, Adrian -- Keep yourself connected to Go Parallel: INSIGHTS What's next for parallel hardware, programming and related areas? Interviews and blogs by thought leaders keep you ahead of the curve. http://goparallel.sourceforge.net ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Implementing realistic radar inside the Flightgear engine
On Wednesday, November 28, 2012 09:51:06 Renk Thorsten wrote: > > I know the advanced weather system uses a C++ random area terrain sampler > > written by Torsten Dreyer. > > Yes - but the way this is currently set up it wouldn't help you - it just > samples various averages and variances of the elevation, it can't be used > to give you a profile of the terrain. > > * Thorsten I know, I was inspired by it when I wrote my own terrain sampler for the radio part. Since we're talking terrain sampling, today I was again inspired by James' work on the navdata cache, and modified the radio terrain sampler to use a sqlite database holding elevation data. This little experiment made me reach a couple of conclusions: 1. This method is way slower than the scenery method, like 20-30 times slower, but works somewhat ok. 2. The elevation database for a 10x10 degree SRTM region is huge even with our filtered data: ~ 700 MB 3. This method allows elevation sampling even when terrain is not loaded, but does not provide material information, of course. Now, if I could only find out and eliminate the speed bottlenecks with sqlite (I have no previous experience with it's C API), maybe this could be an interesting thing. Cheers, Adrian -- Keep yourself connected to Go Parallel: INSIGHTS What's next for parallel hardware, programming and related areas? Interviews and blogs by thought leaders keep you ahead of the curve. http://goparallel.sourceforge.net ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Implementing realistic radar inside the Flightgear engine
On Tuesday, November 27, 2012 15:23:13 Stuart Buchanan wrote: > > I recently implemented a vertical terrain clearance radar for the Douglas > A4F Skyhawkd (a4f) using a combination of Canvas and Nasal terrain > lookups. The code is checked into git if you are interested. > > My main concern when writing it was minimizing the number of terrain > lookups per radar sweep. For the vertical mode this is quite > straightforward as I've simplified the sampling to getting the elevation of > points every 1nm ahead. > > I've still to look at the horizontal modes, but I suspect it would need a > Nasal enhancement to perform terrain intersection tests based on a > lat/lon/heading/pitch combination. I haven't looked into how much effort it > would be to add that yet, though I suspect it should be fairly > straightforward given that we already have similar function handling > mouse-clicks for the ufo. > > -Stuart Hi Stuart, I'm fairly aware of how AG radar modes work, from f16 detailed documentation, but know next to nothing about terrain clearance radar. I will check this out and provide feedback if I can. I have no idea though about Nasal terrain sampling performance. I need to read more about this. I know the advanced weather system uses a C++ random area terrain sampler written by Torsten Dreyer. However, I should have made it clear in my previous message that I was referring to ground-to-air radar, hardcoded as a subsystem, with only the visual interface written with Canvas/Nasal. Cheers, Adrian -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Implementing realistic radar inside the Flightgear engine
Hi, I've seen a couple of external radar clients for Flightgear being developed right now. I think that these days, with the advent of Canvas and other improvements, it should be possible and desirable to have a realistic radar station inside Flightgear. At the moment, I'm only concerned about radar ranges and interference of terrain obstructions, weather, ground clutter. For this purpose, I propose a template implementation of radar transceivers and transponders: It is not possible to provide a detailed terrain picture on every antenna rotation. Sampling all terrrain 360 degrees around the station would cripple performance. Thus, I would just take all positions of aircraft inside the nominal range and perform radio calculations on them, using larger sampling distances and simpler routines for aircraft above a treshhold flightlevel. If terrain around the antenna is obstructing the signal, or weather affects it, we can simulate that correctly. Transponder responses are also a candidate for the new radio code. Like in reality, it is possible to have radar contact but lose transponder id because of radio issues. Awaiting comments, Adrian -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Navaids radio propagation code almost production ready
On Tuesday, November 27, 2012 14:53:07 James Turner wrote: > > Gitorious was down this morning, or I would have already given some review > comments. However I see quite a few new versions of the patch, it would be > good to know it's 'ready' from your perspective, before reviewing. I too > would prefer to merge smaller patches - I didn't yet see how big the > current one is, since Gitorious is still being silly. > > James Hi James, Thanks for reviewing the code. Gitorious is back for me now. The code is production ready and tested, I've just added some little fixes and improvements in the new versions, which don't affect stability on my system. I think it would be best to review and merge as disabled by default, and then allow users to test and find bugs. I can't do that properly alone. Cheers, Adrian -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Navaids radio propagation code almost production ready
Update: I've added new signal calculation for DME stations too. As explained detailed in the wiki, DME uses a very high frequency range, thus it is possible sometimes in reality to receive the VOR signal but not the DME signal. Screenshots provided in the wiki article. Also, TACAN reception is modelled now like the DME, since it uses basically the same frequency range. Unlike DME, I have not tested this yet, but should also work for AI/multiplayer tankers. All this disabled by default, of course. I have not updated the merge request with these features yet, waiting for the new radio to make it into 'next' since it's enough code there already. I have also added a "Request for info" chapter in the wiki page, asking anybody with deep knowledge of air navigation systems to contribute info on the discussion page. Cheers, Adrian -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] system/pitot/total-pressure
On Sunday, November 25, 2012 15:55:44 Eric van den Berg wrote: > Gentlemen, > > I have been looking at the atmosperic system of flightgear and altitude > and airspeed calcs in particular. I have been checking it for > correctness and later looked a bit in the code. > > I must admit that I am not quite clear on how it works, particular the > interaction between FDM and the atmospheric module, but it seems to work > correctly. Although the many unit conversions and lack of significant > numbers tend to decrease accuracy considerably. Hi Eric, Every improvement to the realism of Flightgear is a big step forward. I'm not very knowledgeable about this subject, but there is an older bug report which may be related to your changes: https://code.google.com/p/flightgear-bugs/issues/detail?id=243 which has to do with compressibility effects not being modelled by Yasim. Perhaps with your changes and new ideas, this issue can be solved now by Andy Ross or other contributors. Unfortunately I can see that the team is quite understaffed at the moment, and I hope that our merge requests get through by 3.0. Cheers, Adrian -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Navaids radio propagation code almost production ready
On Monday, November 26, 2012 19:18:26 James Turner wrote: > I'll do a review if no-one beats me to it, but this definitely needs to be > 'off-by-default' for the next release. We can add a checkbox to the > realism dialog to enable it from the GUI, and give aircraft authors a > chance to adapt. > > Well, that's my opinion at least. > > James Emilian pointed out to me that different aircraft can have different types of receivers and antennas for ILS equipment. Of course, if it is desirable, we can make a guideline regarding aircraft developers setting some properties somewhere according to a convention we make. Then we could use these inside the navradio code, so a 747-400 has different equipment behaviour than a Cessna. Also, I'd like to remind everyone who is interested in this that glideslope signals use a different (higher) range of frequencies than VOR/LOC, thus having totally different propagation characteristics, especially in hilly/mountainous terrain. Cheers, Adrian -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Navaids radio propagation code almost production ready
On Monday, November 26, 2012 19:18:26 James Turner wrote: > > I'll do a review if no-one beats me to it, but this definitely needs to be > 'off-by-default' for the next release. We can add a checkbox to the > realism dialog to enable it from the GUI, and give aircraft authors a > chance to adapt. > > Well, that's my opinion at least. > > James It's off by default of course. GUI checkbox would be a plus. Right now it's using command line properties. About aircraft authors needing to adapt, I've had a brief look between C172P which is ok, and C337 Skymaster which does not display the off flag for glideslope when LOC signal still present. It appears to be a case of not checking one property set by the glideslope code (old code, not new one). Aircraft authors basically should not have to worry about whether the new system is on or off, and just use the glideslope flag properties like it's used in C172p's panel. Again, this new code does nothing new to the logic of the navradios, except realistically computing whether a signal is present or not. Cheers, Adrian -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Navaids radio propagation code almost production ready
Hi, I have added VOR, localizer and glideslope signal calculations for the old (classic) navradios (navradio.cxx) Now an ILS navaid is basically considered as two separate stations: Localizer and glideslope, as in reality. Both these stations can have separate parameters like transmitter power, antenna type etc. Tested ok on C172p, but I've seen other aircraft that fail to set the GS flag when the GS signal is lost and LOC signal still present. Localizer on backcourse has range about half the normal one, due to the antenna patterns. This still needs testing for realism, especially since I'm not very happy with the antenna patterns I'm using, and the transmitter powers may be well off for ILS (but are ok for VOR's, according to data I have). Merge request #1568 has been updated today to reflect the changes. The antenna pattern used everywhere should go into $FGDATA/Navaids/Antennas/ but I'm really not keen on placing a merge request for only one text file, so awaiting suggestions. Cheers, Adrian -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] drawing the flight pass in the scenery
On Friday, October 26, 2012 13:56:02 Marcel Baltzer wrote: > Hello folks, > > > > I just freshly started using flightgear for a university project and I > was wondering, if there is an easy method to hard code a subsystem that > displays a calculated route into the scenery or marks objects in the > scenery in a bright color. Therefore I created a new subsystem adding > opengl code doesn't work. > > I really appreciate your ideas! > > > > Thanks, > > Marcel Hi, I just saw this message now, hope it's not too late. You might want to check the way the taxiway path is marked when requesting taxi from ATC. I think your requirements might be similar. I did some work on the taxiway path marker so I am a little familiar with the code. See inside src/Airports/groundnetwork.cxx for details. You could also do this from Nasal and it might be a lot easier for you, but I'm not so familiar with the Nasal library. Cheers, Adrian -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Which navradio code is considered standard?
On Friday, November 23, 2012 15:56:01 James Turner wrote:
Hi James,
> Suggestion: make a runtime switch, to build the 'new' nav-radio when the
> old one is asked for - this can be done via some logic in the instrument
> manager. This of course assumes the visible interface, i.e read / written
> properties, for the new code matches the old, possibly by adding some
> backwards compatibility properties.
>
> (Switch would be a bool prop like /sim/radios/use-new-radios)
Obviously, I should have explained myself this issue: actually the change to
the navradio.cxx and newnavradio.cxx codebase is very small, only adding a
function to set some properties which are then dealt with by the radio
subsystem. I looks somewhat like this:
if( fgGetBool( "/sim/radio/use-radio", false ) ) {
signal_quality_norm = computeSignalQuality(is_loc);
}
where I'm just using a new and rather simple function to get the signal
quality. The rest of the complicated stuff is happening inside the radio
subsystem. This can be enabled at start with --prop:/sim/radio/use-radio
as long with a set of other properties which are all explained detailed in
README.radio inside the minidocs.
>
> If there's a problem making the new code fit the old property API, then you
> have a bigger issue, but updating all the aircraft XML seems ridiculous -
> the current code exposes some slightly strange properties, but emulating
> them in the new code should not be a problem. So, make it a drop-in
> replacement, and make the drop-in automatic via an option. For the current
> release, we'll leave the default as the old code, and after the release is
> out, flip the default to be the new code, for testing by Git users.
>
> Comments?
Of course, no change whatsoever is needed. The classic navradio code as well
as newnavradio already determine the signal strength by some other means, I'm
just using more realistic calculations, that's all. No aircraft XML or
anything else to be updated, just a start-up switch and some other switches
which turn on detailed simulation of antennas, ground clutter attenuation and
other stuff. I took care to write a small guide for the minidocs.
The strange properties you noticed are just internals from the radio
subsystem, and can be used by someone who wants to do radio specific analysis.
If you want to take a look at the code, I'll upload a new branch to my
gitorious clone tonight.
Cheers,
Adrian
>
> James
>
> ---
> --- Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Which navradio code is considered standard?
On Thursday, November 22, 2012 21:44:03 ThorstenB wrote: > navradio is the current/old standard, newnavradio is the new module. > Most aircraft use "navradio", few "newnavradio". I'm not sure if there > is a plan to switch/replace the old radio at some point, and whether the > new module was compatible with the old etc. But for now, both are there. > TorstenD is the expert here. > > cheers, > Thorsten > Ok, here is a comparison using the classic navradio code before and after adding radio propagation calculations: Before: http://wiki.flightgear.org/images/e/e0/Vor_no_itm.png After: http://wiki.flightgear.org/images/c/c6/Vor_itm.png Test performed using C172p trying to receive DVA VOR/DME. The distance is approx 80 km with no line of sight (hills, small mountains, valleys). In both cases the aircraft is on ground, tuned to the frequency of the VOR/DME station. In the first case we have reception and needle deflection, in the second case, as we can clearly see to the right, the radio link budget is simply insufficient to clear the obstacles, despite the high power of the station. No reception, no needle deflection. Cheers, Adrian -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CMake problem
On Friday, November 23, 2012 14:33:58 Renk Thorsten wrote: > I'm just trying to get a working devel environment on my new machine, and > I've succeeded in compiling simgear, but flightgear refuses the cmake > configuration. Basically I want to have the simgear libs inside a user > directory and not system-wide. So what I did is cloning the repositories, > changing to separate build directories and using > > cmake ../../simgear -DCMAKE_INSTALL_PREFIX:PATH=/home/fgfs/FGLib > > followed by > > make CXXFLAGS="-s -O3" > make install > > This created > > /home/fgfs/FGLib/lib64 > /home/fgfs/FGLib/include > > directories which contain all the hxx files and the lib64/ directory > contains libSimGearCore.a libSimGearScene.a, i.e things look normal. > > When I change to my flightgear build directory and do > > cmake ../../flightgear > > I get > > Cannot find SimGear includes! (Forgot 'make install' for SimGear?) > Compile & INSTALL SimGear before configuring FlightGear. When using > non-standard locations, use 'SIMGEAR_DIR' to configure the SimGear > location. > > which is as expected, so I do > > > cmake ../../flightgear -DSIMGEAR_DIR:PATH=/home/fgfs/FGLib > Hi Thorsten, I have a similar setup and I do set -D CMAKE_PREFIX_PATH="/path/to/OpenSceneGraph3;/path/to/plib;/path to/simgear;/path/to/openrti" along with CMAKE_INSTALL_PREFIX:PATH of course. That goes for simgear too, since I have multiple OSG builds. Cheers, Adrian -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Which navradio code is considered standard?
On Thursday, November 22, 2012 21:44:03 ThorstenB wrote: > navradio is the current/old standard, newnavradio is the new module. > Most aircraft use "navradio", few "newnavradio". I'm not sure if there > is a plan to switch/replace the old radio at some point, and whether the > new module was compatible with the old etc. But for now, both are there. > TorstenD is the expert here. > > cheers, > Thorsten Right, classic navradio is done too, but there's a small problem there. Localizer and glideslope would be in reality two different radio stations, with glideslope using frequencies upwards of 300 MHz and different propagation characteristics, antenna configurations etc. Right now ILS is treated as a LOC station only. If glideslope is added as a separate station in the future, it should be no problem, just a couple of lines to rewrite. Ok, so now when flying say 20 km from a VOR station we are tuned into, but we have a range of mountains between or a really big hill and we are nap of the earth, we won't be able to hear the VOR (nor an ILS for that matter), making flying in mountain areas more interesting. The directional radiation pattern used for LOC/GS equipment is a rather crude yagi with 4 elements. This can of course be replaced with something more realistic. Since my old merge request was mothballed for 6 months, I fear that my own branch and fg/next are diverging too much, even if I struggle to keep it updated. There are lots of improvements that I still have to make, but the old radio code which is now in fg/next should really be replaced with the new one which solves some serious issues and brings a lot of improvements. Cheers, Adrian -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Which navradio code is considered standard?
Hi, I've gone ahead and used the new radio code for navaids, but I have a question: which navradio code is considered standard? newnavradio or navradio? Right now the new radio code is used inside newnavradio and works the same for VOR and ILS (i.e. no directional antennas yet for LOC/GS, will follow soon). Tested ok for all VOR stations in range, might need some tweaks to default values. Should I also add it to navradio.cxx? Which one will be used in the future? Cheers, Adrian -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] GPS waypoint sequencing depending on speed
Hi,
Hate to be a nuisance, but is there any reason for this limit:
if (_last_speed_kts < 60) {
// need valid leg course and sensible ground speed to compute the turn
return;
}
in Instrumentation/gps.cxx line 770?
If I have a vehicle with a ground speed of less than 60, the route manager
does not sequence waypoints. Replacing with a value of 10, eveything works
fine.
I think this value is used mostly inside GPS::computeTurnRadiusNm (line 947).
Cheers,
Adrian
--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FSWeekend 2012...
On Wednesday, November 07, 2012 10:30:47 James Turner wrote: > Also, everything on Thorsten's lists is things that FS-X does, or has done > even for some time. Maybe not as good (but maybe better) as our solutions, > but again, that's no help for catching people's initial attention. > > James > What about AI traffic according to real-life schedules, for most major airlines? That's something FS-X doesn't do out of the box. Cheers, Adrian -- LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OpenStreetMap tool to control Flightgear
On Monday, November 05, 2012 20:25:13 James Turner wrote:
> Hmmm, no is the quick answer - if you can wait a little, I'll try to
> replicate this tomorrow.
>
> Regards,
> James
Found the reason myself: in Instrumentation/gps.cxx line 771:
if (_last_speed_kts < 60) {
// need valid leg course and sensible ground speed to compute the turn
return;
}
Is there a reason for that number? I did not dig further into the code, but by
changing that value to a smaller one (10 for instance), the waypoints are
sequenced just fine.
If the limit is absolutely necessary, perhaps we could get around it in some
situations like in my case?
Thanks,
Adrian
--
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OpenStreetMap tool to control Flightgear
On Sunday, November 04, 2012 09:49:25 James Turner wrote: > > Short reply since I'm at FSWeekend still - can reply in more detail > tomorrow. The most likely answer is that the route-manager or GPS is not > activated - activating GPS leg mode should set the route-manger mode > automatically, I think. > > Once that's done, simply passing within 0.1 (IIRC) will sequence the next > wp. > > James > To be more precise, the gps sequencing problem only appears at the second waypoint in the list. With loglevel info, I get the following messages at waypoint #1: GPS doing overflight sequencing 'saw current WP changed, now 1' GPS waypoint index is now 1 current waypt has altitude set, setting on AP route manager, current-wp is now 1 At waypoint #2, the ufo starts circling, and the console is swamped with this message: "already done @ WayptController::setDone" Any ideas? Thanks, Adrian -- LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Regarding the new radio propagation code
Hi all and especially Torsten and Durk, As you know, I had an older merge request containing the new and improved radio code. Since that was ~8 months old and was outdated, I retracted it so you don't have to try to merge in old code over new improvements in trafficcontrol.cxx and other files. I do these myself when I'm updating the source code. Thanks anyway to whoever maintained the old code, I've made sure to backport the changes to the new code. Since the old code is really outdated and is lacking in almost every aspect including performance, it would be highly advised to swich to the new code, if there is interest and time allows. Right now VOR and ILS are not done through the new code. I'm willing to do that myself, if the people who maintain the navradio code are willing to accept me hacking through their code. Cheers, Adrian -- LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OpenStreetMap tool to control Flightgear
> > > > Could someone provide me with some clues here? Is there any specific > > thing the GPS needs to sequence to the next waypoint? > > Short reply since I'm at FSWeekend still - can reply in more detail > tomorrow. The most likely answer is that the route-manager or GPS is not > activated - activating GPS leg mode should set the route-manger mode > automatically, I think. > > Once that's done, simply passing within 0.1 (IIRC) will sequence the next > wp. > > James > Hi James, Thanks for answering. Here is the detailed sequence I use to program the route manager via telnet: fg["/autopilot/route-manager/active"]= 'false' fg["/autopilot/route-manager/input"]= '@clear' fg["/autopilot/route-manager/current-wp"]= '-1' fg["/autopilot/route-manager/input"]= '@posinit' fg["/autopilot/route-manager/input"] = lon,lat@alt .. etc fg["/autopilot/route-manager/input"]= '@activate' fg["/autopilot/route-manager/input"]= '@jump0' fg["/autopilot/settings/target-agl-feet"]= 2 fg["/autopilot/settings/target-agl-ft"]= 2 fg["/autopilot/settings/gps-driving-true-heading"]= 'true' fg["/autopilot/locks/altitude"]= 'agl-hold' fg["/autopilot/locks/heading"]= 'true-heading-hold' fg["/autopilot/settings/target-speed-kt"]= 30 fg["/autopilot/locks/speed"]= 'THR' The first waypoint set is not the UFO position or a runway but an arbitrary point on the map, followed by other arbitrary points. What happens is that the UFO starts just fine towards the first waypoint, but on arrival it starts to circle it and never proceed forward. I think sometimes this happens on the second waypoint, not necessarily the first one. I've looked through the GPS and route manager classes, but I hope you could enlighten me without having to place debug messages through the source code. Thanks, Adrian -- LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] OpenStreetMap tool to control Flightgear
Hi all, I've written a little interface to control Flightgear via an OpenStreetMap interface (at the moment, it can place the ufo at any position on the map, place some virtual radio stations on the ground near the ufo, and also place waypoints for the ufo to follow along a path on the map). My main problem is with the route manager. I can't get the gps to sequence the route manager after the first waypoint at all, and I've also looked through the gps code. Could someone provide me with some clues here? Is there any specific thing the GPS needs to sequence to the next waypoint? Cheers, Adrian -- LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Running Nasal code via telnet connection
Hi there, I'd just like to know if anybody was able to run Nasal code via a normal telnet connection (run nasal /property/where/code/is/located ). I tried, but couldn't manage it, and had to modify a little the code from Network/props.cxx in order to get it to work. Maybe I was doing it wrong, or maybe I should share the patch, please let me know. Cheers, Adrian -- 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] The next FlightGear release (summer 2012)
On Saturday, June 02, 2012 22:36:17 Torsten Dreyer wrote: > Hi, > > in just a bit more than two weeks from now we reach June, 17th, marking > the first milestone for the release of next FlightGear version: the > "feature freeze" period. > > If you have some great and exciting new features for FlightGear on your > local disc but not yet pushed the gitorious repository - now is the time! > Hi Torsten, Is my new radio code (available through an older merge request) going to be included in the next version? I have spent a lot of effort trying to integrate the radio propagation routines and instruments integrated within the Flightgear engine, and I believe it would be a valuable addition to the simulator, nevermind the fact that it would be the first open source engine to perform radio propagation calculations in a 3D environment, and almost real- time. Cheers, Adrian -- 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] Sanitizing materials.xml
On Saturday, February 25, 2012 22:36:34 Stuart Buchanan wrote: > The new file structure is now in place. Note that the file format itself > has not changed, so it should be fairly easy to incorporate your changes. > > Have a look at Materials/default/materials.xml to see how the shared > information is included from the base directory. Hopefully it should make > your materials.xml > smaller (materials-dds.xml was reduced by 50% in size). > > Let me know if you have any problems. > > -Stuart > Right, I'll do the transition as soon as possible. Btw, I listened to the FSBreak podcast, you guys are doing a great job promoting the project. Cheers, Adrian -- 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] Sanitizing materials.xml
On Friday, February 24, 2012 21:38:39 Stuart Buchanan wrote: > > > Regional texturing is a feature which would be nice on GIT - by now, we > > also have enough GPL-compatible textures to pull it off (a while ago, > > Adrian posted a very impressive GLP texture pack in the forum). > > > > I'd be willing to help implementing it. > > That would be great. I saw the textures on the forum, but haven't had the > chance to look at them. I suggest implementing this in a separate > directory (Materials/regional) once the new file structure is in place > (hopefully tonight). > Hi, That texure pack has been updated a couple of weeks ago, adding the new path compatibility changes and also adding a couple of new GPL compatible textures sent by Thorsten to me. I'd be grateful if you decided to add the textures to the main Flightgear repository, since I wouldn't have to worry about maintaining yet another download in another repository :) I'll try to keep up with your new file structure changes, if I can. Cheers, Adrian -- 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 related: groundnetworks and parking
On Thursday, February 23, 2012 01:05:07 Martin Spott wrote: > I do, I've been the first real user of the "xplane" driver in GDAL - > except from Even himself :-) > BTW, I didn't say I "don't want any 850 centerlines as a base for > this". I just wanted to make clear that there's a trap hiding because > you can't rely on v8.50 centerlines being topologically reasonable - > simply because there's no constraint enforcing proper topology. > Ask OSM folks about the big surprise they experienced when they first > tried to build routing on top of their road network. It's the same > with v8.50 centerlines. > > If you'd like to develop automated creation and maintenance of ground > networks in PostGIS on the basis of X-Plane v8.50, then please > negotiate with Durk and go ahead - you know how the database works. > > Cheers, > Martin. Hi Martin, Christian, The main problem I see is the lack of parking positions defined in apt.dat For example, EHAM has 30, EDDF none, LFPO 50. And the parking positions are pretty much essential to the groundnet files. In my script I am generating them automatically, because I have a known airport layout. Anyway, I think it's more likely for the large airports to get attention from scenery designers than for smaller ones. Using taxiway markings was just an idea, now of course I might go ahead and try to come up with a working proof of concept for just one airport, but it's not guaranteed to happen. Cheers, Adrian -- 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 related: groundnetworks and parking
On Wednesday, February 22, 2012 00:57:49 Martin Spott wrote: > > I'll leave it to Durk to commit these files when you consider them > being ready for use. Anyhow I think we'll need some aid for tracking > the ground networks, at least in the long run, as there'll be a lot to > change when people add more custom airport layouts or when we're going > to switch to Robin's latest v8.50 collection. > > Cheers, > Martin. Hi Martin, What do you have in mind for tracking them? As for custom layouts, I think one way or another they would already probably contain groundnet/parking information, and they would likely end up in the scenery database after a while, so any old groundnetworks would get overwritten. As for the switch to v8.50 airports, I already am looking into parsing them too. The "default" airports have a different format, but roughly the same characteristics, so it should be doable. Cheers, Adrian -- 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] linking errors with origin/next?
On Saturday, February 11, 2012 14:01:55 Scott wrote: > thanks Thorsten, > > Now to find out why, must be a static link library somewhere that > isn't getting updated... > > > cheers > S. > Hi, I had the same problem recently, and it took me quite a long while to figure it out. It may be the same for you or not, but I think it's worth mentioning this just in case: if you build simgear and flightgear with CMAKE_BUILD_TYPE="Debug", libraries have a "d" suffix. If afterwards you switch flightgear to "Release" and forget to do the same for simgear, flightgear tries to link to old "Release" simgear libraries which don't have a "d" suffix. Of course, the right way to do this is to have separate build trees for build types, like it's described in the cmake readme, but of course I did not follow this procedure and was bitten by this issue. Worst part was flooding the tracker with fake bug reports and pestering Thorsten because of my local issue :) I still have a common build tree, but now I check the flags beforehand. Cheers, Adrian -- 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 related: groundnetworks and parking
Hi, As a follow-up on yesterday's question, I now can generate in a relatively reliable fashion groundnet files for a certain type of airport, with 9 medium- large parking positions and an AI network which passes the Taxidraw tests (I have randomly tested the files). I have also tested that visual display of the taxi path is correct, and that AI will taxi to active runway via taxiways. There are about 5900 airports which support this operation, plus or minus bugs in my script. Right now I'm trying to generate them all to see if there are any issues to iron out. Like I said previously, the concept can also be extended to the 850 format. Cheers, Adrian -- 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 related: groundnetworks
On Thursday, February 09, 2012 13:40:49 Martin Spott wrote: > Adrian Musceac wrote: > > I'm not too motivated to write such a script, simply because there's no > benefit in it for myself, but I'd be willing to run it on The > MapServer, if it helps. Anyhow, from my perspective the solution to > the problem should be a more generic one. > > First, the easiest way to get a list of airfield without ground network > would be to fetch our list of all airfield and exclude just those few ! > where a ground network is available. Isn't that much cheaper than > scanning the entire World Scenery ? ;-) > > Second, the "generic" solution I'd have in mind would be a completely > different one: Ask the AI system to delay the appearance of the next > aircraft as long as the startup position is occupied, sort AI aircraft > for each startup position by departure time. > I think that's a much more elegant approach and saves you from the > impractical and error-prone overhead of maintaining data about other > data not being available. > > Cheers, > Martin. Hi Martin, I think scanning the airport list obtained with terrasync should do? I'm not sure if terrasync downloads all airports, but I think that's the case. That way I get the list of airports with missing networks. Anyway, what I had in mind was more akin to this: quite a lot of the airports in apt.dat are "generic" ones, that is, they have almost the same, simple, layout, excluding minor differences. Thus, I've started to work on a way to automatically generate groundnetworks for these airports. For an even more advanced solution, airports which use the new 850 apt.dat format have line data for taxiway/routes marking. Of course, using this data would definetly be a lot harder than generating networks for simple "standard" aiports, but I think it could be done in the long term, either as part of the Terragear toolchain, or separately? Anyway, I'm currently not very concerned with this, and I'm pursuing the simple task for default airports (most of them have the same format even in 850 apt.dat). Cheers, Adrian -- 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 related: groundnetworks
Hi, Currently there are a number of airports with missing goundnetwork files, with the obvious consequence that AI aircraft are placed on top of eachother at startup, they do not use taxiways, and the ATC manager cannot assign a taxi route to the player (also this taxi route can't be visually displayed). Now, my question: is there a way to create a list of airports which are missing the groundnetworks, without downloading the whole scenery? If there is none yet, perhaps we can create it using a script (which could be run periodically on the global scenery)? Cheers, Adrian -- 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] Radio simulation of navigational aids
On Tuesday, February 07, 2012 18:31:26 Eric van den Berg wrote: > Hi Adrian, > > Would go with 1. As you say signal strength does not have a major > influence on the functionality itself. It works or you have a flag. Only > of the very border of reception the respective indicator will wander > out. But that also is a signal strength issue and can be modelled > accordingly. > 2. is not realistic as you say yourself. Has nothing to do with those > systems functionality. > 3. would be very interesting to model, but unless it is planned to model > failures (90Hz sender out for instance), interference with other radio > sources (EMI so to say) or some other radio propagation effects I would > not bother. > > Eric Hi Eric, I agree that for now option 1 is the best. If there will be any interest in the future for a more detailed simulation, I will consider #3. Right now, I will use a generic directional antenna pattern for ILS systems, obtained with a 4nec2 generated plot for a yagi antenna. This plot could be replaced easily if the same file format is kept. I'm also willing to consider different file formats for antenna plots, as long as they are not obfuscated, if you or anyone else knows a better tool for electrical antenna analysis that I'm not yet familiar with. I'm not yet sure what to use for aircraft antennas, so I'll leave them omnidirectional for now. Cheers, Adrian -- Keep Your Developer Skills Current with LearnDevNow! 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-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Radio simulation of navigational aids
Hi, While working to add support for realistic radio capabilities of navradio equipment, I have transitioned the radio code to a subsystem, thanks to valuable advice from Torsten, which should remove performance issues and make the system more flexible and useful for other development, like integration with Fgcom. Regarding the simulation of realistic ILS behaviour, I do have a couple of unanswered questions left. Right now, the code is able to simulate realistic coverage of a directional antenna system, like the ones used in localizer and glideslope systems. The navradio code can poll a property which is updated periodically, and obtain a radio signal strength value. This should be enough to simulate range coverage. However, there is still the issue of how to address the simulation of directional features of the localizer and glideslope. Real systems use a rather complicated antenna and feed system, which generates two types of signals, with phase differences being used to modify the modulation depths of two tones (90 Hz and 150 Hz) which are transmitted either with a main carrier or as sideband only. This means that signal strength is not the main factor determining localizer course or glideslope angle. Now, I can see a couple of ways to simulate ILS: 1. Use the signal strength calculation only for available range (and coverage determined by terrain obstructions) and leave the directional calculations as they are now. 2. Simulate a simplified system which uses two virtual antennas to determine localizer course and glideslope angle using only radio signal strength (not realistic but would work, this was tested by me). 3. Go for something as close to real systems as possible. Options 1 and partially 2 are available now. I'd like to know what you think about this, and what paths do you foresee in the future for Flightgear radio. Cheers, Adrian -- Keep Your Developer Skills Current with LearnDevNow! 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-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal API generator
On Monday, January 30, 2012 12:45:26 Gijs de Rooy wrote: > I do see an issue, the menu isn't scrollable and it doesn't fit on my > laptop screen ;) It is cut of at atc-chatter. > > Other than that, nice work! > > Gijs Right, that should be taken care of now. I'm thinking the proper location of this script might be in scripts/python or scripts/tools. Any opinions on that? Cheers, Adrian -- 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
[Flightgear-devel] Nasal API generator
Hi all, I've written a parser to generate a local API documentation for Nasal scripts inside $FGROOT/Nasal. Here is a preview of the result: http://ompldr.org/vY2kwNA/nasal_api.html Is there any interest to add the parser and API doc to the repository? Cheers, Adrian -- 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] [Flightgear-commitlogs] TerraGear / Custom
On Friday, January 20, 2012 07:55:24 Martin Spott wrote: > Martin Spott wrote: > > Topologically cleaned CLC2000v15 is now available on the FlightGear > > MapServer web map and if you download Shapefiles, you'll get them from > > the revised dataset. Please let me know if you encounter technical > > mistakes in this data ! > > CLC2006v15 likewise, > > Martin. Hi Martin, That's great news. I'm curious, what kind of elevation data are you using for the new terrain? SRTMv3 by any chance? Cheers, Adrian -- Keep Your Developer Skills Current with LearnDevNow! 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-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] PostGIS update @ Landcover-DB
On Sunday, January 08, 2012 01:50:50 Martin Spott wrote: I've placed a merge request with the changes. Now it works properly, at least on my machine. Cheers, Adrian -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] PostGIS update @ Landcover-DB
On Sunday, January 08, 2012 01:50:50 Martin Spott wrote: > Martin Spott wrote: > > Cool ! I'll figure how to interface this with the download machinery. > > Ok, from my perspective the interface to "download.psp" works, please > check (fill in the values you prefer): > > > http://mapserver.flightgear.org/download.psp?xmin=6&xmax=7&ymin=50&ymax=51 > > but when I try to call the above download page from the > OpenLayers map: > > > http://mapserver.flightgear.org/testmap/?lon=-156.34932&lat=20.76679&zoom= > 11&layers=B0TFFFTFT > > then I still get the (hardcoded) default values, even though the > input fields in the OpenLayers map get filled properly. > > Any idea ? Heh, that's because I've ommited the name="xmin" part from the input fields :) So you can either add to each input field the name so that it is propagated through the request, or, if you're not really in a hurry, you can wait for me to also add Geoff's code that makes the selection click order irrelevant. Cheers, Adrian -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] PostGIS update @ Landcover-DB
On Saturday, January 07, 2012 20:23:02 Geoff McLane wrote: > Hi Adrian, > > > No, I do NOT think they should be hidden! > > After the user has used the mouse selection, [s]he may choose > to modify the fields, say rounding them, etc, which would be > difficult, impossible with the mouse, so I think they should > stay... even enhanced with labels to say what they are... > > So why not use the right side of the table for this? They > could be set vertically, with labels, to keep the right side > narrow, if that is a concern... > > It would seem unnecessary, and CONFUSING, to have TWO visible > [download buttons], one _ON_ the map and one to the right, no? > Hi Geoff, I was talking about the map at index.php, not the small iframe, of course. I don't know how Martin plans to use the small iframe on the other page, I only modified the index.php part. But your iframe code is good too, if the lightmap is swapped for the big one. Cheers, Adrian -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] PostGIS update @ Landcover-DB
Hi Geoff, Martin, > and thus assume the lightmap/?lon=... URL does in fact > point to this index.php, or something like it... but > maybe this is not right ;=((. > > In fact it is clear there are some differences, but > the source of 'lightmap' was not included in git... Yeah, the small map is not on git, but I asume it's pretty similar to the large one. About the input fields obscuring the map, they may be changed easily into type="hidden", I only left them as text for debugging and testing. The download button is pretty unobtrusive by itself. > Of course the action calling download.psp should set the > values, and inside download.psp need to get these values > and fill in each of the 4 sets... 1:Individual, 2:CS, > 3:CLS and 4:OSM for the user... The coordinates sent by the POST request can be used in download.psp to fill the fields automatically, of course. That was the intent, at least. > > (2) After the two mouse clicks, and the 4 values > correctly filled in, but the yellow/red bounding box outline > has the correct width but has only 1 or 2 pixel height, > positioned at the 2nd click location... if the 1st click > was in the upper left, and the 2nd in the lower right. > > If the first click was in the lower left, and the 2nd > in upper right, this yellow/red outlined box is drawn with > the correct height, but a width of only 1-2 pixels, > at the location of the 1st click... etc... Yeah, that's why I left the comment in the merge request about selecting from lower left to upper right. An OpenLayers thing, values can be swapped at will of course. > except do not understand or see the need for the 'click' > event on this 'box'... Click event could be used in the future to get rid of the download button by auto submitting the form. Or could be removed :) Cheers, adrian -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Multiplayer now very smooth
Hi, We've had a multiplayer session last night, and were very pleasantly surprised to see that it's now very smooth, without the old "jitter" effect, at least for Yasim aircraft. Maybe this is related to commit cf86d37 by Curtis? It may be worth updating issues #120 and #202 which seem to be related. Cheers, Adrian -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] PostGIS update @ Landcover-DB
On Wednesday, January 04, 2012 22:05:13 Martin Spott wrote: > Vadym Kukhtin wrote: > > Why mapserver.flightgear.org have zooming-panning map, if by "Download > > Shapefiles" I still have to type the numbers of coordinates by hands? > > Because someone has to implement the feature you mention ;-) > Feel free to go ahead, the foundation of the web map is OpenLayers. > > Cheers, > Martin. Hi, I've written an OpenLayers handler to populate some input fields with the cooordinates of a drawn box on the map. The zone has to be defined by first clicking on the lower left corner, then on the upper right one. No modification has yet been made to the download script, but it should be pretty simple from there. This is the gitorious merge request: https://gitorious.org/fg/sceneryweb/merge_requests/1 Cheers, Adrian -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Some More Detailed Scenery
Hi and a Happy New Year, On Thursday, December 29, 2011 14:29:16 ThorstenB wrote: > > So, rather than forking development into many little subprojects, and > finding ways to better support these forks, we should find solutions, so > that scenery developers keep joining forces and improve our common > scenery world (uh, that sounds cheesy, right?). No, of course it doesn't. One year ago I have compiled some scenery for eastern Europe, using Corine and OSM. At the time, I was not quite aware of the existing infrastructure and effort to maintain a common database (like the PostGis project). Besides, there was the problem of different licenses for various datasets. If someone would like to analyse the compatibility of various licenses with the Flightgear repo, I'll gladly offer the terrain layers for inclusion in a common repository. Also, I can't reliably host the terrain file myself, and other options have some drawbacks too. Where can I find some documentation on contributing such work? For future reference, here is the forum link: http://www.flightgear.org/forums/viewtopic.php?f=5&t=10464 Cheers, Adrian -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re : Maritime traffic
On Saturday, December 17, 2011 23:19:16 Stuart Buchanan wrote:
> Great work Adrian,
>
> I had something similar working in January - I think I posted
> something to this list. My system used an AI scenario to
> create a number of ships, and then used a perl script to
> query www.marinetraffic.com using the current lon/lat and
> write to the property tree the lon/lat speed and heading of
> all the ships in a given radius. The difficult thing I found was
> that the AIS information wasn't sampled frequently enough.
>
> Let me know if you'd like the scripts and XML I wrote, and I'll
> dig them out for you.
>
> To be honest, I was never very happy with my implementation -
> it was a bit of a hack. I'd be very interested to hear about the details
> of yours, and I'm sure you've thought of something much better!
>
> The ideal might be to push the shipping data onto the MP network,
> but the amount of shipping data would swamp our current MP aircraft
> numbers :)
>
> -Stuart
Hi Stuart,
I didn't know about you attempt. Your method is probably more advanced, since
I'm just using static data, placing models with a Nasal script executed in the
debug console. I'm not sure if dynamic traffic could be done properly, but
maybe storing at least two points for each ship at any time and moving it
between them at the speed reported through AIS may be a solution. Though, I'm
don't know how useful people would find this, and how much of a performance
hit it would be.
Anyway, I'm attaching the Nasal script I used. The data is just a text file,
containing the type of vessel, position, speed and course. I can send that to
you too, if you want, but it's too large to send to the list.
Cheers,
Adrian
var lat = getprop('/position/latitude-deg');
var lon = getprop('/position/longitude-deg');
var lat_max = lat + 0.5;
var lat_min = lat - 0.5;
var lon_max = lon + 0.5;
var lon_min = lon - 0.5;
var path = getprop("/sim/fg-root") ~ "/Nasal/aisdata2.txt";
print( path);
var file = io.readfile(path);
var file_lines = [[]];
var current_word = "";
for (var i = 0; i < size(file); i += 1)
{
var char = substr(file, i, 1);
if (char == "," or char == "\n")
{
append(file_lines[size(file_lines) - 1], current_word);
current_word = "";
if (char == "\n") append(file_lines, []);
}
else
{
current_word ~= char;
}
}
foreach(var line; file_lines)
{
var model = "";
if(line[0]==1)
{
model = "Models/Maritime/Civilian/MediumFerry.xml";
}
if(line[0]==2)
{
model = "Models/Maritime/Civilian/ContainerShip.xml";
}
if(line[0]==3)
{
model = "Models/Maritime/Civilian/CruiseShip.xml";
}
if(line[0]==4)
{
model = "Models/Maritime/Civilian/Tanker_sailing.xml";
}
if(line[0]==5)
{
model = "Models/Maritime/Civilian/Trawler.xml";
}
if(line[0]==6)
{
model = "Models/Maritime/Civilian/SailBoatUnderSail.xml";
}
if(line[0]==7)
{
model = "Models/Maritime/Civilian/LargeTrawler.xml";
}
if(line[0]==0)
{
model = "Models/Maritime/Misc/MarkerBuoy.xml";
}
#var heading = rand() * 360;
var lat_ok =0;
var lon_ok =0;
var height =0;
if(line[3]==0)
{
height=-1;
}
#print(line[0]);
if( (line[2] <= lat_max) and (line[2] >= lat_min))
{
lat_ok =1;
}
if( (line[1] <= lon_max) and (line[1] >= lon_min))
{
lon_ok =1;
}
if(lat_ok ==1 and lon_ok==1)
{
#print(line[0]);
geo.put_model(model, line[2], line[1], 0, line[4]);
}
}
--
Learn Windows Azure Live! Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure training event for
developers. It will provide a great way to learn Windows Azure and what it
provides. You can attend the event by watching it streamed LIVE online.
Learn more at http://p.sf.net/sfu/ms-windowsazure___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re : Maritime traffic
On Friday, December 16, 2011 14:57:24 Olivier wrote: > Hi, > > That's a nice start! Are you grabbing data from: > http://www.marinetraffic.com/ais/ ? Yes. aprs.fi also has a good feed, although more oriented towards ham radio APRS. AisHub has very detailed NMEA data, but they require you to send a feed before accessing raw data, and I don't live in a coastal area. > In fact, depending on the data format, you may obtain the speed & the type > of the ship with AIS. So if speed=0, you should use a ship without wakes > (eg ship in a harbour, and display a type depending on the type returned > by AIS (cargo, tug, sailing, ...). Type's already done (sort of), but the foam I have no clue how to get rid of it other than a different model. Some images near Amsterdam harbour: http://i.imgur.com/gNBqS.jpg http://i.imgur.com/7Gpyj.jpg http://i.imgur.com/gxN5L.jpg http://i.imgur.com/StpuV.jpg Crowded, I'd say. Cheers, Adrian -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Maritime traffic
Hello everybody, I wrote a little script to add maritime traffic from AIS static data. It's a little crude Nasal script at the moment, but it could be done in C++ to automate the display of traffic according to a certain range/density. I'll be looking at that later. For an explanation of the AIS system see: https://en.wikipedia.org/wiki/Automatic_Identification_System Here are some screenshots taken near LFML and LRCK: http://i.imgur.com/kQ9C4.png http://i.imgur.com/FaEg5.png http://i.imgur.com/NLV5R.jpg http://i.imgur.com/jc3hn.png Right now there's only one model being loaded, so it may look a bit silly. Cheers, Adrian -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] NAV receiver specs
> Thinking of most GA and business aviation aircraft I know the NAV > antenna (VOR/LOC/GS) is always located on the vertical tail, just below > the horizontal tail with a cross or t-tail and on top of the vert. tail > with a low hor. tail. These are usually two antennas, one on each side > of the structure. They are on the vertical tail because NAV signals are > polarized horizontally and thus the antenna must be installed that way > (unlike COM which is polarized vertically and you will find these > antennas standing up or down.) Thanks, I didn't know NAV is polarized horizontally (which makes sense given the need for an elevated pattern). I've been doing some reading about ground VOR equipment, and it seems there are 3 main types. Terminal VOR - around 50 W ERP, service radius approximately 25 miles under 12000 feet Low altitude VOR - power output unknown, range 80 miles under 18000 feet High altitude VOR - around 200 W, range 200 miles above 2 feet I got this information from the book "Aviator's guide to GPS" by Bill Clarke. Other sources on the internet which seem particularly reliable to me, mention a standard setting of 100-130 W with a maximum power of 200 W, which is set based on local site surveys. Cheers, Adrian -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] NAV receiver specs
On Monday, November 28, 2011 20:20:03 Eric van den Berg wrote: > > That I do not know. But I do know there are long-range and short-range > VOR-s with significantly different output levels. Not sure how to > determine the difference easily. > For NDB-s it is more easy. The short range ones are on or near the > threshold and at the FAP typically. > Ok, I understand. I will postpone any VOR-related code until I can get specific data. The whole point of this code is to increase the realism, so if real data is not available, it's better to leave it like that for now. I've looked through the navradio code written by Torsten before starting to add radio attenuation to VOR's, and it's currently calculated based on service cone radius at different altitudes. While obviously this does not take into account any terrain obstruction, it's going to be more accurate as far as range is concerned - if the attenuation code has no hard figures for power output. > > Well the standard in GA aircraft is RG400. Which is pretty crappy > (approx. 12.5dB per 100ft). If you take a typical GA aircraft 10m in > length, NAV unit in cockpit, VOR/LOC/GS antenna on the vertical tail. > Antenna cable may be 15m (50ft) + one bulkhead connector (another > 1.5dB?) = 7.5 dB signal loss (=38% signal strength left). > Bigger aircraft have corresponding longer antenna cables and a pressure > cabins (so more possible bulkhead feed-throughs: these connectors are > real signal killers) which might use RG213 or even RG393. > Oh, I see your point now, I was expecting at least RG58, but I now realize that weight is an issue for an aircraft. I will provide a separate field for cable+connector losses, which could be configured for each aircraft. > Another big influence is the antenna pattern of the antenna on the > aircraft. Fuselage, wing and empennage are the blocking structures of > course. If you want I can have a look and get you some "typical" data > for "structure blocked signal loss". > > A lot of aircraft have a seperate GS antenna in the cockpit because: > 1. antenna cable short (NAV unit is in cockpit usually) > 2. excellent view of the runway (...) Thanks for the information. Of course, this would depend on the antenna position on the fuselage. Would it be placed underneath the aircraft? Perhaps the antenna gain might be increased in some situations by the fuselage acting as a huge reflector? Since there can be many specific situations, antenna gain will be configurable on a case by case basis. I will spend more time doing research, but would definetly appreciate if you know a reliable source for this type of information online. As I said earlier, I think it could be possible to add antenna radiation patterns, at least in a simplified way. Cheers, Adrian -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] NAV receiver specs
> > The nav.dat file contains 'range' in nm for the nav-aid. > http://data.x-plane.com/file_specs/Nav740.htm > > Perhaps you could use some heuristic to create a reasonable power level to > meet the published range? > > Ron > Oh I see then, my bad, I was not aware of this fact. Of course, the navradio code already does that, so I guess I'll have to forget about this issue because of data unavailability. Cheers, Adrian -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] NAV receiver specs
On Monday, November 28, 2011 18:31:42 Eric van den Berg wrote: > For GA (what I have handy right now): > The good old Garmin 400 series: VOR/LOC:-103.5dBm, GS:-87dBm > Avidyne (EntegraII): VOR: 5uV, LOC and GS: 10uV > > www.repeater-builder.com/measuring-*sensitivity*/*dbm*2uv.pdf > /for conversion table!/ > > The Avidyne is TSO minimums if I remember correctly. Their units tend to > depend on GPS (and thus do not care much for radio navigation). > > Airline stuff goes down to like 0.5uV (so much more sensitive and > expensive). They can receive a VOR signal at FL300 at quasi-optical range! > Thanks, that is useful data! From what I could gather from different sources on the internet, typical VOR ground equipment operates with around 100-200 W ERP, am I correct? > Antenna cable losses have to be added for in airplane performance (and > they are usually significant). I will make the antenna gain configurable for each station/aircraft, so any cable losses can be added into the system that way. I think that losses might not be very high in the VHF airband unless the aircraft uses very crappy coax or a significant length, but that might change for GS frequencies in the 300 MHz range, of course. Cheers, Adrian -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] More information on the radio code
Hello everyone, I've added a short article on the wiki with details of the features the radio code adds, its implementation, and future intentions. http://wiki.flightgear.org/Radio_Propagation One possible application that I can think of besides those mentioned in the article would be simulating low power emergency beacons in rough terrain. I'm also considering adding antenna radiation patterns, thus enabling directional signal characteristics. Of course, this is all work in progress, so the details are rather fluid. Suggestions are always welcome. Cheers, Adrian -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] NAV receiver specs
Hi there, I'm about to start implementing navradio signal propagation, and I'd like to know from anyone who has experience with this type of radios whether this spec sheet performance is typical for most receivers including airline big iron, so that I should hardcode or not the values. https://www.bendixking.com/wingman/servlet/com.merx.npoint.servlets.DocumentServlet?docid=doc689082ce- f7ddb4bf1a-762df96555eb2dc6f382507bde7144eb The meaningful quoted figures for sensitivity are: VOR/LOC - 2 uV for half flag, 1 uV typical Glideslope - 12 uV typical, 20 uV for half flag Cheers, Adrian -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Festical voice volumes
Hi everybody,
I'm almost finished implementing radio propagation for ATC communications, but
there's one thing I can't figure out yet: I'm trying to set Festival voice
volume to a lower value when the radio signal is near the receiver threshold,
but all my attempts using
fgSetDouble("/sim/sound/voices/voice/volume", volume);
fail to make any difference.
I'd appreciate a pointer to the right direction here.
Thanks,
Adrian
--
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain textures
On Tuesday, November 22, 2011 19:09:27 Erik Hofman wrote: > That sounds about right. > > > I think the new work from Emilian/Vivian needs some new policy for the > > .dds files. I see formats up to 2048 x 2048 pixel size. > > That might be a good idea, but it's also a good idea to check if it is > actually necessary to make them 2048x2048 or that maybe a smaller size > will look (almost) as good. > > Erik > The problem with small textures is that patterns on them become very visible at high altitudes. On the other hand, good textures with no visible repeating features are quite hard to obtain. I've tested on my setup with up to 4096x4096, mapped on a correspondingly high area. This gives very good results at high or low altitudes and almost eliminates the need for more than one texture per material, but the size of the textures becomes a problem. Anyway, I think it would be a good idea to keep the high detail textures for the future, or as an option for those who can afford it now, and scale them appropriately for default usage. Cheers, Adrian -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain textures
Hi Yves, The issue here is that some of these textures are really large, and thus have the potential to limit performance for users with lower-end machines. Thus, I'm interested in guidelines/policies regarding texturing the terrain, what sizes are recommended or usable etc. I also agree about about having a unified texture scheme (or more, to suit different tastes/seasons/regions). Cheers, Adrian On Tuesday, November 22, 2011 14:23:09 HB-GRAL wrote: > Hi Adrian > > I think quality textures like yours goes directly to the main repo ? On > the other hand I heared there is probably central "scenery repo" coming > up (a separate repository and/or database). Maybe also for developing > textures and to store "origins" or base material ? > > Green as I am I started such a database once myself (landcovertex). But > without success, it needs to be close to the main project and at least > 2-3 people working there. Textures can go from there to the main repo > when texture "packs" are ready, when textures are classified and when > changes to materials.xml are applied. I might be wrong, but in my point > of view changing one single texture makes almost no sense for world > scenery. And Git, images, heavy blobs ! ... as you mentioned once > yourself, looking to texture blobs with git does not make a lot of > sense. Thats why I still propose a "texture developing database/gallery" > where main work is done, beside of a repository. > > Cheers, Yves -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fixing fgfs-construct crashes
> I think the solution to this whole issue is to bring fgfs-construct .btg > generation closer to how the genapt works - keeping the material > information around with each poly through the clipping process. Ignore my previous e-mail on this issue, I misread the "each poly" part. Adrian -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Terrain textures
Hi everybody, I have been doing recently some terrain textures experiments, mainly using aerial imagery from USGS and some personal photographs. I have managed to get a number of high resolution textures, and was wondering what the official policy is regarding terrain, and whether they would be eligible to be added to the main repository as is, or whether there is an alternative repository just for texture work. This forum thread contains screenshots of some of these new textures: http://www.flightgear.org/forums/viewtopic.php?f=5&t=14254 Cheers, Adrian -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fixing fgfs-construct crashes
> I think the solution to this whole issue is to bring fgfs-construct .btg
> generation closer to how the genapt works - keeping the material
> information around with each poly through the clipping process.
Hi Peter,
I thought that was already the case? I was fooling around the other day,
modifying the BTG loader to use a material definition for each feature
(fan/strip/triangle), thus loading a different texture from the
instead of only one per tile. Really the only modification I made was to store
the geometry along with the material while loading, instead of loading a
material and then storing all features with that material in the same bin.
That seemed to bring the performance down to a crawl (to be expected since
otherwise this code would probably have been there from day 1). If it's any
use, I'll attach here a diff of my experiments.
Cheers,
Adrian
diff --git a/simgear/scene/tgdb/obj.cxx b/simgear/scene/tgdb/obj.cxx
index d080ff3..ba56c0e 100644
--- a/simgear/scene/tgdb/obj.cxx
+++ b/simgear/scene/tgdb/obj.cxx
@@ -68,7 +68,7 @@
using namespace simgear;
-typedef std::map SGMaterialTriangleMap;
+typedef std::multimap SGMaterialTriangleMap;
typedef std::list SGLightListBin;
typedef std::list SGDirectionalLightListBin;
@@ -190,7 +190,7 @@ struct SGTileGeometryBin {
}
static void
- addTriangleGeometry(SGTexturedTriangleBin& triangles,
+ addTriangleGeometry(SGMaterialTriangleMap& triangleMap, std::string& material_name,
const std::vector& vertices,
const std::vector& normals,
const std::vector& texCoords,
@@ -203,11 +203,11 @@ struct SGTileGeometryBin {
// If the normal indices do not match, they should be inmplicitly
// the same than the vertex indices. So just call ourselves again
// with the matching index vector.
- addTriangleGeometry(triangles, vertices, normals, texCoords,
+ addTriangleGeometry(triangleMap, material_name, vertices, normals, texCoords,
tris_v, tris_v, tris_tc, tcScale);
return;
}
-
+SGTexturedTriangleBin triangles;
for (unsigned i = 2; i < tris_v.size(); i += 3) {
SGVertNormTex v0;
v0.vertex = toVec3f(vertices[tris_v[i-2]]);
@@ -223,10 +223,11 @@ struct SGTileGeometryBin {
v2.texCoord = getTexCoord(texCoords, tris_tc, tcScale, i);
triangles.insert(v0, v1, v2);
}
+triangleMap.insert(std::pair (material_name, triangles));
}
static void
- addStripGeometry(SGTexturedTriangleBin& triangles,
+ addStripGeometry(SGMaterialTriangleMap& triangleMap, std::string& material_name,
const std::vector& vertices,
const std::vector& normals,
const std::vector& texCoords,
@@ -239,11 +240,11 @@ struct SGTileGeometryBin {
// If the normal indices do not match, they should be inmplicitly
// the same than the vertex indices. So just call ourselves again
// with the matching index vector.
- addStripGeometry(triangles, vertices, normals, texCoords,
+ addStripGeometry(triangleMap, material_name, vertices, normals, texCoords,
strips_v, strips_v, strips_tc, tcScale);
return;
}
-
+SGTexturedTriangleBin triangles;
for (unsigned i = 2; i < strips_v.size(); ++i) {
SGVertNormTex v0;
v0.vertex = toVec3f(vertices[strips_v[i-2]]);
@@ -262,10 +263,11 @@ struct SGTileGeometryBin {
else
triangles.insert(v0, v1, v2);
}
+triangleMap.insert(std::pair (material_name, triangles));
}
static void
- addFanGeometry(SGTexturedTriangleBin& triangles,
+ addFanGeometry(SGMaterialTriangleMap& triangleMap, std::string& material_name,
const std::vector& vertices,
const std::vector& normals,
const std::vector& texCoords,
@@ -278,11 +280,11 @@ struct SGTileGeometryBin {
// If the normal indices do not match, they should be implicitly
// the same than the vertex indices. So just call ourselves again
// with the matching index vector.
- addFanGeometry(triangles, vertices, normals, texCoords,
+ addFanGeometry(triangleMap, material_name, vertices, normals, texCoords,
fans_v, fans_v, fans_tc, tcScale);
return;
}
-
+SGTexturedTriangleBin triangles;
SGVertNormTex v0;
v0.vertex = toVec3f(vertices[fans_v[0]]);
v0.normal = normals[fans_n[0]];
@@ -299,6 +301,7 @@ struct SGTileGeometryBin {
triangles.insert(v0, v1, v2);
v1 = v2;
}
+triangleMap.insert(std::pair (material_name, triangles));
}
SGVec2f getTexCoordScale(const std::string& name, SGMaterialLib* matlib)
@@ -325,7 +328,7 @@ struct SGTileGeometryBin {
for (unsigned grp = 0; grp < obj.get_tris_v().size(); ++grp) {
std::string materialName = obj.get_tri_materials()[grp];
SGVec2f tcScale = getTexCoordScal
Re: [Flightgear-devel] cmake
On Friday, November 04, 2011 01:05:25 Jon Stockill wrote: > > Have we changed the default data directory again? cmake outputs this: > -- Using default data-dir: /usr/lib/FlightGear > There doesn't appear to be any way to set it within ccmake or from te > commandline. > I believe it's FG_DATA_DIR, as observed here: https://gitorious.org/fg/flightgear/commit/4b8ef9c3cf4f4f3565de3678cd733ad8067be6d9 Cheers, Adrian -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgfs hangs while loading scenery
On Thursday, October 27, 2011 18:59:18 Michael Sgier wrote: > In my git when looking at airport objects they're loaded but unloaded when > looking elsewhere!- So there's always a huge lag when looking back on the > airport and you can see the objects being loaded again one after the > other. This is very annoying, if someone knows thanks for fixing otherways > I'll look at that someday. > I think this has something to do with animated jetways. Unchecking this option should get rid of the problem (which I did encounter myself at least on KSFO). Cheers, Adrian -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World™ now supports Android™ Apps for the BlackBerry® PlayBook™. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CMake, tomorrow (Sunday 23rd)
On Monday, October 24, 2011 16:53:23 James Turner wrote: > > Mathias' suggestion also works, BTW - specify CMAKE_PREFIX_PATH, with one > (or several) paths to search - I tested that this morning and updated the > README. > > As you guessed, manually setting the the detection variables > (SIMGEAR_VERSION_OK, etc) is a bad idea, unless you set *all* the > generated variables correctly - not impossible, but a lot of work. The > error you report looks like it's happening because the detection script > has got confused, but I need to see the arguments / environment passed to > CMake, to understand why. > > James > Hi James, and thanks for updating the readme. I may be blind or just stupid, but I can't find a way of setting CMAKE_PREFIX_PATH in KDevelop that works. Adding it to environment variables does not do anything, and cmake fails to find the libraries. Do you, or anybody else, know how to get KDevelop to use custom paths the way cmake does with -D CMAKE_PREFIX_PATH ? I'm using KDevelop 4.01 on Debian Squeeze. Thanks, Adrian -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgdata: Important note
On 10/20/11, ThorstenB wrote: > Hi FlightGear, > > there was little input on the fgdata split and few people speaking up > when things were started. We do see a lot of responses now - many being > in favor of the change, but also concerns about remaining issues. > Indeed, setting up the new repo isn't as simple as it seemed initially, > and there are issues which need to be resolved. We also need common > acceptance of the new structure, tools and processes. Thanks for providing a sane solution, based on more than harsh words and hand-waving. I am not a core developer, however some of my work depends on keeping up-to-date with whatever is happening on git, so I feel compelled to speak up. As far as I'm concerned, I find the common fgdata repository as hassle free, however I would have no problem syncing a common aircraft repo too. But I think it would be wise to leave at least some well known aircraft, as well as the UFO inside fgdata proper, for obvious purposes. As far as workflow is concerned, I think the current process (clone, modify, pull request) is quite adequate but could use a little more documentation for new users which do not understand it completely, as seen recently. I speak for nobody but myself, of course. Cheers, Adrian -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A collection of issues
On Thursday, October 06, 2011 10:22:18 thorsten.i.r...@jyu.fi wrote: > Some observations I've made in the last couple of days: > > * hardcoded terrain presampling: This seems to have died on me after the > last pull (probably even earlier?) - currently all I get out is zero > everywhere. Since geodinfo() is now 50 times faster than it used to be, > falling back to the old system doesn't really make a huge difference in > performance though. Whatever you think is best - fixing or going back to > geodinfo() - just let me know please. > Hi Thorsten, I just checked, and src/Environment/terrainsampler.cxx hasn't been changed since July. My radio code also relies on terrain sampling and today's git works as before. Perhaps the problem is somewhere else. Cheers, Adrian -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Newsletter - September 2011
On Monday, October 03, 2011 23:07:08 Gijs de Rooy wrote: > Lots of (big) images this time, we'll have to see if that's something we'd > like to continue with. > The "big" images are probably due to the wiki server missing the ImageMagick tools that generate thumbnails. I don't know who's in charge of the server, but I thought I'd bring it up here. Cheers, Adrian -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
