[Flightgear-devel] FSWeekend 2008
Hello Everybody, This is just a quick announcement / heads-up: FSWeekend, the largest Flight Simulation event in europe being organized on November 1st and 2nd, at Lelystad airport (EHLE). As in previous years, I'm planning to organize a booth, in close collaboration with Martin Spott and Torsten Dreyer, and hopefully a few other people. So, if you happen to be around, please step by to say Hi. :-). In addition, I guess we can still use a few hands to help in runnning the booth. Feel free to contact me when interested. More information can be found here: http://www.fsweekend.com/ Cheers, Durk - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] EGNW apt.dat corrections and additions
--- On Sun, 8/3/08, Martin Fenelon <[EMAIL PROTECTED]> wrote: > From: Martin Fenelon <[EMAIL PROTECTED]> > Subject: [Flightgear-devel] EGNW apt.dat corrections and additions > To: flightgear-devel@lists.sourceforge.net > Date: Sunday, August 3, 2008, 6:35 AM > Hello, > > I've just sent the following minor corrections to Robin > Peel for inclusion > in the next update. > > EGNW (Wickenby) [810 format, Unix line endings]. > > http://awaywiththepixies.org.uk/pub/FlightGear/Aerodromes/EGNW/EGNW-20080802.dat > > Summary of changes: > 1. Runways - default position/length/orientation corrected > (UK AIP) > 2. Windsock - removed four defaults and correctly placed > one unlit > 3. Tower - add tower viewpoint + prevent auto drawing of > tower > 4. Light Beacon - add dummy green+white beacon to prevent > auto creation > 5. Taxiways/Apron - basic structure added > 6. Comms - "Wickenby Radio" A/G frequncy added > > Reference data used (AIP) is freely available via UK/JAA > NATS sources: > http://www.nats-uk.ead-it.com/aip/current/ad/EGNW/EG_AD_2_EGNW_en.pdf > > A few points are worth a mention. The runway surface is > listed as being > concrete although photographs seem to indicate otherwise. I > contacted > the operating company concerned who did indeed confirm that > the runway > surface is now asphalt. Markings are a little odd looking > too. Their > runway is actually a runway marked within an old runway. > Officially > declared distances are all within those markings with no > under or > overrun, despite what looks suspiciously like displaced > thresholds for > 03 and 34. The old eastern taxiway terminates rather > abruptly as what > remains of it is now a public road. > > EFVA is progressing nicely. > > It this the right place to make such postings? > > Kind regards. > > Martin Fenelon. > > > - > This SF.Net email is sponsored by the Moblin Your Move > Developer's challenge > Build the coolest Linux based applications with Moblin SDK > & win great prizes > Grand prize is a trip for two to an Open Source event > anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel Martin, You asked, so here is my two cents worth. I would not post this to the Developers List. I might, from time to time, post progress reports to the Users list. It is good to here that progress is being made even if the results are not immediately apparent. Some other user with the same interest might be willing to help you out. At the least avoid duplication of effort. The frustrating part of editing taxiways is waiting for a scenery rebuild. Most users will not see your improvements till the next scenery release. Thanks for making the FlightgGear world a better place. Paul B. [EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS-Server down?
On Mon, Aug 4, 2008 at 11:53 AM, Curtis Olson wrote: > On Mon, Aug 4, 2008 at 9:05 AM, Curtis Olson wrote: > >> We had a network switch that died yesterday ... the network guy is working >> on getting it replaced this morning. I don't have an eta yet. >> > > Update: the switch has been replaced, but there seems to be a configuration > issue still. Packets get out, but nothing gets back in that the machine can > see ... I'm still working with the net guys to try to prove it's not my own > machine's fault. > Late afternoon cvs server update: the switch configuration issues should now be all sorted out. Somehow after the replacement, no inbound traffic was allowed through, I couldn't even ping the router .. but that should be fixed now. Also in the process of all this, they moved my machine to a different subnet and IP address. I have updated the flightgear.org dns, but it may take several ours to flush through to all the caching dns servers around the world. If you'd like to check that you are getting the correct address from your dns server, the new IP address is 128.101.141.227. (On linux you can run "host cvs.flightgear.org" and you should get this number, if not, you'll have to wait for your dns server's cached entries to expire ... which can be up to 12 hours after I made the change.) Sorry for the mess, but every once in a while a piece of network hardware will go chips up and thankfully they had a new replacement switch already to drop in. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS-Server down?
On Mon, Aug 4, 2008 at 9:05 AM, Curtis Olson wrote: > We had a network switch that died yesterday ... the network guy is working > on getting it replaced this morning. I don't have an eta yet. > Update: the switch has been replaced, but there seems to be a configuration issue still. Packets get out, but nothing gets back in that the machine can see ... I'm still working with the net guys to try to prove it's not my own machine's fault. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS-Server down?
On Mon, Aug 4, 2008 at 8:34 AM, Curtis Olson wrote: > I suggested to Melchior that I would be able to look at it Monday AM ... > it's 8:30am here right now and I'm about to go look at the machine... > We had a network switch that died yesterday ... the network guy is working on getting it replaced this morning. I don't have an eta yet. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS-Server down?
I suggested to Melchior that I would be able to look at it Monday AM ... it's 8:30am here right now and I'm about to go look at the machine... Regards, Curt. On Mon, Aug 4, 2008 at 8:24 AM, Heiko Schulz wrote: > > --- Melchior FRANZ <[EMAIL PROTECTED]> schrieb am Mo, 4.8.2008: > > > Von: Melchior FRANZ <[EMAIL PROTECTED]> > > Betreff: Re: [Flightgear-devel] CVS-Server down? > > An: flightgear-devel@lists.sourceforge.net > > Datum: Montag, 4. August 2008, 15:16 > > * Heiko Schulz -- Monday 04 August 2008: > > > > > > Is there any mirror? > > > > Yes, there are git repos: > > > > $ git clone git://pigeond.net/flightgear/simgear.git > > $ git clone > > git://pigeond.net/flightgear/flightgear.source.git > > > I wanted to update my data- is there any mirror for that in git too? > > > __ > Gesendet von Yahoo! Mail. > Dem pfiffigeren Posteingang. > http://de.overview.mail.yahoo.com > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS-Server down?
--- Melchior FRANZ <[EMAIL PROTECTED]> schrieb am Mo, 4.8.2008: > Von: Melchior FRANZ <[EMAIL PROTECTED]> > Betreff: Re: [Flightgear-devel] CVS-Server down? > An: flightgear-devel@lists.sourceforge.net > Datum: Montag, 4. August 2008, 15:16 > * Heiko Schulz -- Monday 04 August 2008: > > > Is there any mirror? > > Yes, there are git repos: > > $ git clone git://pigeond.net/flightgear/simgear.git > $ git clone > git://pigeond.net/flightgear/flightgear.source.git > I wanted to update my data- is there any mirror for that in git too? __ Gesendet von Yahoo! Mail. Dem pfiffigeren Posteingang. http://de.overview.mail.yahoo.com - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS-Server down?
Hi Heiko, Heiko Schulz wrote: > Is this known? Is there any mirror? CVS as such is not easy about mirroring, because the CVS servers' hostname is stored in the CVS "Root" entry and you would have to change that before updating from a mirror. If you don't mind taking a bypath, then I'd recommend you to have a look at our GIT 'mirror', which is updated twice a day (as long as the main CVS service is alife). This should at least allow easy browsing of the source tree(s) and also allows those people, who are sitting behind a firewall and a HTTP proxy, to track current development (delayed by max. 12 hours) at: http://mapserver.flightgear.org/git/gitweb.pl Mirrors of the official CVS service are marked with the "FlightGear Flight Simulator" description, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS-Server down?
I had the same problem about 12 hours ago... glad to hear it's not just me, meaning it's probably just offline... Cheers, -R. Robert M. Shearman, Jr. Transit Operations Supervisor, University of Maryland Department of Transportation also known as [EMAIL PROTECTED] - Original Message From: Heiko Schulz <[EMAIL PROTECTED]> To: FGFS Developers Mail List Sent: Monday, August 4, 2008 8:56:58 AM Subject: [Flightgear-devel] CVS-Server down? Hi, Tried today to update FGFS, but I can't login: >cvs [login aborted]: connect to cvs.flightgear.org:2401 failed Is this known? Is there any mirror? Regards HHS still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html __ Gesendet von Yahoo! Mail. Dem pfiffigeren Posteingang. http://de.overview.mail.yahoo.com - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS-Server down?
* Heiko Schulz -- Monday 04 August 2008: > Is this known? Yes. More of that network seems to be down, but Curt doesn't have the possibilty/authority to fix it. The theory was that it should be fixed by now. Hmm ... > Is there any mirror? Yes, there are git repos: $ git clone git://pigeond.net/flightgear/simgear.git $ git clone git://pigeond.net/flightgear/flightgear.source.git Had we switched to git already, then we could just continue to work, committing patches to our local copies, and push that to the central repo once it's up again. (With cvs or svn we can just stop working, or create a mess later. :-) m. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Antwoord bij afwezigheid
Ik ben momenteel op vakantie. Woensdag 13 augustus ben ik weer terug. -- I'm on holiday at the moment. I return home at wednesday 13 August. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Antwoord bij afwezigheid
Ik ben momenteel op vakantie. Woensdag 13 augustus ben ik weer terug. -- I'm on holiday at the moment. I return home at wednesday 13 August. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] CVS-Server down?
Hi, Tried today to update FGFS, but I can't login: >cvs [login aborted]: connect to cvs.flightgear.org:2401 failed Is this known? Is there any mirror? Regards HHS still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html __ Gesendet von Yahoo! Mail. Dem pfiffigeren Posteingang. http://de.overview.mail.yahoo.com - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cockpit displays (rendering, modelling)
James Turner schreef: > I'm not clear what there is to be afraid of :) I mean, of course there > needs to be a way to render basic geometry, and there's an issue about > how to do that internally - a 'line' could be rendered by hand-written > Breshnam code into a texture, it could be an OSG node rendered > orthographically, etc, etc. There's many ways to get a 'vector' line > on the screen, but they're mostly dictated by the underlying OSG > rendering approach we adopt. > What I'm suggesting is to make an abstraction for that so that display designers do not need to worry about the OSG code itself, but just define where their lines, points, rectangles, and text will go and the underlying engine will do the rest. Whether this is sent over the network or just stored in a file isn't really an issue -- it can go either way. I am personally in favor of orthographic rendering. > This is what I have a problem with - I'm concerned to get something > simple and workable behaving with the current panels and systems in > FG. So initially I want in-process code, using the existing property > tree, panels and scene graph. While something like your approach would > give maximum flexibility, it's something we could talk about pursuing > once a basic solution that works in FG is established. If we're > rendering each display as an OSG sub-camera, extracting that logic and > wrapping it in a stand-alone OSG viewer should be simplicity itself - > and so long as it's driven by properties, those can be sent over a > socket. That's an approach which seems a lot more bearable to me than > sending per-frame pixel surfaces over shared memory or sockets / pipes. > > James > My approach wouldn't be sending the pixel surfaces (like video) over a network, but sending the low-level geometry that would result in pixel data. The rendering into the actual framebuffer would be done by the receiving application, this would also allow abstraction over different display engines (fx. for Windows developers who may prefer Direct3D or GDI+), so my idea is to make a VM-like structure with instructions like "draw line", "draw polygon", "translate", "rotate" etc. and a stack-based architecture. These instructions could be executed locally (acting on properties) or sent over a network for remote display, or saved to a file for delayed rendering. A property-based display in an OSG viewer could also be a good idea, though, but it has a minor downside of decreased flexibility, since you're placing part of the instruments' intelligence in the client. But it might be a simpler solution in the short term -- and since the property interface is well documented, it wouldn't be hard to connect that to other flight simulation packages as well. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cockpit displays (rendering, modelling)
James Turner schreef: > On 4 Aug 2008, at 10:43, Tim Moore wrote: > >>> Lots of interesting issues here. >>> > > Yep :) > > >> Instrumentation/wxradar.cxx and Instrumentation/od_gauge.cxx are the >> existing >> examples we have of a custom glass instrument. The weather radar >> does work in >> FlightGear OSG; there isn't any weather yet, but it can show other >> aircraft >> traffic and is the basis for the ATC radar. od_gauge.cxx uses the >> method that >> would be used for any glass instrument: an osg::Camera that is bound >> to an >> off-screen render target, i.e a texture. The texture can then be >> used anywhere >> in the scene. >> > > Okay, that fits my basic expectations, great. I'll look more closely > at the od_guage as well as the wx_radar. > > >> You can integrate arbitrary OpenGL code with an OSG application. It >> is most >> friendly to setup and change all OpenGL state using OSG's StateSet >> mechanism, >> but even that is not necessary. We use the GUI code from PLIB, which >> doesn't >> know anything about OSG. See the SGPuDrawable class in Main/ >> renderer.cxx for the >> implementation. The one catch is that OSG has a strong notion of >> separation >> between the update of a "scene" and its rendering, and that might >> not play well >> with arbitrary existing OpenGL code. >> > > Also good to know, though purely in terms of sane design I'd want some > better structure than just hacking up low-level GL calls I think. I > was aware the OSG could wrap arbitrary GL code, I'd just forgotten it > was that easy. Silly me. > A cockpit display doesn't require *arbitrary* GL calls, only the ones related to drawing geometry and transformation are useful. Most special API calls like the ones found in GLU aren't even used. And I don't think basic geometry and transformation would be difficult to map. > I'm also very aware that even for a stand-alone cockpit-display > running full-screen, many elements can be drawn much cheaper as a > texture than as SVG graphics. It's not as aesthetically pure as > specifying everything in pure vector formats, but I'd be happy to use > a mixture of simple vector graphics and bitmap textures to start with, > and the replace the textures with vector art once there's a suitable > renderer. > Err, come on... Compared to a full scene graph, rendering a full-vector graphics cockpit display is like rendering the desktop for most contemporary graphics cards. Textures have their uses (as bitmaps), but they aren't the way to go when emulating vector graphics when you have GPU cycles to spare. My software runs pure vector and it runs smoothly even on a 7-year-old Celeron without a 3D card. And for the record, that's on Windows 2000. >> A moving map is a different beast. It would make sense to implement >> that as a >> scene graph in its own right with its own pager. That would require >> a change in >> current fg architecture to use a CompositeViewer instead of a single >> Viewer, but >> we're contemplating that anyway. >> > > Yep, I agree, moving map is a much harder problem, and not something > I'm going to worry about in the short term. > > James I did a moving map with complete navigation database and flight plan support in one file for my OpenRJ project (see a previous post), and it's about 300-400 lines of code total, including the surrounding MFD's. So a separate scene graph can work if that's what you want but it is not really neccessary. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cockpit displays (rendering, modelling)
Frederic Bouvier wrote: > There is a new OSG pluggin that requires librsvg in OSG 2.6.0 RC1. > I didn't managed to build it under Windows though. Without having a close look at it, I just tried to install the devel package on a stable Debian distribution and noticed that 'librsvg2-dev' pulls a _huge_ list of dependencies, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cockpit displays (rendering, modelling)
On 4 Aug 2008, at 10:54, Frederic Bouvier wrote: > There is a new OSG pluggin that requires librsvg in OSG 2.6.0 RC1. > I didn't managed to build it under Windows though. Depending on something like librsvg is pretty much my idea of hell. It's heavy, depends on libart (or possibly cairo, now), and doesn't seem to be actively developed. To be persuaded on the SVG front, I'd want to be sure there's a reasonably lightweight solution that would map to primitives we can easily support, i.e raw GL or OSG drawables. And it's not like we need a large set of SVG - I think SVG-Tiny would be sufficient, though I've forgotten what features are in each 'level' of the SVG 1.1 standard. Anyway, I'll do some research on the SVG technologies. I sort of feel it's a side issue anyway - whether the compass rose is drawn as an SVG or PNG is the easy part, it's getting the appearance to be reasonably close to a Boeing/Airbus/Primus/Garmin display that will take time, I feel. If the biggest complaint people have is that the graphical elements aren't sharp enough, I'd be happy :) James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cockpit displays (rendering, modelling)
James Turner wrote: > Yeah, I've also (just) been looking at the state of the art in SVG -> > GL rendering. I was hoping to find something reasonably compact, but > there's various dead links and so on. This might be exactly what you need: http://fabrice.bellard.free.fr/TinyGL/ Erik - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cockpit displays (rendering, modelling)
On 4 Aug 2008, at 07:28, R. van Steenbergen wrote: > I fear, though, that in some way you are going to have to fall back to > the rendering of very basic geometry (points, lines, rectangles) > because > they are the basic make-up of a 2D vector display. I'm not clear what there is to be afraid of :) I mean, of course there needs to be a way to render basic geometry, and there's an issue about how to do that internally - a 'line' could be rendered by hand-written Breshnam code into a texture, it could be an OSG node rendered orthographically, etc, etc. There's many ways to get a 'vector' line on the screen, but they're mostly dictated by the underlying OSG rendering approach we adopt. > I am thinking about a small 'dumb' GL rendering application that takes > in geometry data in some sort of byte-code from stdin, a file or a > socket, and outputs GL frame buffer data into a block of memory. If it > would be possible to offer that block of memory to OSG as a texture > and > tell it to map it onto some surface, we pretty much get what we're > looking for, including the degree of flexibilty required by deck > builders. > This tiny app could have other uses as well, as the Blender crew might > be interested into an app that generates pixel data from a raw > geometry > stream, maybe incorporating GPU-accelerated rendering. This is what I have a problem with - I'm concerned to get something simple and workable behaving with the current panels and systems in FG. So initially I want in-process code, using the existing property tree, panels and scene graph. While something like your approach would give maximum flexibility, it's something we could talk about pursuing once a basic solution that works in FG is established. If we're rendering each display as an OSG sub-camera, extracting that logic and wrapping it in a stand-alone OSG viewer should be simplicity itself - and so long as it's driven by properties, those can be sent over a socket. That's an approach which seems a lot more bearable to me than sending per-frame pixel surfaces over shared memory or sockets / pipes. James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cockpit displays (rendering, modelling)
On 4 Aug 2008, at 10:43, Tim Moore wrote: >> Lots of interesting issues here. Yep :) > > Instrumentation/wxradar.cxx and Instrumentation/od_gauge.cxx are the > existing > examples we have of a custom glass instrument. The weather radar > does work in > FlightGear OSG; there isn't any weather yet, but it can show other > aircraft > traffic and is the basis for the ATC radar. od_gauge.cxx uses the > method that > would be used for any glass instrument: an osg::Camera that is bound > to an > off-screen render target, i.e a texture. The texture can then be > used anywhere > in the scene. Okay, that fits my basic expectations, great. I'll look more closely at the od_guage as well as the wx_radar. > You can integrate arbitrary OpenGL code with an OSG application. It > is most > friendly to setup and change all OpenGL state using OSG's StateSet > mechanism, > but even that is not necessary. We use the GUI code from PLIB, which > doesn't > know anything about OSG. See the SGPuDrawable class in Main/ > renderer.cxx for the > implementation. The one catch is that OSG has a strong notion of > separation > between the update of a "scene" and its rendering, and that might > not play well > with arbitrary existing OpenGL code. Also good to know, though purely in terms of sane design I'd want some better structure than just hacking up low-level GL calls I think. I was aware the OSG could wrap arbitrary GL code, I'd just forgotten it was that easy. Silly me. > If a vector description of instruments is the way to go, then you > should look at > using SVG with OpenGL and OSG. The big player here is cairo+glitz, > but the last > time I looked at this it was hard, perhaps impossible, to coax glitz > to draw > into an OpenGL context that it had not created. Perhaps this has > been solved. > Another library is svgl at svgl.sourceforge.net, but I have no idea > if it is > still alive. Any solution that renders to memory using the CPU is > going to be > too slow, IMHO. Yeah, I've also (just) been looking at the state of the art in SVG -> GL rendering. I was hoping to find something reasonably compact, but there's various dead links and so on. We already have some of the components (XML parser) so my preferred approach would be to make something like an osg-svg-kit by borrowing code from a project like svgl, but I really haven't looked at enough code to be sure about that. I'm also pretty wary of SVG as a technology, I've worked on the Mozilla SVG code in the distant past. I'm also very aware that even for a stand-alone cockpit-display running full-screen, many elements can be drawn much cheaper as a texture than as SVG graphics. It's not as aesthetically pure as specifying everything in pure vector formats, but I'd be happy to use a mixture of simple vector graphics and bitmap textures to start with, and the replace the textures with vector art once there's a suitable renderer. Anyway, going to play with svgl now. > > > A moving map is a different beast. It would make sense to implement > that as a > scene graph in its own right with its own pager. That would require > a change in > current fg architecture to use a CompositeViewer instead of a single > Viewer, but > we're contemplating that anyway. Yep, I agree, moving map is a much harder problem, and not something I'm going to worry about in the short term. James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cockpit displays (rendering, modelling)
- "Tim Moore" <[EMAIL PROTECTED]> a écrit : > If a vector description of instruments is the way to go, then you > should look at using SVG with OpenGL and OSG. The big player here > is cairo+glitz, but the last time I looked at this it was hard, > perhaps impossible, to coax glitz to draw into an OpenGL context > that it had not created. Perhaps this has been solved. > Another library is svgl at svgl.sourceforge.net, but I have no idea if > it is still alive. Any solution that renders to memory using the CPU is > going to be too slow, IMHO. There is a new OSG pluggin that requires librsvg in OSG 2.6.0 RC1. I didn't managed to build it under Windows though. -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://fgsd.sourceforge.net/ FlightGear Scenery Designer - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cockpit displays (rendering, modelling)
R. van Steenbergen wrote: > James Turner schreef: >> Yeah, that's an absolute non-starter, same as the OpenGC code - low >> level OpenGL will not be flexible enough, or efficient in the OSG >> scene-graph, is my perception. I hope Tim Moore will pitch in with his >> opinion on the best way to do the OSG integration, separate camera >> feels like the best choice to me, but I need to think about the details. >> >> James >> > I fear, though, that in some way you are going to have to fall back to > the rendering of very basic geometry (points, lines, rectangles) because > they are the basic make-up of a 2D vector display. Lots of interesting issues here. Instrumentation/wxradar.cxx and Instrumentation/od_gauge.cxx are the existing examples we have of a custom glass instrument. The weather radar does work in FlightGear OSG; there isn't any weather yet, but it can show other aircraft traffic and is the basis for the ATC radar. od_gauge.cxx uses the method that would be used for any glass instrument: an osg::Camera that is bound to an off-screen render target, i.e a texture. The texture can then be used anywhere in the scene. You can integrate arbitrary OpenGL code with an OSG application. It is most friendly to setup and change all OpenGL state using OSG's StateSet mechanism, but even that is not necessary. We use the GUI code from PLIB, which doesn't know anything about OSG. See the SGPuDrawable class in Main/renderer.cxx for the implementation. The one catch is that OSG has a strong notion of separation between the update of a "scene" and its rendering, and that might not play well with arbitrary existing OpenGL code. If a vector description of instruments is the way to go, then you should look at using SVG with OpenGL and OSG. The big player here is cairo+glitz, but the last time I looked at this it was hard, perhaps impossible, to coax glitz to draw into an OpenGL context that it had not created. Perhaps this has been solved. Another library is svgl at svgl.sourceforge.net, but I have no idea if it is still alive. Any solution that renders to memory using the CPU is going to be too slow, IMHO. A moving map is a different beast. It would make sense to implement that as a scene graph in its own right with its own pager. That would require a change in current fg architecture to use a CompositeViewer instead of a single Viewer, but we're contemplating that anyway. > > I am thinking about a small 'dumb' GL rendering application that takes > in geometry data in some sort of byte-code from stdin, a file or a > socket, and outputs GL frame buffer data into a block of memory. If it > would be possible to offer that block of memory to OSG as a texture and > tell it to map it onto some surface, we pretty much get what we're > looking for, including the degree of flexibilty required by deck builders. > This tiny app could have other uses as well, as the Blender crew might > be interested into an app that generates pixel data from a raw geometry > stream, maybe incorporating GPU-accelerated rendering. It will be much more efficient to integrate this directly into FlightGear and render to a texture. Otherwise your program and FlightGear will thrash with graphics context switches and you'll have the cost of copying from memory to GPU. Tim - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A patch to prevent multiple loading AIModels on reset
Tatsuhiro Nishioka wrote: > So here is my suggestion. > First, we use my patch as a temporal fix just to prevent the fps drop. > Second, we investigate a reasonable means of loading and unloading AIModels > on reset (and remove my patch). > > Any opinions? Sounds good to me. Erik - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
