Re: [Flightgear-devel] Grr... I am so angry
I agree with Tim here. There are many secondary benefits of time-boxed releases. Getting bugfixes and mindshare improves interactions with the user community and attracts users which ultimately attracts new developers. Of course there is a percentage effort cost to ensure broad stability - but ultimately that comes down to developer discipline and branch structure more than anything. By project agreement you sacrifice a release for high value/high risk changes (like the OSG transition). But beyond that you push for a greater focus on complete changes and as was originally suggested an improved architecture that allows subsystems to be added and removed is the main driver. With this new release, flightgear's multihead capability will be added to the Phoronix Test Suite as a test. (Google for more info). If someone wants to take leadership in improving testability/automated testing with flightgear, that can go a long way to pushing flightgear out further, as well as ensuring that standard releases can be tested. If there is someone willing to step up to the task I can provide more information. Any takers? Regards... Matthew On 12/29/08, Tim Moore timo...@redhat.com wrote: LeeE wrote: Hello dev list, If you're in no mood to critically appraise a rant then read no further. For quite a while now, since I stopped actively contributing to FG, I've been sitting here watching the direction in which FG development is heading and if ever there was a good project, which has potentially boundless scope in the field of VR, but which has lost it's way and is now chasing it's tail up it's own fundament then FG is it. What finally broke this camel's back was the thread about release schedules, but it goes further than that. The idea that FG should be updated and released to what is a purely abstract schedule is disingenuous and destructive nonsense. The origin and sole purpose behind the idea of releasing new versions of software on any sort of regular schedule is to upset and exploit the market for the type of software you're producing; it's a thinly veiled attempt to deter your market from trying, and perhaps adopting, alternative solutions by promising even better things in your future product. This simply doesn't apply to open-source software projects because maintaining or increasing market take-up of your product brings no benefits to you, other than massaging your egos. What we're talking about is doing timebox releases. I suggest you Google the term. There is a steady stream of new features checked into CVS. However, most FG users can't or won't build Flightgear from source, so these features don't see wide use until a release. The fact that we make a release is a signal that we believe the code to be stable and that it is worth the time of packagers, within the FG project and outside, to make a package out of the code at that point. The timebox idea enforces some discipline to get the code ready and not noodle around with new features indefinitely. It's used by many open-source projects today. It will certainly work better with several independent source branches in the repository. So I reject the breathless cynicism of your proposition :) The idea then, that new versions of FG should be released on a regular schedule, is an attempt at competing with something that has no intrinsic value - it's a worthless fight, not only for the effort that it consumes, but for what could be won. The reason that Open-source projects occur at all comes down to one major factor; someone has a better idea. There are a number of secondary reasons for open-source projects, but without that single primary reason they're pointless - what is there to be achieved by simply duplicating what has already been achieved? Simply doing it so that people don't have to pay money for it is not an adequate answer; if people need the software they'll pay for it, if necessary. The 95% of computers that run MS software proves this. The justification for the existence of FG is to make a better solution. 'Better' in this context encompasses several areas: being 'open' is the primary benefit of open-source projects, because whatever you do will never be perfect for everybody, but being open means that other people can progress in their own direction by standing on your shoulders; but they couldn't do whatever they want to do without you doing your bit first. But being 'better' also means other things too. Another important aspect of 'better' includes the overhead of using the FG solution over others, and in this respect FG is getting worse not better. I think many would say that an open-source flight simulator is already a better idea than a closed source one. Not only is it useful for many projects, it is more fun to work on :) ... As a consequence, while the overall design of FG is familiar to many of the developers, no one knows all the details.
Re: [Flightgear-devel] screenshots for v1.9
One nice value-add would be to include sufficient details to allow end users to reproduce the conditions for screenshots. Regards... Matthew On 12/22/08, Heiko Schulz aeitsch...@yahoo.de wrote: Hi, Here are some of my screenies for the gallery! Feel free to take one or more of them. http://www.hoerbird.net/galerie/FGFS1.9.0/index.htm Merry Christmas and a happy new year to all! HHS -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Sent from my mobile device -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Nearcamera still not rendering
Hi, The discussion seems to have died down somewhat on this issue. As of CVS fg/sg yesterday, I do not get the near camera drawn. I would assume that not everyone is seeing this which implies an OSG or driver specific issue. Any ideas or information that needs to be gathered? Regards, Matthew - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear 1.99.5: Release Candidate
I agree. The initial offering from flightgear is fundamentally only for Windows - the expectation under Linux is that the packages will be rolled into distributions. For the aircraft, I would suggest something akin to -base, -realistic, -fun. That would appeal to the different classes of user. It also sends a clear unambigous packaging suggestion to the distribution packages. Regards... Matthew On 11/30/08, Stefan Seifert [EMAIL PROTECTED] wrote: On Sunday, 30. November 2008, Heiko Schulz wrote: Which format zip isn't it MS windows format. ? And what about tar.gz format which is a standard too :) .zip is mainly used on Win but it can also opened on Linux and Mac. But tar.gz can be used also on win but can be opened on win with the OpenSource program 7-zip. Tar.gz compresses IMHO much better, so we should use that. I think the question is not about the archive format itself, but about the contents. That is for example if all the contents are in a folder already or unpack directly into the current directory. Stefan - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Sent from my mobile device - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Further 3D Clouds updates
I haven't applied the patch yet, so I can't give full specs. With CVS as of a few days ago, I did notice that OSG attributed almost double the 'update' time with 3D clouds on. I assume that Tim can comment on what The 'update' time is. I assume this means that (at least prior to your patch) the 3D clouds is current CPU limited. I can't comment on the 'draw' time difference, although it does appear that there are now extra 'cameras' in the last few weeks. On my multi-GPU system I used to have num-displays+1, now I seem to have num-displays*2. Is this expected? For multi-display, this would have an impac on framerate (particular with the serialized mode that is default. I'll discuss more fully in a different email - I just wanted to touch this here in case it is clouds related. Regards... Matthew On 11/26/08, Markus Zojer [EMAIL PROTECTED] wrote: Well, just tested, very nice, I withnessed an improvement in performance. My specs: Athlon XP2000, 768MB ram, NVidia FX 5900 @ 1680x1050 (system: linux with nvidia drivers), no AA Using: sg + fg cvs, OSG 2.7.5; everything enabled, custom settings, using metar, no ai/mp planes around Startup: 30fps 2D/ 20fps 3D (clouds at 6000ft, scattered, thickness 600ft) Flying 400ft/440knots: 26fps 2D/ 19fps 3D (clouds at 6000ft, scattered, thickness 600ft) Flying 6300ft/440knots: 35fps 2d/ 11-22fps (clouds at 6000ft, scattered, thickness 600ft) Note: Flying within the clouds resulted in 22fps, getting very close or through clouds 11fps Changing conditions: Low vis (7000m), clouds at 8000ft(broken) and 4000ft(broken), thickness 600ft Flying @ 8000ft/440knots: 14fps 2D/ 6fps 3D Low vis being also a frame rate killer? Changing conditions: Vis (25000m), clouds at 5500ft(broken), thickness 600ft Flying @ 8000ft/440knots: 25fps 2D/ 16fps 3D Flying @ 6000ft/440knots: 20fps 2D/ 12fps 3D Hope this helps a bit, Markus Stuart Buchanan wrote: Stuart Buchanan wrote: Vivian Meazza wrote: And I have yet to see any 3d clouds. Any clues on where I should be looking (yes the box is checked :-)) Something has changed in the environment manager which means that clouds generateion is now inconsistent. I'm still tracking it down, as my recent changes shouldn't have affected this. Well, the cause was a bug in my code, but it didn't expose itself until we moved to multiple cameras. The attached patch fixes the problem. I've also put in a new heuristic to improve the frame-rate. Clouds that are already sorted are likely to still be sorted in subsequent frames. Therefore I've put in a back-off mechanism for the bubble-sort pass. This should mean that if you stay completely stationary, once the clouds become sorted they will eventually only perform a bubble sort pass every 128 frames. It would be good to get a feel for how bad performance is with 3D clouds. At the moment I don't have a handle on whether performance is almost good enough, or completely unacceptable. I'd appreciate it if people would post their observations, providing details of their machine spec, graphics options and the frame-rate with and without 3D clouds - ideally with a description of the general load on the machine. Thanks, -Stuart - 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=100url=/ ___ 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Sent from my mobile device - 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=100url=/ ___ Flightgear-devel mailing list
[Flightgear-devel] Total Cameras in statistics view
Hi, Recently, I discovered that there seem to be almost the double cameras that there were previously. This is in the event/update/cull/draw page of the statistics page. Is this expected? I also notice that each camera seems to be 'paired' with another camera - as in the 2nd camera will not start it's cull and draw until after the previous one. This is in a 5 camera config across 5 displays. I am using the 'CullThreadPerCamera' model, with the gc.realize commented out with the OSG_SERIALIZE_DRAW variable turned off. Regards... Matthew -- Sent from my mobile device - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Total Cameras in statistics view
Comments within Original Message Subject: Re: [Flightgear-devel] Total Cameras in statistics view From: Tim Moore [EMAIL PROTECTED] To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Date: 26/11/08 09:57 AM Matthew Tippett wrote: Yes. In order to draw our huge Z range -- from the tip of your nose (more or less) out to the horizon -- without flickering and other artifacts, the scene is drawn twice. It's drawn with the near plane set to 100 meters, then the depth buffer is cleared, and the scene is drawn again with the far plane at 100 meters and the near plane at its nominal value, currently .1 meters by default. It's been done this way for some time by a ViewPartitionNode in the scene graph. I recently changed the scheme to use two slave cameras as the camera-like nature of the ViewPartitionNode was screwing up view-dependent shadow work I am doing. Plus, this is the recommended way to do such a partition, according to the wisdom of the OSG users list. There shouldn't be any performance difference in the change to slave cameras, but the statistics for the two cameras will be displayed in the stats display. Okay. So that points a smoking gun at the near camera (call it what you will :) is not getting drawn. Is the complete code submitted? It seems to be spending time in the draw for both the near and far camera. I think others have seen this too. Is there any different camera settings that are needed (I am using camera groups as described in the README.multiscreen with defaults except for the view. I also notice that each camera seems to be 'paired' with another camera - as in the 2nd camera will not start it's cull and draw until after the previous one. This is in a 5 camera config across 5 displays. Because of the depth ordering, the far camera must be drawn before the near camera. Note that this is not new behavior, it is just now exposed in the timing statistics. I don't know why the two cull passes are serialized, unless you're simply running out of processors to run the cull passes. The ordering does make sense, however it appears as the secondary cull occurs immediate after the primary draw completes. I can't get CullThreadPerCameraDrawThreadPerContext to start up reliably, so it might be related to that. Does the slave cameras honor the OSG_SERIALIZE_DRAW variable (also note that Csaba got me to remove a couple of gc.realize() calls to deserialize the CullDrawThreadPerContext draw. I am using the 'CullThreadPerCamera' model, with the gc.realize commented out with the OSG_SERIALIZE_DRAW variable turned off. I don't think that's one of the choices :) Do you mean CullThreadPerCameraDrawThreadPerContext? You might try CullDrawThreadPerContext and see if that gives better performance. As mentioned before, there seems to be deadlocks starting up with CullThreadPerCameraDrawThreadPerContext, but I have found that CullDrawThreadPerContext is quite reliable now. Regards, Matthew - 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=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Non-orthogonal frustums for multi-camera support
Hi, I have been wrestling with this for a few weeks now. As some of you are aware, I am slowly preparing a new multi-head demo with around 8 GPUs in it (so up to 16 heads). The new camera support is great, but there are some problems with the way the frustums work. My understanding is that the fundamental controls are for a direction for the camera. With large numbers of monitors this begins to fall apart. The view frustums will overlap when you don't create an offset and begin to creat monitors in both the horizontal and vertical directions. With offsets you will have to stack the views on top of each other and in theory get the bottom of one frustum to align with the other, but then you end up having visual issues since the cameras are separate. So what I would like to be able to do is take the layout of the cameras, determine their angles to the camera, and define a frustum that has a non-orthogonal face. The first camera code that Tim released seemed to do this (which meant there was some visual quirks for monitors far out to the sides (like verticals being at angles and so on), but for the person sitting in front of all the screens it looked about right. Are there any other magic options that would allow me to get to that? (7+9 is my current plan). Regards, Matthew - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Non-orthogonal frustums for multi-camera support
Thanks. I guess the frustum calculation is possibly the most difficult part (at least investing some more effort) and dusting off the maths. With the original shear code that you implemented first there did appear to be a project of some sort - the far left and right screens exhibit a level of perspective or distortion. I'll see if I can provide a camera layout that demonstrates it. How many monitors do you have (so I can see if I can demonstrate that way). I am guessing that I am missing something on the projection side. My mental model says that if the screen is not perpendicular to my eye, I need to somehow encode that. Unfortunately with the standard multiple monitor stands (2x2) you have some the screens at about 170 degrees to each other - not quite flat. I'll see if I can get something in blender to suit to show what I am using. Even a simple 2x2 layout doesn't quite sit too well at the moment - I'll send some photos later. Regards... Matthew On 11/26/08, Tim Moore [EMAIL PROTECTED] wrote: Matthew Tippett wrote: Hi, I have been wrestling with this for a few weeks now. As some of you are aware, I am slowly preparing a new multi-head demo with around 8 GPUs in it (so up to 16 heads). The new camera support is great, but there are some problems with the way the frustums work. My understanding is that the fundamental controls are for a direction for the camera. With large numbers of monitors this begins to fall apart. The view frustums will overlap when you don't create an offset and begin to creat monitors in both the horizontal and vertical directions. With offsets you will have to stack the views on top of each other and in theory get the bottom of one frustum to align with the other, but then you end up having visual issues since the cameras are separate. So what I would like to be able to do is take the layout of the cameras, determine their angles to the camera, and define a frustum that has a non-orthogonal face. You can't have a frustum with a non-orthogonal face unless you render to a texture and project it, which we don't do. Actually, you don't want to do that unless you're projecting the image unto a screen. OSG does have some builtin support for rendering on domes and such, but I digress. What you need to do for each screen is determine the direction from the eye-point to the plane containing the screen and encode that in the view parameters of the camera for that screen. Then you need to determine the frustum dimensions, which don't need to be symmetric, that place the screen properly in that plane. The first camera code that Tim released seemed to do this (which meant there was some visual quirks for monitors far out to the sides (like verticals being at angles and so on), but for the person sitting in front of all the screens it looked about right. Are there any other magic options that would allow me to get to that? (7+9 is my current plan). Not much magic other than getting out a tape measure and protractor. It might help to build a model of your rig in Blender or another 3D modeling program and make measurements of the model. You could also simplify your geometry by arranging the screens in a cylinder and following the curved monitor example in README.multiscreen. 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Sent from my mobile device - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] screenshots: legal status
I would suggest *NOT* making flightgear responsible for managing the licenses on the images in the gallery. I would suggest however that there be a requirement for the uploader to explicitly state the license that they want. It is a quagmire if you start placing restrictions beyond the standard Creative Commons clauses. Share-alike, deriviatives, commercial use... Each has their advantages and disadvantages, and enhances and diminishes the creator of the works rights. Consequently each person needs to make their own decisions about what they want their images are distributed under. I agree with Gerard's comment that each there should be a default that is implicitly applied if the uploader makes no other assertion. Regards... Matthew On 11/24/08, Melchior FRANZ [EMAIL PROTECTED] wrote: There could be no doubt about the legal status of the screenshots displayed on our webpage. If there's no explicit license, then they are automatically protected by national copyright law in countries which signed the Berne Convention. But we *want* that they be used in articles and reviews about FlightGear, so we have to give explicit permission for that. I've written down on a wiki page what should IMHO be made clear in the future: - conditions for screenshot submitters, to which they have to agree - license terms on the screenshot page on flightgear.org, which explain how the screenshots may be used Consider that English isn't my first language, and that IANAL: http://wiki.flightgear.org/index.php/Submitting_Screenshots Please comment and demand changes that you consider important. If we can come to a result that everyone can live with, then I'd like to let it be reviewed by the Free Software Foundation Europe. (Shane Martin Coughlan was so friendly to offer his help. :-) 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Sent from my mobile device - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] screenshots: legal status
Some potential pitfalls. Who 'is' the flightgear project? Is it the leadership? Is it everyone by consensus? What if the project splits? What if you as an individual does not agree with the project leadership? You have lost your rights. Taking the case of flight sim pro as an example. By saying that 'the great simulator is built from flight gear' (which it does) - then although peope have been up in arms, the flight sim pro guys fulfil the requirement of promoting flight gear hence have access to all of the images on flight gear. Again, as a user you have given up rights and enshrined a subjective phrase in the triggers to permit use. To block the use of the images, you have then add 'explicit permission', then who gives explicit permission? What about if someone creates a fully compliant fork? Does the project licenses fork as well? Since there is no 'legal entity' called flightgear, what 'owns' the license and copyright? Flightsimpro is just a fork of flightgear by the GPL (with no value add at this stage), so where does that sit (considering it triggered the discussion). There are many rights you gain and lose with licensing. Occam's Razor applies. Keep it simple, keep it aligned to legal entities. Images are (more or less) indivisible, keep the license in the of the creator. Code is intermixed and an aggregate of many creators - use a common license. It is a *very* slippery slope that you have to go down to close all the loopholes. If any on the list have been through license negotations, the ones that are costly and mostly leave you unsatisfied are the ones with caveats and try to prevent an explicit past event. Nuff said from here, hope you guys make the right decision now, but also that decision still makes sense in another 12 months when there is a different pressure placed on the decison. Regards... Matthew On 11/24/08, Ron Jensen [EMAIL PROTECTED] wrote: IANAL, I have to agree with Melchior. The project should insist on a single license for the screenshots. I also agree with the basic aims of the suggested wiki license and offer the following suggestions: *** First *** The bullet: - The creator grants the FlightGear project a revokable and non-exclusive copyright, which permits the project: Should read: - The creator grants the FlightGear project a non-revocable, perpetual and non-exclusive copyright license, which permits the project: The submitter should not be able revoke the copyright license once granted. This is the same concept as the GPL. The project should not have to track down and destroy all copies of an image if a submitter becomes disgruntled. Once an image is shared under this license grant is should stay shared. *** Second *** 1. to use the screenshot in documentation and promotion of the FlightGear simulator, including the display on the FlightGear website and all authorized mirrors (including mirrors which are translated to other languages and may include additional services like forums), I suggest we either drop the word authorized from mirrors, or provide an expansive definition of the word authorized to make it an op-out authorization instead of an opt-in. That is, all mirrors are authorized unless explicitly unauthorized. Thanks, Ron On Mon, 2008-11-24 at 21:02 -0500, Matthew Tippett wrote: I am suggesting nothing more complex than a requirement for the description to include a license. No license information - no upload. Forcing a single license for something that is individual and clearly divisble is way too coarse. There should be no maintenance of the flightgear project's side. The issue with a catch-all license is that for someone to do what they want means they need to create an explict exclusion. Please ensure that you have worked through a few scenarios, the project effort to relicense after a mass-licensing is way higher than requesting all users determine what license they want - leaving the remainder to be relicensed if and only if they want to give it up all rights to the project. Regards... Matthew On 11/24/08, Melchior FRANZ [EMAIL PROTECTED] wrote: * Matthew Tippett -- Tuesday 25 November 2008: I would suggest *NOT* making flightgear responsible for managing the licenses on the images in the gallery. But that's exactly what you suggest: that everyone chooses his favorite license, and the project therefore has to manage all that and keep track of the load of licences. That's a lof of work with no gain. Simplicity rules. Yes, better just one license. And that's what the suggestion on the wiki was for. 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
Re: [Flightgear-devel] Z-near problem with new code
It looks like the near clip plane is out too far. CVS fg and sg from yesterday. Regards... Matthew On 11/22/08, Tim Moore [EMAIL PROTECTED] wrote: Frederic Bouvier wrote: Hi Tim, With the new code, I have a zNear problem shown in this screenshot : http://frbouvi.free.fr/flightsim/fgfs_near_problem.jpg This build is still OSG 2.6 based. -Fred Can you tell me what you're expecting to see i.e., is there a cockpit there that isn't displayed, or is this with the UFO? Any other details would be helpful. Thanks, 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Sent from my mobile device - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Z-near problem with new code
I have seen something similar too. The splash screen seems to be 800x600 unscaled in the bottom left of the screen. It then seems to go full screen shortly after though. I doubt it is related to clipping issue mentioned elsewhere. Regards... Matthew On 11/22/08, gerard robin [EMAIL PROTECTED] wrote: On samedi 22 novembre 2008, Frederic Bouvier wrote: In this screenshot : http://frbouvi.free.fr/flightsim/fgfs_near_problem_4.jpg I am seated in the c172. Yes, really ;-) -Fred Matthew Tippett a écrit : It looks like the near clip plane is out too far. CVS fg and sg from yesterday. Regards... Matthew On 11/22/08, Tim Moore [EMAIL PROTECTED] wrote: Frederic Bouvier wrote: Hi Tim, With the new code, I have a zNear problem shown in this screenshot : http://frbouvi.free.fr/flightsim/fgfs_near_problem.jpg This build is still OSG 2.6 based. -Fred Can you tell me what you're expecting to see i.e., is there a cockpit there that isn't displayed, or is this with the UFO? Any other details would be helpful. To me the cvs version which gives the little startup flash screen on the left bottom corner is right with Z-near. -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Sent from my mobile device - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Z-near problem with new code
To add to this, when in 'Fly By' view, a fast moving aircraft will be visible on the approach, will disappear as it passes through the clip plane, the camera will pan and the aircraft will appear to emerge from the clip-plane. Regards... Matthew On 11/22/08, Matthew Tippett [EMAIL PROTECTED] wrote: It looks like the near clip plane is out too far. CVS fg and sg from yesterday. Regards... Matthew On 11/22/08, Tim Moore [EMAIL PROTECTED] wrote: Frederic Bouvier wrote: Hi Tim, With the new code, I have a zNear problem shown in this screenshot : http://frbouvi.free.fr/flightsim/fgfs_near_problem.jpg This build is still OSG 2.6 based. -Fred Can you tell me what you're expecting to see i.e., is there a cockpit there that isn't displayed, or is this with the UFO? Any other details would be helpful. Thanks, 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Sent from my mobile device -- Sent from my mobile device - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Another person selling FlightGear under dubious pretenses
Okay. So, let's look at what actions should be taken. Given that I am not a copyright owner, I have nothing at stake beyond community membership. Regarding the images. We now sufficient information for individuals to assert their copyright on the individual using them. Regarding flightgear, I am still trying to connect the dots on how we can be sure there is a GPL violation. Arnt, Can you describe which parts of the GPL you believe he is violating? Since this list is a public record, I would like to stay away from potentially libelous claims, and stick to verifiable facts. Also, what would your expectation be for any action. There is no morality or advertising clause in the GPL, and almost all of the rights conferred by the GPL are really oriented towards distribution - of which no one has been a recipient. Realistically, if he ships the source on CD, I don't think there is any wrongdoing from flightgear's perspective. Regards... Matthew Regards... Matthew On 11/21/08, James Sleeman [EMAIL PROTECTED] wrote: Arnt Karlsen wrote: ..ok, this far I have found a fake physical address, suggesting my suspicion is confirmable. So I cc. ..unless New Zealand allow a fake address, a fake company, a fake name etc, these are illegally registred web sites. Are we taking about whois data Arnt? The whois data on the domains seems to be sensible to me, infact, it's about 3 KM as the Cub flys from my own house in Hoon Hay. He is very nearby to a very historic airfield which is sadly going to close in a couple of months forever to be made into housing by the landowners :-( I have noticed this rebranding of FG for sale on the dominant auction site here in NZ for quite a long time, but never really felt concerned by it - http://www.trademe.co.nz/Gaming/PC-games/Simulation/auction-188794636.htm Now I look, the trademe username is casey-a from Christchurch, the whois data for the domain indicates this is Mr Andrew Casey of that address. Phone number etc is in the whois. I won't post it here for respect. The whois on flight-aviator.com and idbproductions.com match up. The whois on idb.net.nz doesn't quite, but could just be an work address, it's not very far away. The company name in the whois KcKpers Ltd is a legitimate company, and the Director's address agrees with the whois on the .com domains, you can search the company at www.companies.govt.nz . Mr Casey is the only shareholder (nothing sinister in that, common practice). The company was incorporated in 2002, and Mr Casey was he who did that incorporation and had the same Wigram address at the time. I don't see any fakeness Arnt? Or have I missed half of a conversation somewhere? --- James Sleeman - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Sent from my mobile device - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Another person selling FlightGear under dubious pretenses
A quick review of the site doesn't indicate they are doing anything fundamentally wrong. The acknowledge that it is derived from Flight Gear and that FG is an Open Source project. I am not saying that the way they are presenting it is a nice way to do it. But it is not fundamentally different than what most of the for-profit distribution vendors do when they create a binary distro. The key differentiator of the 'correctness' of what they are doing is if they are not distributing the code - if requested. Or if they are enhancing the source but not distributing it. A polite email from a potential customer asking if the source is available since it is Open Source should clear that concern up. Regarding the use of screenshots, wikipedia seems to always claim 'fair use' for using screenshots to discuss software, but again if as a creator of a screenshot you haven't explicitly declared a license, then a simple request should clean that up too. I am willing to attempt to contact them as an individual to get some more information if people are interested. Regards... Matthew On 11/20/08, Tatsuhiro Nishioka [EMAIL PROTECTED] wrote: On Nov 21, 2008, at 7:49 AM, Stuart Buchanan [EMAIL PROTECTED] wrote: One way to discourage this sort of thing would be to include www.flightgear.org prominently in the startup screens, in the same way that we include initializing sub-systems, initializing scenery. They might replace the string with binary editor. Encoding a massage in some way can be good against such case, maybe not enough but it is a bit hard to find a way to crack it. Possibly with an added message along the lines of Welcome to FlightGear, the free open source flight simulator. That would force the rip-off merchants to at least compile the code, rather than simply replacing some .pngs! We can also hardcore some small image (probably with a checksum validation) showing such message on or next to splash image. This way it may take a while to modify it even they can get source code. But I think there was some discussion on similar idea but not implemented yet, so this probably is not a suitable idea. Maybe a good combination of obfuscation and clear message without messing code is a good idea. Tat - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Sent from my mobile device - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Another person selling FlightGear under dubious pretenses
One thing to be *very* careful of is assuming that flightgear has some absolute right to control what happens downstream. If this company is honoring it's responsibilities under the GPL, there is nothing that the FG community can do to prevent it happening. The GPL enshrines those rights to the recipient, and by extension you give up the right of control as an author when you allow code to be distributed under the GPL. The main thing that the GPL prevents is 'flightsimpro' creating a flightsim that has unique features and linking it into the the main binary and preventing the release of that. But if the developer is keeping their stuff separate (say an advanced-clean room implementation of terrasync using different scenery, or a bridge to a different flight sim network), again they have done nothing wrong by the GPL (distribution of aggregations is a confusing area). Contact with this company would clarify most of this quickly. (A parasite isn't always violating the GPL - a lot of X and kernel developers call Ubuntu a parasite since they don't contribute a proportional amount upstream.) Regards... Matthew On 11/20/08, Stuart Buchanan [EMAIL PROTECTED] wrote: --- On Thu, 20/11/08, Curtis Olson wrote: Someone pointed out this site to me. It probably falls into the category of just barely ok, but I thought I'd post the link here to get some more eyes on it. http://flight-aviator.com/ One way to discourage this sort of thing would be to include www.flightgear.org prominently in the startup screens, in the same way that we include initializing sub-systems, initializing scenery. Possibly with an added message along the lines of Welcome to FlightGear, the free open source flight simulator. That would force the rip-off merchants to at least compile the code, rather than simply replacing some .pngs! -Stuart - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Sent from my mobile device - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] heads up: Boost dependency
As per other discussions, there is nothing stopping fg from creating a set of support libraries that exist in /opt/flightgear. This can be an optional 'we admit we are on the bleeding edge' support package that can be made broadly compatible. If people are interested in a recommended approach for building broadly compatible binaries, then please speak up. Regards... Matthew On 11/20/08, gerard robin [EMAIL PROTECTED] wrote: On vendredi 21 novembre 2008, gerard robin wrote: On vendredi 21 novembre 2008, Csaba Halász wrote: On Tue, Nov 18, 2008 at 11:59 PM, Tim Moore [EMAIL PROTECTED] wrote: FlightGear now has a dependency on the Boost library header files. See boost.org or your favorite distribution. I built against version 1.34, but the latest (1.37) should be fine too. Okay, I know I am kind of late with this, but I just found out that debian stable comes with 1.33. Upgrading to 1.34 would mean having to upgrade gcc to 4.2 and libstdc++ as well. Which would cascade to a lot of other programs. Assuming you haven't used it extensively in ready but not checked in code, I suggest to postpone boost usage until after the planned release is made. Hopefully by the time we release our next version after that, distributions will be shipping 1.34 or later. Just an idea. We will need a rule, these library could bring up to us a consistency problem. On my side, if i look at the wide range of distributions, since i use to install and to update FG on my friends computers,( with Debian, Fedora, and Suze some are 32 bit one is 64 bit ). And i don't include my wife computer :) :) I fear that we won't never have the same version at the same time, but to freeze at a specific stable version ( same problem with OSG). Cheers If no rule, there will be the lucky users/devel who will continue on to update FG with CVS update. Behind the others more or less lucky whose the progress will look like an iregular dotted line. I will regret the PLIB time ( dead period time) when everything was stable. What about a specific Boost source dedicated to FlightGear which could be said stable , and easily built by any user with any distribution. -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Sent from my mobile device - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Another person selling FlightGear under dubious pretenses
Still, the question is if this company is violating the GPL. We have no proof of that. (The gpl-violations.org guys go after people who are not honoring the release of source for both distributed and derived works - typically in embedded systems. Usually they settle when the company honors the GPL and provides source or stops distributing the offending product.) At this stage it appears that they are simply selling a binary distribution of a set of OSS applications. As mentioned before, ethics or questionable business practices aside, we need to focus on what they are actually violating. Even the wikipedia screen shots are licensed under the GPL can be re-used freely. Regards... Matthew On 11/21/08, Arnt Karlsen [EMAIL PROTECTED] wrote: On Thu, 20 Nov 2008 22:37:18 -0500, Matthew wrote in message [EMAIL PROTECTED]: Unfortunately, the GPL doesn't account for emotion. For those who have met RMS, interpersonal relationships don't really fit... Certain rights are gained, others are given up. The best we can hope for is that they are interested in being a part of a community, the worst we should expect is that they add no value and sell it as a package. ..in this case I think we have an excellent opportunity to stand up for the GPL by enforcing it, copyright law and criminal law. ;o) I don't believe that FG I structured in a way to be able to receive funds as an organization, and consequently we can only hope that they will be a good community member and sponsor and assist where they can. If people want me to slueth around and find some more info and ..by all means go ahead. ;o) possibly reach out, please advise. ..here I'd like the copyright owners to weigh in, me, I recommend hiring a lawyer for this job, to make sure we get it _right_. ;o) ..given http://www.idbproductions.com/Products/ and http://idbproductions.com/catalog/ this is _not_ just us, so I'd have Harald Welte and the guys at http://gpl-violations.org/ weigh in with advice on how to proceed. I cc this there. ..playing with dig, jwhois and a web browser and the names I find, it's _amazing_ how I get thrown back to: http://idbproductions.com/catalog/ ;o) Regards... Matthew On 11/20/08, Tatsuhiro Nishioka [EMAIL PROTECTED] wrote: Hi, For clarifying my position, I don't care if they sell flightfear. But I do care if that affects our project in either technically or emotionally. According to some threads or posts in the list and the forum, it seems that many developers and users do not like the current situation. I guess the problem is they don't make any communication with us including contribution. I do welcome some third parties sell flightgear if they are friendly and hopefully make a contribution. Needless to say they need to observe the GPL thingies. You can pack everything into either DVD or thumb drive and sell it as long as it doesn't brake any legal issue. But... For me it's more on human relation issue. As long as they are friendly and actively open to us, then we can collaborate and make flightfear better from both open source and bussiness aspects. I think there is still much room in improving the usability, functionality, and quality of flightgear. If marchants can collect such needs and give some offers and feedback (preferably in implementation, but just an idea is OK) to flightgear community, that'll be super good. Look forward to seeing reply from them, Tat p.s. Sorry for full quote. I'm writing on iPhone. this fun tool is missing copy-past and cut-paste things. On Nov 21, 2008, at 10:16 AM, Matthew Tippett [EMAIL PROTECTED] wrote: One thing to be *very* careful of is assuming that flightgear has some absolute right to control what happens downstream. If this company is honoring it's responsibilities under the GPL, there is nothing that the FG community can do to prevent it happening. The GPL enshrines those rights to the recipient, and by extension you give up the right of control as an author when you allow code to be distributed under the GPL. The main thing that the GPL prevents is 'flightsimpro' creating a flightsim that has unique features and linking it into the the main binary and preventing the release of that. But if the developer is keeping their stuff separate (say an advanced-clean room implementation of terrasync using different scenery, or a bridge to a different flight sim network), again they have done nothing wrong by the GPL (distribution of aggregations is a confusing area). Contact with this company would clarify most of this quickly. (A parasite isn't always violating the GPL - a lot of X and kernel developers call Ubuntu a parasite since they don't contribute a proportional amount upstream.) Regards... Matthew On 11/20/08, Stuart Buchanan [EMAIL PROTECTED] wrote: --- On Thu, 20/11/08, Curtis Olson wrote: Someone pointed
Re: [Flightgear-devel] heads up: Boost dependency
Sure. It is involved and complex, so I didn't want to bother people unless they wanted the information. First, get a compiler built via crosstool - http://www.kegel.com/crosstool/ That allows you to low-bar the baseline glibc and gcc (and hence libstdc++). Then build the out-of-distro packages with that compiler. So long as you target the lowest common denominator you are willing to support, then you can have broad distro support. The real complexity is a) getting the head around using a native cross compiler, b) getting a solid idea of where your dependencies lie in the distro-space. Getting this right is a multi-week effort, but if people are concerned with a new release being out of reach for the majority of distro-users, then it is the only way to go. Regards... Matthew On 11/20/08, Arnt Karlsen [EMAIL PROTECTED] wrote: On Thu, 20 Nov 2008 20:47:46 -0500, Matthew wrote in message [EMAIL PROTECTED]: As per other discussions, there is nothing stopping fg from creating a set of support libraries that exist in /opt/flightgear. This can be an optional 'we admit we are on the bleeding edge' support package that can be made broadly compatible. If people are interested in a recommended approach for building broadly compatible binaries, then please speak up. ..what in the world makes you think we are not interested? The GPL? If you know something useful to us, you just volonteer it. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Sent from my mobile device - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Another person selling FlightGear under dubious pretenses
Comments within. (I am personally uncomfortable including the GPL violations people until we have a clear direction from the leadership of the flightgear project as to the direction the project would like to go). On Fri, Nov 21, 2008 at 1:49 AM, Arnt Karlsen [EMAIL PROTECTED] wrote: Hi, ... Still, the question is if this company is violating the GPL. We have no proof of that. ..I'm checking my wee mirrors to find out. ;o) The GPL can only be violated when they distribute the software. Their website doesn't entail them distributing. Action can only be taken if there is a clear violation (ie: they distribute a flightgear derived product without an offer of distributing source. Who knows, they may include the source in the DVD or CD that they ship. I personally don't want to charge forward and claim a violation when nothing has been distributed. (The gpl-violations.org guys go after people who are not honoring the release of source for both distributed and derived works - typically in embedded systems. Usually they settle when the company honors the GPL and provides source or stops distributing the offending product.) ..aye, this means they have valuable experience and can guide us. ;o) At this stage it appears that they are simply selling a binary distribution of a set of OSS applications. ..then, in good faith, they shouldn't mind saying so. My opinion now is, these people are common criminals, or a tSCOG-style Microsoft proxy team. http://gpl-violations.org/faq/violation-faq.html http://gpl-violations.org/faq/legal-faq.html http://gpl-violations.org/faq/sourcecode-faq.html http://gpl-violations.org/faq/vendor-faq.html But they do say that - http://flight-aviator.com/ === [image: flight]Based on the award winning Flight Gear project [image: flight]All from the thriving Open Source Community, this sim is forever changing === As mentioned before, ethics or questionable business practices aside, we need to focus on what they are actually violating. Even the wikipedia screen shots are licensed under the GPL can be re-used freely. ..aye. Removals of FlightGear.org and GPL etc around these screen shots, would prove a few things though. ;o) I don't see what you are saying. The screenshots don't seem to be trimmed - beyond a possible crop here or there. http://www.flight-aviator.com/images/fps/multiplayer-map.jpg as well as http://www.flight-aviator.com/images/getstart11x.jpg don't seem to be hiding it from being (or being derived from flightgear). The lack of attribution is not quite nice, but is a common mistake. Again, if the flightgear leadership, or the creators (and hence copyright owners) of the images have particular concern then that can put forward when a direction is chosen. ..and keep in mind, top posting is not quite comme-il-feaut at [EMAIL PROTECTED] ;o) I understand, but the google mobile client provides no options to inline quote or bottom quote. (I would actually expect that from a legal perspective a top-posted email thread is far more valuable than a inline posted... But that is a different discussion. :) Please note that I am not saying take no action, I am just saying take a few days to gather what each copyright owner who is impacted wants and ensure a plan is prepared before taking action. Remember, the emotive aspect - although it is real and affects people personally - should not be the prime driver for individuals. The legal framework that each person has implicitly or explicitly has agreed to is what should be driven. (I had a long discussion with some people from Creative Commons that people should also be made aware of what they are giving up. If you CC-Share Alike an image, and then see that image being used to promote something you personally find distasteful - have given up your right to control what the downstream person does with the image. You have no fundamental recourse unless the downstream restricts other people from the Share Alike rights within the license. You may not like it, but you gave up your right to control that when you licensed it. The same goes with the GPL. As mentioned before, I see the baseline direction should be at least the following. 1) Respect copyright - The images and and so on should attributed fully 2) Respect the GPL - If the flightgear derived binaries that are distributed are not accompanied by source or an offer to provide the source that created the binary, then actions should be taken to ensure that it is available. 1) is fairly obvious, but 2) will need someone to buy the CD before taking further actions. Regards, Matthew - 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
Re: [Flightgear-devel] Statistics overlay accuracy.
So I updated to current CVS, and now the behaviour is different. If a camera is looking at the sky, both cull and draw are short. So I assume something was fixed somewhere which is great. Now I need to work out how to stop running out of memory :(... It looks like 64bits is the only way.. As an aside, the xml loader seems to be sub-optimal - loading the same file multiple times (for each camera?). Are there any hints on that behaviour? Regards... Matthew On 11/6/08, Tim Moore [EMAIL PROTECTED] wrote: Matthew Tippett wrote: Comments within. Original Message Subject: Re: [Flightgear-devel] Statistics overlay accuracy. From: Csaba Halász [EMAIL PROTECTED] ... On Wed, Nov 5, 2008 at 11:26 PM, Matthew Tippett [EMAIL PROTECTED] wrote: My two issues are 1) It appears as if environment loading is added to 'draw' statistic. Scenery loading is done in the pager thread, don't think that is counted into the draw time. It seems be. When there are the stalls when moving to a new area or seeing new parts of the scenery it appears to be attached to the draw. My rationale for this is that in the 'serialized' draw mode the start time for each raw appears to be concurrent 10 milliseconds after each other. The other couple of hundred of milliseconds for each camera seem to run in parallel. When no stalling is occurring, the draws are correctly serialized. A portion of scenery loading is done within the draw threads: textures are bound and otherwise initialized (e.g., mipmaps are generated in hardware), shader programs are compiled and linked, and display lists are created. These operations require a valid OpenGL context, which the database pager doesn't have. There is some experimental code in the pager to share OpenGL contexts with the draw threads, but this is rarely used in practice. There is code in the pager to stream these objects to the draw threads so that the impact of this compilation is minimized in any given frame. Several environment variables defined in OpenSceneGraph/src/osgDB/DatabasePager.cpp tune this process: OSG_DO_PRE_COMPILE, OSG_MINIMUM_COMPILE_TIME_PER_FRAME, OSG_MAXIMUM_OBJECTS_TO_COMPILE_PER_FRAME. Also, OSG_DATABASE_PAGER_DRAWABLE controls whether geometry is compiled into display lists or not. I have heard that display lists are not an advantage on ATI hardware; you could try setting that variable to VertexArrays and see if there is much difference in the stalls. Is it possible that the compilation operations, such as texture binding, are serialized in your OpenGL driver? 2) There are blank periods in the graph that doesn't get attributed to event, update, cull or draw.. Could be the time spent during synchronization, for example. I am not sure. Okay. For 1), I am dreading the comment that the measure is from flightgear's call into, and return from osg. Meaning that it is the 'osg' draw that does some black voodoo that both a driver and flightgear have no control over. Sorry :) It is in fact OSG internal statistics. Everything fg does counts into the event time I think. We don't really call into OSG, rather, OSG calls into FG! (apart from our auxiliary threads) Is there an uber-level of statistics that provides lots of extra details (like triangles, lots of other metrics, etc, etc). There is, with current OSG and FlightGear. As you cycle through the statistics you now have modes with detailed geometry information. Some of you may be aware that I am tuning for multiple asics. What I am seeing is there seems to be consistent render times of 6-10 ms per card for the flight data I am replaying. The fg cull operation is nicely parallelized (although I need to confirm timings), but the draws, although parallelized, seem to take an O(n) time to complete (meaning 4 GPUs results in 40 ms for each of the draws that take 10 ms if done serially). Is that when paging scenery, or the steady-state condition? We should carefully examine whether that is a result of the osg stats not being thread safe. It is a known fact that the *display* isn't, I don't know the status of the actual collection. I do not believe that this is related to the stats display. The performance I am experiencing is consistent. There are a few things that I can try to see if there is a driver issue, but realistically it is a bit opaque without instrumenting osg. I'll take a look at the compilation code in the pager and see if these operations are being serialized somehow. Regards, Matthew 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=100url
Re: [Flightgear-devel] FlightGear in IVAO network
My suggestion was along these lines, however I was focusing more on the inter-organization issues than technical. The technical details in my email was matching yours, that is the FG-MP server accepts a connection from *any* trusted MP flight environment. A secure wrapper using public key cryptography should provide that trust. It also allows IVAO to pre-screen incoming data for certain traits that will make the play be blocked from the IVAO network. There are many options as to how to 'keep the sky clear and safe'. This does make IVAO not unique from the FG-MP perspective which raises the value question. If IVAO main value is having FG-MP traffic appear on their network, than the model should have no problems. If however, IVAO sees the value in allowing FG users access to their network as 'peer' pilots, then this model discussed by Curtis and myself diminishes in value considerably. Pep, Can you describe the value-add that FG gives that would be used for ROI assessment for IVAO? Regards... Matthew On 11/11/08, Curtis Olson [EMAIL PROTECTED] wrote: On Tue, Nov 11, 2008 at 2:38 PM, Pep Ribal wrote: I don't think the MP servers have to change their philosophy. I don't think both networks should be merged: it would be better to have the possibility to choose. All this is a personal opinion, but I think your MP should remain intact, with the same philosophy, and just add into IVAO the ability to accept FG connections. You can't lose your identity, you should just gain the possibility to connect your simulator to the network of your choice based on which philosophy best suits you. Hi Pep, I don't know if this idea has been proposed yet FlightGear's multiplayer protocol is published and open. It is also flexible in the sense that we can update or enhance the protocol if we have good reason to do so. (Maybe to add a new feature or data field that is helpful for talking to IVAO networks ... such as a secure open authentication scheme.) The IVAO team could implement a FlightGear compatible interface into their network. The work would be done on their servers, but then nothing would need to change on the FlightGear side. The IVAO team would not need to expose their proprietary communication protocols, but instead would create an implementaion of our open protocols at their side to accept FlightGear connections. They could create their own proprietary interface to our protocol as long as they don't grab any of our code to do so (or maybe the developers that create the flightgear multiplayer system might consider some special license grant to IVAO of at least critical structures in order to make their job easier???) For example, I put the FGNetFDM structure definition in the public domain to facilitate building communication links with proprietary software (matlab for instance.) I designed the FGNetFDM structure so I felt it was my right to do so, and I don't think it has hurt us in anyway. Of course the IVAO folks might be quick to point out that this would expose an open-protocol route into the IVAO networks which is true, but it is completely under their control, so if some day it does become a wide spread problem, they could turn off flightgear access. And they would be able to turn off access from specific ip address or specific subnets or ban specific users. With the help of the smart flightgear developers, we could develop a robust/secure open authentication/communication protocol, and perhaps they could take the lessons learned there and apply them to their wider proprietary network so that they don't need to depend on the shakey concept of security through obscurity. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Sent from my mobile device - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear in IVAO network
Note the subtle suggestion of the discussion here. To avoid exposing/causing concern with the GPL, keeping it completely internal and not distributing it from IVAO seems like a good idea. However, this appears to need FG to expand/revise it's MP interface to allow secure connection of external MP-FS networks. This in effect opens the FG to have other networks (that talk FG-MP) to connect. Note that in this model, IVAO would bridge it's network into FG-MP, and not the other way around. This distinction is critical for the following reason... Assuming a secure connection (public key), we have the following trusts. 1) FG will allow IVAO MP information when a IVAO network connector joins the FG-MP network. 2) By connecting, the IVAO network agrees to receive FG MP information. 3) The public key of the IVAO network is trusted by FG-MP. 4) The FG-MP network has the trust 'power' to deny IVAO if there are any problems by removing the trust of the public key. Note that the primary factor in this FG-MP is master, IVAO is slave is driven by the closed protocols on the IVAO network. It makes a lot more sense for IVAO to create a connector that talks FG-MP, than the FG jump through a larger (and to some a lot less palletable) set of hoops to have FG-MP create a connector to connect as a slave to the IVAO network. (The Master/Slave term sounds wrong and would most likely cause IVAO issues. Truster/trustee sounds more peerish, but doesn't sound architecturally right either. I suggest the two groups settle on terminology ASAP to ensure a common frame of mind.) Regards... Matthew On 11/11/08, Arnt Karlsen [EMAIL PROTECTED] wrote: On Tue, 11 Nov 2008 09:31:34 +0300, Pep wrote in message [EMAIL PROTECTED]: The way IVAO has worked so far, as Curt says, is completely plugin based, in regard of flight simulators, due to the fact that the simulators that log in are not open source (let's change that!). In the case of FG, where FG itself is open source, and the MP server is too, there are two approaches, as Matthew pointed out: One would be FlightGear acting as a IVAO client and connecting directly to IVAO FSD servers. Honestly it was my first though. However, that would be a bit difficult both for FG and IVAO. The other approach, bridging both networks seems to me now better. However, I leave it to you guys to decide which of the two you prefer, though I assume you go for the second one. In case of the second one, we at IVAO could set up a MP server (or more), connected itself to the IVAO FSD servers. ..and if you modify your MP server, and, _keep_ it _in-house_, you are not distributing etc it and therefore you not violating any GPL or any copyrights. I believe this is a valid work-around. And here, as Martin says, starts the religious war. ..nope, it is no longer necessary. ;o) As I understand, a server-server protocol should be implemented. ..yes, and by your guys, Pep. ;o) The authentication stuff, moreover, perhaps will demand a few changes to MP? ..maybe. Then you propose a patch or something, if it goes into FG or FG MP servers, it's subject to copyright and to the GPL. ;o) Once we start agreeing, there will be more things like these to address, I assume. .. ;o) If you confirm this is the way you wish to proceed, please tell me. I'll report to my IVAO bosses and see what they decide. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Sent from my mobile device - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear in IVAO network
I think the key thread passing through each posting is mentioning that the two networks should be bridged. I don't believe the FG developer/user responses indicate a desire to have FG act as a IVAO client, bypassing the existing MP network. Most of the terms used imply a bridging of the two networks, rather than combining them. Note that the IVAO comments seem to imply the opposite, is that IVAO would like to see FG act as a IVAO client. I would suggest understanding the differing topologies and finding a mutually appropriate topology is a lot more important than the technical details. Regards... Matthew On 11/10/08, Martin Spott [EMAIL PROTECTED] wrote: Pep Ribal wrote: The way authentication is handled so far in IVAO ATC (IvAc) and pilot (IvAp) clients is a connection popup window that lets you fill VID and password, which you can retype every time you login, [...] The above comments still don't tell us much about how things are supposed to work, they leave too much room for vague guesses. To make the story short: If IVAO is really serious about getting FlightGear on-board, they should approach FlightGear with a precise idea a) if they have a serious offer to make in terms of network interoperability and b) what they expect FlightGear to deliver. Otherwise, with no dependable information on their hands, I don't expect that people are going to to spend relevant effort on this topic. Best regards, 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Sent from my mobile device - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Statistics overlay accuracy.
Hi, I would like to know who to work with to push for some improvements to the statistics overlay. My two issues are 1) It appears as if environment loading is added to 'draw' statistic. 2) There are blank periods in the graph that doesn't get attributed to event, update, cull or draw.. For 2), if someone says that it isn't a problem, I am fine with that. For 1), I am dreading the comment that the measure is from flightgear's call into, and return from osg. Meaning that it is the 'osg' draw that does some black voodoo that both a driver and flightgear have no control over. Some of you may be aware that I am tuning for multiple asics. What I am seeing is there seems to be consistent render times of 6-10 ms per card for the flight data I am replaying. The fg cull operation is nicely parallelized (although I need to confirm timings), but the draws, although parallelized, seem to take an O(n) time to complete (meaning 4 GPUs results in 40 ms for each of the draws that take 10 ms if done serially). If I can get closer to understanding the 'gl' cost of the draw vs the osg cost of the draw, that would allow me to get optimizations in faster. Any brave soul, willing to work with me? (Tim/Csaba?) Regards... Matthew -- Sent from my mobile device - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Statistics overlay accuracy.
Comments within. Original Message Subject: Re: [Flightgear-devel] Statistics overlay accuracy. From: Csaba Halász [EMAIL PROTECTED] To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Date: 05/11/08 06:11 PM On Wed, Nov 5, 2008 at 11:26 PM, Matthew Tippett [EMAIL PROTECTED] wrote: My two issues are 1) It appears as if environment loading is added to 'draw' statistic. Scenery loading is done in the pager thread, don't think that is counted into the draw time. It seems be. When there are the stalls when moving to a new area or seeing new parts of the scenery it appears to be attached to the draw. My rationale for this is that in the 'serialized' draw mode the start time for each raw appears to be concurrent 10 milliseconds after each other. The other couple of hundred of milliseconds for each camera seem to run in parallel. When no stalling is occurring, the draws are correctly serialized. 2) There are blank periods in the graph that doesn't get attributed to event, update, cull or draw.. Could be the time spent during synchronization, for example. I am not sure. Okay. For 1), I am dreading the comment that the measure is from flightgear's call into, and return from osg. Meaning that it is the 'osg' draw that does some black voodoo that both a driver and flightgear have no control over. Sorry :) It is in fact OSG internal statistics. Everything fg does counts into the event time I think. We don't really call into OSG, rather, OSG calls into FG! (apart from our auxiliary threads) Is there an uber-level of statistics that provides lots of extra details (like triangles, lots of other metrics, etc, etc). Some of you may be aware that I am tuning for multiple asics. What I am seeing is there seems to be consistent render times of 6-10 ms per card for the flight data I am replaying. The fg cull operation is nicely parallelized (although I need to confirm timings), but the draws, although parallelized, seem to take an O(n) time to complete (meaning 4 GPUs results in 40 ms for each of the draws that take 10 ms if done serially). We should carefully examine whether that is a result of the osg stats not being thread safe. It is a known fact that the *display* isn't, I don't know the status of the actual collection. I do not believe that this is related to the stats display. The performance I am experiencing is consistent. There are a few things that I can try to see if there is a driver issue, but realistically it is a bit opaque without instrumenting osg. Regards, Matthew - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D Clouds - patch and progress report
For comparison, can anyone show some screenshots of MS FSX or X-Plane clouds? Regards... Matthew On 10/27/08, gerard robin [EMAIL PROTECTED] wrote: On mardi 28 octobre 2008, Georg Vollnhals wrote: gerard robin schrieb: I did not notice any difference with my graphic card. (7800 GS ) Yes Gerard, the clouds Heiko showed us were much more squared in size compared to your and my pictures. Georg Looking at these snapshot again: yes you are right with squared clouds which can be seen on clouds Heiko, however looking at http://pagesperso-orange.fr/GRTux/Clouds-im1.jpg we can notice squared clouds, the main diff is that the aircraft is in the clouds. -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Sent from my mobile device - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D Clouds - patch and progress report
Out of interest, what do the clouds look like in wireframe? FWIW, if people want to know where to aim.. http://www.sundog-soft.com/ Has some very nice soft, fluffy clouds :). For the modellers/OSG people out there, here is a page that probably gives some interesting clues. Regards, Matthew Original Message Subject: Re: [Flightgear-devel] 3D Clouds - patch and progress report From: Martin Spott [EMAIL PROTECTED] To: flightgear-devel@lists.sourceforge.net Date: 26/10/08 08:47 AM Georg Vollnhals wrote: Until I 3. enabled Environment = Weather scenerio from none to METAR. Does also work if I enable Thunderstorm or fair weather. Surprisingly, if you set another weather scenario via the menu, this is going to find its proper represenation, as seen in the property browser, in the /environment/weather-scenario property. If I set a different scenario via the property browser, this does not have any effect on the visual representation therefore I'm also unable to set a weather scenario via the --prop:/environment/weather-scenario=METAR command line switch. TO me this looks a bit confusing to the user. To be honest, I'd be very happy if someone who thinks she/he has understood how the weather-related options are supposed to work, would write this down as a chapter for The Manual. Cheers, Martin. - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear contest
My suggestion would be a pre-recorded flight contest. http://wiki.flightgear.org/index.php/Suggested_Prerecorded_Flights Rationale is as follows 1) Will provide great demo-fodder http://wiki.flightgear.org/index.php/Presentation_Recipe 2) Will provide a nice basis for improving scenery and eye-candy the flight itself will remain the same, but the rendering and scenery can improve. 3) Will enable automated benchmarking if we become CPU or GPU limited Regards, Matthew Original Message Subject: [Flightgear-devel] Flightgear contest From: Curtis Olson [EMAIL PROTECTED] To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Date: 24/10/08 12:38 PM I've been speaking with a manufacturer of graphics related hardware device. Let me just keep it generic for now, even if the list of names to guess from isn't very long. We were discussing the idea of setting up a contest with one of their units being the grand prize. They would benefit of course by getting more exposure of their product to the flight simulator community. We would benefit by drawing in more users to come take a look at FlightGear. And it doesn't hurt to have a positive relationship with various graphics manufacturers so FlightGear can reasonably support the features in their software and hopefully help make sure their hardware and drivers work well with FlightGear. The prize for the contest would be one unit of this company's flagship product. Value would be in the range of $300-400 let's say. It might be possible to find additional prizes (?) and maybe if this works well it might be possible to offer future contests like this. To the cynical out there ... yes, this is marketing. But it is marketing of a good product that I have personal experience with and have no problem endorsing. It's a product that is of direct interest and relevance to flight sim users and can make the simulation experience more immersive and/or cheaper depending on your perspective, and a contest like this could benefit us if the contest is posted on other forums and we draw more people in to give FlightGear a try. Two contest ideas were presented. 1) A screen shot contest (that implies setting up a way to accept screen shots, and someone has to evaluate the entries and decide on the winner ... could be a lot of work if word of our contest is spread around and we have many entrants.) 2) Another idea would be to setup some sort of FlightGear scavenger hunt. Entries would be done through some web site, entries with the correct answers would all go in a hat and the winner would be drawn out randomly. I like this second idea because to enter the contest, you have to download and install FlightGear, and then learn to run it well enough to explore the FlightGear world and find the answers to the contest questions. Above all, I want to keep things as simple as possible. So my question to the developers is this: 1. Do we like the idea of a scavenger hunt type contest? If so, what types of questions would we ask or what things would we ask people to find? I assume we would keep this to the default scenery area. And we should keep the questions/goals reasonably simple and easy and quick to discover. 2. Since this is marketing, wow, it would really make sense to coordinate a contest with a new release ... but that puts pressure on us to do a release sooner rather than later ... should we push for a November or December FlightGear release and schedule the contest soon after that? 3. Would anyone out there have experience or be willing to help setup a web page for participants to register. I am imagining something pretty simple, where registrants can enter their contact info, and their answers (multiple choice?), and maybe snag their IP address to try to weed out as many duplicate entries as reasonably possible. I don't want contest management to turn into a huge overwhelming burden for me or for someone else. (How much do we worry about people trying to cheat or register too many times?) 4. Is a scavenger hunt too much of a barrier ... forcing people to download FlightGear and actually learn a bit about it might be too hard or take too long for some folks, and they would simply give up and not be able to register ... or answers could get posted on the net and they could skip having to look at FlightGear entirely? There's no rush to decide on a plan today, but a grand prize has been all but offered to us and I think this could draw a lot of attention and interest to FlightGear. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.Net email is sponsored by the Moblin Your Move Developer's
[Flightgear-devel] x86_64 regression?
Hi, I am trying to determine if the CVS tips are broken relative to * x86_64 system, or if I have a bad build/installation. The build is from CVS tips of fg/source, fg/data and sg. The symptoms are 1) Flight data playback doesn't work (complains about no binary input) 2) No key commands 3) No menu I am hoping that almost all of this implies bad fg/data, and so blowing that away will fix it, but don't want throway the MB of data if it may be a regression. Are there anu other CVS users of fg? Regards... Matthew On 10/20/08, robin424 [EMAIL PROTECTED] wrote: Hello, I can't avoid precipitation with the Rendering option menu , is it just me ? Cheers - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Sent from my mobile device - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] x86_64 regression?
Okay. I'll treat my install as bad, and do a clean build and a clean checkout of the data. (It was a new system, so autoconf and the build choked a couple of times - who is the autoco guru I can pass some more dependencies that have been missed to? Regards... Matthew On 10/21/08, Csaba Halász [EMAIL PROTECTED] wrote: On Tue, Oct 21, 2008 at 11:40 PM, Matthew Tippett [EMAIL PROTECTED] wrote: Hi, I am trying to determine if the CVS tips are broken relative to * x86_64 system, or if I have a bad build/installation. The build is from CVS tips of fg/source, fg/data and sg. The symptoms are 1) Flight data playback doesn't work (complains about no binary input) 2) No key commands 3) No menu Haven't tried #1, but the other two are fine here. Build as of 20hrs ago. -- Csaba/Jester - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Sent from my mobile device - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Add optional build dependency: libsvn
The package needed would be libsvn-dev or similar. This is unlikely to be installed as part of the installation of svn, however libsvn (the runtime library) will be. And the dev package is usually just a suffix. Regards... Matthew On 10/19/08, James Turner [EMAIL PROTECTED] wrote: On 19 Oct 2008, at 09:13, Alex Perry wrote: This patch changes terrasync so it links against the subversion library if you have it installed. It supports people who build binary releases for use by non-developers by removing the runtime external dependency on having command line svn or rsync available. Since the patch changes autoconf to detect libsvn, I'd appreciate it if people who release binaries could verify that the detection scripting works for their platform. Out of curiosity, does installing 'svn' mean I have libsvn installed automatically? Or does that depend on how my svn was built? Anyway, seems like a good change. 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Sent from my mobile device - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch for multiscreen mode with multiplayer
boards ran $30k to $60k each and required a specially trained sgi tech to install them. We paid $10k a year for our hardware maintenance contract.) Regards, Curt. On Wed, Oct 15, 2008 at 2:38 AM, Erwan MAS wrote: On Tue, Oct 14, 2008 at 04:01:55PM -0400, Matthew Tippett wrote: Hi, I don't know if Tim has documented the OSG Camera work that he has done. it removes most of the requirements for multiple instances and runs very well on modest hardware. Of course it depends on what you are doing for the mode of operation. The OSG Camera can work with 2 PC each with 2 screens ? -- / Erwan MAS /\ | mailto:[EMAIL PROTECTED] mailto:[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=100url=/ http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net mailto: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=100url=/ ___ 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch for multiscreen mode with multiplayer
First up, some arbitrary definitions. Multi-instance means multiple instances of flightgear running (on one machine or many). Multi-camera is using what Tim is describing here. I don't believe that multi-camera is exclusive of multi-instance. But for most users, a multi-camera setup will be cheaper (assuming you have the slots on your motherboard). Regards... Matthew On 10/15/08, Erwan MAS [EMAIL PROTECTED] wrote: On Wed, Oct 15, 2008 at 08:59:52AM -0500, Curtis Olson wrote: Hi Erwan, Tim's multiple view features are very powerful, and I'm amazed at how fast things run on medium and even lower range hardware. Tim's updates support two major modes of operation. But this require that all screens are attached to the same computer . Currently i work with 2 computerq so i have 3 screens with only 1 keyboard/mouse with SYNERGY ( see http://synergy2.sourceforge.net/ ) . Operating systems can be different . So the multi-instance mode for multiscreen is very simple to setup for me. My configuration is a laptop and a computer with 2 screens, and i dont need special hardware to play . I have a nvidia card with in xinerama mode . I think we must keep the another mode for multiscreen ( aka multi instance ) . -- / Erwan MAS /\ | mailto:[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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Sent from my mobile device - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch for multiscreen mode with multiplayer
Hi, I don't know if Tim has documented the OSG Camera work that he has done. it removes most of the requirements for multiple instances and runs very well on modest hardware. Of course it depends on what you are doing for the mode of operation. Regards, Matthew Original Message Subject: [Flightgear-devel] Patch for multiscreen mode with multiplayer From: Erwan MAS [EMAIL PROTECTED] To: flightgear-devel@lists.sourceforge.net Date: 14/10/08 04:16 PM Hello , I resubmit my patch . This reason of this patch is to have a better behavior of flightgear when you fly in multi screen configuration with multi-player mode . When you setup a multi-monitor configuration you have multi instances of flightgear ( see http://www.inkdrop.net/dave/multimon.pdf ) . On the second screen the slave instance , i don't see multiplayer . A small solution to solve the problem was to resend the packet coming from the multiplayer server to the other instance of flightgear . Who can push this patch in the cvs ? - 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=100url=/ ___ 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Towards a release - Re: Revision Log / Intended developments
Hi, Although I would still love to see a snapshot as soon as possible... It would be great to push visibly to a 1.9 release. You have a nice list formed below of items to be mentioned in release notes. But do we have a burn down list of items that need to be completed. In general, I see there being two fundamental approaches for the approach to the release. First, time based. Target a date and taint that date with a realistic set of hoped for features, what is ready is what is ready. What is not, slips to the next release. Second, feature based. Target a set of features, allowing it to be tainted with a reasonably realistic date. When the features are complete, the release is made. Which is preferred approach for those on the list? Can I suggest a wiki page to provide a focus for burning down issues prior to the release? Regards, Matthew Original Message Subject: [Flightgear-devel] Revision Log / Intended developments From: Durk Talsma [EMAIL PROTECTED] To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Date: 05/10/08 04:03 AM Hi All, As mentioned by Curt on previous occasions, one of the more labour intense parts of managing a release consists of the compilation of a comprehensible revision log that lists the major changes / improvements to FlightGear. I would appreciate it if somebody would give a hand in compiling such a list. Last year, we used the WIKI to host this log. Eventually this page ended up in the Developer portal, under the section Done. There is still a Changes since 0.9.10 page, and I guess we could add a new Changes since 1.0.0. Each revision log typically consists of the sections: New Features, Bugfixes, Regressions, New Aircraft, and Improved Aircraft Also, with the global target set for the release, I'm trying to get an impression of which projects are still under development, and which would be nice to have included in the release. Note that this overview implies by no means a deadline, or anything like it. I'd just like to know what is currently going on, so I can get an impression of which projects need some more time, and when we should set a feature freeze period. Based on my own reading of the developers list, I have the following list: Ralf Gerlich and Martin Spott: Complete scenery rebuild based on improved terragear algorithms / object database updates James Turner: Refactoring / unification of Airport and runway code and its ramifications for AI / ATC / Waypoint managment. Stuart Buchanan: 3D Clouds. Melchior: GUI improvements? Myself: Traffic Manager II. More aircraft improvements than possibile to mention. :-) Anything else? 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=100url=/ ___ 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery distribution
Can you define 'excellent server/network infrastructure'? Is SVN what they are offering, are they open to alternate architectures? Regards... Matthew On 10/6/08, Martin Spott [EMAIL PROTECTED] wrote: Folks, we have recieved an offer to use an excellent server/network infrastructure for the purpose of Scenery distribution. This would mean to provide read-only access to an SVN directory tree which contains the entire, unpacked Scenery. This offer even includes a modified 'terrasync', readily adapted to use this service !! which already has been tested with success at least on Linux, I hope to get feedback from someone checking its use on Windows. Objections ? 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Sent from my mobile device - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Call for aircraft nominations
This is sounding like a 'base' and a 'full' or 'extras' release packages. The base release should contain what is suggested here - a collection of best of breed aircraft for particular classes that people are interested in. The 'full' provides a collection of 'complete' aircraft, but may duplicate some classes (but with different aircraft). 'Extras' contains the 'random other collection' - like santa, development aircraft and so on. Likewise with scenery. The default location and whatever demo locations should ship with reasonably detailed scenery + other common locations. The 'full' brings in other common scenery, and 'extras' brings in everything else. (Integrating terragear as a thread within the main binary would make autoloading a simple checkbox - hint hint :). Regards... Matthew On 10/5/08, James Turner [EMAIL PROTECTED] wrote: On 5 Oct 2008, at 09:13, Durk Talsma wrote: So, with these criteria in mind, what would be your current top 10 of aircraft? Before the debate gets too details, there intention was (and still is, I think) to have at least one aircraft from the following categories: - the c172 - another light, GA single (eg, the cub, or maybe a more modern single-engine, like the piper archer) - a piston driven twin (senea, c310, etc) - a turboprop (eg, the b1900d, or Dh-6) - a WW2 era fighter (p51d, spitfire, one of the japanese fighters) - a heli - a transport class jet (737, A320, 777ER) - a glider - a modern fighter (f16, f14, SU-37) That's eight straight away, which are basically fixed, to 'prove' to new users that FG can handle all those classes of vehicle. Ten or twelve seems like a good limit - eg add a biz-jet (One of the citations being the obvious candidate) and then there's loads of 'cool' planes - the Osprey, Concorde, the WW1 era fighters, and so on. I'll leave it to Durk to pick a base package size based on the current aircraft selection, but people should be thinking along these lines when picking aircraft. The decision isn't how good the F18 / F14 is, it's whether it's better than then F16 / SU-37. Similarly, the 777ER verses the A320 or 737. And so on for each class - though in some it's easier, the Bo-105 is probably the clear winner for the heli, and the b1900d in the turboprop segment. There's also good arguments for including one 'show-off' aircraft in the base package - the the SR-71, Concorde, the 747-400 or A380, so people get some 'wow' factor without any install / download hassles. Particularly if someone wants to script a demo mode with Concorde taking off over the Golden Gate from KSFO or similar. Regards, 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Sent from my mobile device - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Call for aircraft nominations
Yes. Terrasync. With the intent being the terrasync thread can point to multiple repositories for data - low/medium/high resolution. Possibly using a bittorrent style sharing mechanism to share the bandwidth load :). Regards... Matthew On 10/5/08, Ralf Gerlich [EMAIL PROTECTED] wrote: Matthew Tippett wrote: Likewise with scenery. The default location and whatever demo locations should ship with reasonably detailed scenery + other common locations. The 'full' brings in other common scenery, and 'extras' brings in everything else. (Integrating terragear as a thread within the main binary would make autoloading a simple checkbox - hint hint :). I sincerely hope you didn't mean to earnestly suggest that last part. TerraGear is a beast of complex computational geometry algorithms and neither in a shape nor intended to be integrated into FlightGear. Maybe you meant terrasync? ;-) Cheers, Ralf - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Sent from my mobile device - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Call for aircraft nominations
It was meant more as a concept... Although with dedicated servers (effectively the same as the current rsync servers), there should always be a subset of servers providing all the data. Extra users seeding and sharing at runtime would just be gravy. Incomplete data would be just as likely as a bad download too. If enabled by default in a thread in fgfs, there would be many options for evaluation since feedback would be trivial to obtain. Regards... Matthew On 10/5/08, Jon Stockill [EMAIL PROTECTED] wrote: Matthew Tippett wrote: Yes. Terrasync. With the intent being the terrasync thread can point to multiple repositories for data - low/medium/high resolution. Possibly using a bittorrent style sharing mechanism to share the bandwidth load :). Bittorrent is ok for downloading huge chunks of scenery, but no good for terrasync where you can't be left waiting for that one last block, without which your entire tile is useless. Jon - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Sent from my mobile device - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] CVS Snapshot for publicity?
Hi, I would like to raise the question of a flightgear CVS snapshot being made and hosted. There was a video recently posted of a demonstration of (what I believe is) Tim Moore's OSG based camera system (8 displays connected to one PC) http://www.youtube.com/watch?v=brG3-yyvv9Q this was picked up by Phoronix.com http://www.phoronix.com/scan.php?page=news_itempx=NjczNQ Now Phoronix is wanting to do a bigger article on the multi-display support from ATI, which will include how to set up flightgear on many displays. Once that article is out of the way, Phoronix is also looking at enabling automated testing for flightgear based on the multi-display and data playback capability in Phoronix Test Suite. To achieve all this, Phoronix will require a declared CVS snapshot on flightgear.org to hook it all in together, although not a formal release, a snapshot tarball for both scenery and code will be better than some CVS point in August. In the past been working with Tim Moore, but Red Hat seems to be keeping him very busy. Is there anyone else on this list that would be willing to declare a snapshot and host it on flightgear.org? Regards, Matthew - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Prospects for a new release
As a new person to flightgear, but an OSS participant for the last decade and a half, and a development manager by trade I would strongly suggest the 1.9 stream numbering. The rationale for this is as follows. 1) Realistically there are bugs that exist, having a 1.8 or 1.9 is industry practice for saying 'we know we aren't to what we want for a major, but it adds value for us to get this out'. 2) Flightgear between 1.0 and now has gone from a part flightsim/part opengl development project to a part flightsim/part visualization toolkit. With OSG, most of the OpenGL is now gone, replaced with near pure visualitation toolkit. This considerably reduces the barriers for developers to start assisting since they can now go effectively shopping with OSG and then the 'coding' is bringing an OSG feature into flightgear.Actively pushing this should help flightgear gather OSG capable developers for flightgear 2.0 3) Actively pushing flightgear as a production user of OSG and OSG as the underpinning for flightgear should provide for useful synergy for allowing OSG core developers experiment with flightgear to see their ideas in actual use (vs small theoretical examples). Again the gap between 1.9 and 2.0 allows the experiments to occur. It does mean the flightgear people need to be open to experimentation by people who fundamentally don't necessarily show interest in flightgear itself. Just by 2 cents :) Regards... Matthew On 10/4/08, Stuart Buchanan [EMAIL PROTECTED] wrote: --- On Sat, 4/10/08, Melchior FRANZ wrote: * Durk Talsma -- Saturday 04 October 2008: Given that we have an OSG branch that has undergone significant development this year, and a PLIB branch, with little or no development, I would strongly urge that the main release would be OSG based. I agree. The PLIB branch was only kept alive for a short time after the 1.0 release, just for the case that we missed some really bad bugs and needed to make a bugfix release. Making another release from that would be rather pointless, and not help to convince people that fgfs is not dead. Rather the opposite. I think a release is a great idea. Thanks in advance for all the work you will be doing! I'll second Melchior's comments on PLIB vs. OSG - even with the known deficiencies, an OSG release would be by far the best. PLIB based maintenance release: 1.0.1 OSG based main release: 1.1.0 (or 1.2.0) I like the idea of an 1.9 release from the OSG branch. This makes clear that it's one step before a major release 2.0, and that there were fundamental changes (additions and also temporary losses). We could easily explain why clouds/shadows are missing there, and it might attract new developers who are interested and knowledgable in OSG. I think this numbering scheme makes sense. -Stuart - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Sent from my mobile device - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS Snapshot for publicity?
Original Message Subject: Re: [Flightgear-devel] CVS Snapshot for publicity? From: Curtis Olson [EMAIL PROTECTED] To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Date: 29/09/08 11:34 PM On Mon, Sep 29, 2008 at 8:33 PM, Matthew Tippett wrote: ... Hi Matthew, I made an unofficial snapshot a couple weeks ago that ended up on two ATC flight simulators (ATC is the company name, not the function) at a school on Long Island. It's not too hard to make a source snapshot if I don't worry too much about release notes, change logs, binary builds, etc. I've been wanting to move towards some sort of regular developer snapshots, but I've had too many things on my plate. The great things about regular snapshots is that you don't need to always do release notes. Just pull in the CVS changelog and call it done :). As long as the guides for dependencies are good, that is great for a snapshot. Where are these snapshots stored? I don't recall any links on them. Mind you, there are also clear benefits for a 1.8/1.9 formal release as well. :). ... BTW, really neat stuff with the 8 monitor demo! No problems, stay tuned for a 12 or 16 monitor demo over the next month or two :). (On one system too). If I had to nitpick, Please do, this is constructive criticism. I'd suggest that (at least from the video) it appeared that not every display was identical in size? Yes, that is correct. Getting 100% similar monitors isn't that easy the 12 display setup should make it a bit nicer. Also, with Tim's most recent CVS changes, it's possible to adjust the view parameters for each monitor to account for the gap between monitors (i.e. so it doesn't look like you sliced up an image into 8 pieces and then spread them apart.) (I am hoping that there is a Wiki or similar for camera setup :). A sample aircraft or test pattern or similar would be a great way to allow people to see what values are needed fine tune. And if I was getting really nitpicky, I suggest that it might be fun to go blasting up some valleys in the mountains east of seattle somewhere, although flying around SFO isn't a bad choice either ... perhaps some dusk/dawn flying would have been fun too ... (But I do realize there is only so much you can show in a couple minute demo.) The flight data was pre-recorded. Look at http://wiki.flightgear.org/index.php/Presentation_Recipe for more information. If someone is willing to pre-record a standard flight that would be shipped with flightgear data, that would be ideal. Record your favoured flight path - it looks like the external fdm data actually handles jumping around locations too, so choose where you want to go :). To really make flightgear accessible and engaging to the masses there are two *absolutely* critical items. 1) A pre-recorded demo that ships with flightgear that gives a guided tour of what is best with flightgear. This will require improved visuals over the flightpath. 2) Absolutely engaging eyecandy in the default startup location. I know there are some amazing visuals in other parts of the world, but when you start fgfs, you end up in KSFO, which is somewhat boring. If this means moving the initial location to a better location, IMHO fgfs would be better for it. No tweaks, no extra packs, just blow people away with what comes up on by default. If you have a look at celstia under Linux (http://www.shatters.net/celestia/), the startup mode is a guided tour of the solar system, allowing you to break out at any time and look around. This is *absolutely* great for people to go holy-cr*p, this is amazing, and then go and try doing that. Regards, Matthew - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Back-porting to the pre-OSG branch (was Re: Only to remember)
I would be pleased to get something formal released. A snapshot would mean publicity through Phoronix - to the Linux crowd, inclusion in the Phoronix Test Suite (for multi-display testing), and finally AMD would squeeze out a few videos of Tim Moore's great multi camera at least 12 heads (16 if I can get a 4 slot motherboard that works reliably). Speaking of which, another call out for multithreading... The GPU isn't the limiting factor in our tests, the CPU is. Even mid-low end systems have 2-4 cores these days, and with the multi-display demo we are continually capped by one CPU. Regards... Matthew On 10/3/08, Heiko Schulz [EMAIL PROTECTED] wrote: Hi, So, I'd much rather see a concerted effort to get CVS into a releasable state, and a schedule for some 'preview' or 'beta' releases, rather than working on back-ports. James I agree to nearly all what you said, but why not release an official 2.0-pre-version with OSG which shows to the world that we are still alive? Maybe as an advertisement to other developers? In the moment I see that the clouds and shadows are a one-man-project- so now wonder that it needs a long time until we will have these features back. I wonder if it really needs so much knowledge about OSG, and if other developers could help here? Regards HHS - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Sent from my mobile device - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multi-threading / CPU usage
Are there any short term targets that will show benefit? Regards, Matthew Original Message Subject: [Flightgear-devel] multi-threading / CPU usage From: James Turner [EMAIL PROTECTED] To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Date: 03/10/08 09:51 AM On 3 Oct 2008, at 13:48, Matthew Tippett wrote: Speaking of which, another call out for multithreading... The GPU isn't the limiting factor in our tests, the CPU is. Even mid-low end systems have 2-4 cores these days, and with the multi-display demo we are continually capped by one CPU. I have a long, long, long term plan to improve multi-threading support, by enforcing subsystems to *only* communicate via the property tree, which has light-weight locks thanks to some work by Mathias. With a dependency graph between subsystems (which I want to add for other reasons any way) it would then become possible to run any 'clean' subsystem on a pool of worker threads (maybe just one, maybe more). I'm sure there's some other locking that would be required for global state (eg, the AIManger objects), and of course there's awkward cases that will never be clean (especially instruments that touch the scene graph) but it still seems a worthwhile goal. It'd be worth identifying which subsystems are the big time sinks (FDM? AItraffic?) to prioritise this. Another thing that would work well is to proxy all nasal script invocations to a Nasal helper thread - again this assumes scripts basically interact with the sim via properties (which they already do) and that any system functions they call are thread safe - not very hard to do. As more and more functions get moved to nasal, this might become a very easy way to balance the CPU usage. 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] CVS Snapshot for publicity?
Hi, I would like to raise the question of a flightgear CVS snapshot being made and hosted. There was a video recently posted of a demonstration of (what I believe is) Tim Moore's OSG based camera system (8 displays connected to one PC) http://www.youtube.com/watch?v=brG3-yyvv9Q this was picked up by Phoronix.com http://www.phoronix.com/scan.php?page=news_itempx=NjczNQ Now Phoronix is wanting to do a bigger article on the multi-display support from ATI, which will include how to set up flightgear on many displays. Once that article is out of the way, Phoronix is also looking at enabling automated testing for flightgear based on the multi-display and data playback capability in Phoronix Test Suite. To achieve all this, Phoronix will require a declared CVS snapshot on flightgear.org to hook it all in together, although not a formal release, a snapshot tarball for both scenery and code will be better than some CVS point in August. In the past been working with Tim Moore, but Red Hat seems to be keeping him very busy. Is there anyone else on this list that would be willing to declare a snapshot and host it on flightgear.org? Regards, Matthew - 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=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
