Re: [Flightgear-devel] tree textures
--- Csaba Halász wrote: On Feb 9, 2008 12:29 PM, Vivian Meazza [EMAIL PROTECTED] wrote: I would be pleasantly surprised if condition worked in materials.xml Here you go :) As a side effect, we could get rid of the ugly code that makes Terrain.season out of Terrain at the expense of some more xml. I attached a patch against Syd's new materials.xml as well. This is fantastic - thank you very much! I have been thinking for a while that it would be good to have some way to have a finer granularity within materials.xml. For example: - Towns and villages in different countries/continents are quite different in terms of the buildings, and it would be good to reflect this. - Tropical forests are quite different from that of temperate climates - I did a virtual flight over Denali recently, and due to the limitations of the current terrain definitions, large parts of it were forest. I think that as well as a property defining the season, it would be good to have a set of properties based on the geographical region, for example: /sim/geography/continent (africa, europe...) /sim/geography/climate (tropical, temperate, arctic...) I'm sure we can think of some more. If we could define these regions based on lat/lon (in an XML file?), FG could set them, and they could be easily used within materials.xml. -Stuart ___ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Object avoidance
--- Melchior FRANZ wrote: * R. van Steenbergen -- Friday 15 February 2008: Melchior FRANZ wrote: ...you could abuse that by launching an invisible, lightweight, and very fast submodel, and check where and at which altitude it lands. Don't they call that 'radar' in real life? :) (The very fast, lightweight submodels being microwave photons in that case) Hehe, yes. Except that ours don't come back. And I'm not sure if they collide with static/random buildings. They hardly do with trees. Hmm ... cows? Photons colliding with cows - isn't that a microwave oven? TING! Burger anyone? ;) -Stuart ___ Support the World Aids Awareness campaign this month with Yahoo! For Good http://uk.promotions.yahoo.com/forgood/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Generic Blackout/Redout
Hi All, We currently have a number of aircraft which feature blackout and redout due to the G-force on the pilot. Blackout occurs when the pilot is subject to high positive G-loading, as the blood is drained from the head. Red-out occurs when the pilot is subject to high negative G-loading, as extra blood pools in the head. The effects can be mitigated by tensing the muscles of the legs (for blackout) or wearing a G-suit. I've just committed a generic, configurable version which means that all aircraft now have G-force blackout, and the aircraft-specific versions can now be retired. As G-force affects all pilots, it seems appropriate to have a single solution for everyone as part of the core simulator, rather than only specific aircraft. Notes: 1) There is a G-force Options dialog under the View menu, which allows the user to enabled/disable blackout and set the G-force at which blackout and red-out occur, and are complete (i.e. the screen is completely black/red). 2) Whether or not blackout is enabled is controlled by /sim/rendering/redout/enabled. This is a userarchive property. The intention is that the user will configure this. 3) The points at which blackout/redout start and are complete are configured by the following properties: /sim/rendering/redout/blackout-onset /sim/rendering/redout/blackout-complete /sim/rendering/redout/redout-onset /sim/rendering/redout/redout-complete These are not userarchive. The intention is that aircraft designers can configure these appropriately to take into account the resilience of the pilot. For example, the default values are probably appropriate for a civilian pilot, while a military pilot in a G-suit will have a much higher tolerance. 4) The blackout/redout only occur within in-cockpit views (the view/internal property), so have no effect on chase or tower views. 5) The properties and dialogs are under redout as this is the name .cxx file and that implements the blackout/redout, and also the property which is used to control the current blackout/redout itself. Yes, we could change it to blackout. 6) This is OSG only, so isn't applicable to the plib data branch. Comments are, as always, very welcome. -Stuart __ Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Generic Blackout/Redout
--- Stuart Buchanan wrote: I've just committed a generic, configurable version which means that all aircraft now have G-force blackout, and the aircraft-specific versions can now be retired. As G-force affects all pilots, it seems appropriate to have a single solution for everyone as part of the core simulator, rather than only specific aircraft. I've committed some changes to this, based on feedback from Melchior. The only change in function is that the property names have changed to the following: /sim/rendering/redout/parameters/blackout-onset-g /sim/rendering/redout/parameters/blackout-complete-g /sim/rendering/redout/parameters/redout-onset-g /sim/rendering/redout/parameters/redout-complete-g The other changes make it more efficient (by using listeners instead of reading properties every iteration) and smoother (by updating the blackout level every frame). -Stuart __ Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] tree problems ...
--- SydSandy wrote: I know the differences between tree species , LeeE ,thats not the problem ... if I set a certain tree texture for a terrain type ... for example , I have 2 meter high shrub trees for the ShrubCover/ShrubGrassCover/ScrubCover. When I fly over the area , it is covered by mixed forest... I few south and there are shrub cover trees on a DeciduousNeedleCover material patch. The ground texture changes accordingly , just not the tree textures ... and yet I see tree sizes change correctly at the material boundaries I hadn't reaaly noticed this effect until I started flying around and checking terrain using geod.info so didn't expect it to jump out at anyone else Sorry for the delay in replying, I've been away ski-touring all week, so haven't been on email. Though I've still to look at the code in detail, I'm almost certain that this will be a bug in my tree shader code. I suspect that the same tree texture strip is being used for all the trees on a tile/quad. Could you give me a starting lon/lat and a flightplan that shows the problem? -Stuart __ Sent from Yahoo! Mail. A Smarter Inbox. http://uk.docs.yahoo.com/nowyoucan.html - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] AI Aircraft Models
--- On Wed, 9/4/08, Melchior FRANZ wrote: We certainly don't want redundant texture duplicates in $FG_ROOT/AI/. Did you scale them down or do anything else that justifies this step? If not, then just refer to the original textures (converting those to PNG if you want). As I mentioned in my reply to Vivian, I don't want any dependency on the Aircraft tree, as the user may not have the full aircraft present on their system. One of my aims is that a user with just the base package will be able to see all the aircraft in MP sessions without having to download them. I haven't scaled any of the textures down, though the conversion from .rgb to .png reduced the size quite significantly. I will look at resizing them. -Stuart ___ Yahoo! For Good helps you make a difference http://uk.promotions.yahoo.com/forgood/ - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] AI Aircraft Models
--- On Wed, 9/4/08, Melchior FRANZ wrote: * Stuart Buchanan -- Wednesday 09 April 2008: As I mentioned in my reply to Vivian, I don't want any dependency on the Aircraft tree, You don't want that, fine. And *I* don't want a parallel structure of aircraft with megabytes of duplicated files. I could have worded that better as the following: I don't think there is any benefit to adding AI aircraft if they have a dependency on the Aircraft tree. So, please let's discuss that first, before anyone dumps more of that stuff into $FG_ROOT/AI/! Hence my original post - discussion is good. In my opinion, adding AI version of the aircraft I maintain was reasonable, they are fairly small anyway, and converting to png etc. makes them smaller. Do we really want MP support for all aircraft in the base package, at a cost of an extra 200 MB of data? Wrappers are fine (like Vivian described), but do we want a complete concorde.ac with all textures *again* in the AI/ dir? If someone wants the Concorde displayed, then s/he can install it, no? Yes, I strongly think that there would be a real benefit for everyone who uses the base package to be able to see all MP aircraft. As well as making the MP experience faster (which everyone would benefit from), I think it would make it richer for new users. Even though I have a fairly fast machine, MP flying around KSFO is still marginal. It is likely to get worse as the number and complexity of aircraft increase. Creating AI models (and also promoting a culture of creating AI models for all new aircraft) would go a long to helping this. In that context, another 50 - 100MB of data in the base package seems reasonable. I think it should be possible to create AI aircraft at less than, say, 500KB per aircraft, which would grow the base package by less than 100MB. For example, the Vulcan AI model is around 200KB. Some aircraft are going to be much easier to make AI versions of than others, and some may require the .ac file to be edited. Most of my aircraft are almost trivial in complexity. I'd prefer fgfs to show better information about which aircraft couldn't be shown because they aren't installed, and a better LOD concept (LOD in the aircraft dir, where it belongs). And if we really want the independence, then we should make sure that this is cheap. Textures should be scaled down a *lot*, the model should be drastically poly-reduced, the whole aircraft shouldn't take more than 250 kB (or something). And we don't need MP-versions of Ogel, wrightfligher and others. How about the following - Maximum size 250KB. - All textures converted to PNG and scaled to 1/4 size in both dimensions. Does that seem reasonable? -Stuart ___ Yahoo! For Good helps you make a difference http://uk.promotions.yahoo.com/forgood/ - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] AI Aircraft Models
--- On Wed, 9/4/08, Durk Talsma wrote: I do forsee that adding loads of AI aircraft could add to the size of the release version of the base package. That being the case, we could consider spawning off a separately downloadable, optional AI aircraft package (including not only aircraft, but also traffic files, etc etc). Without wanting to put words into his mouth, I assume that is Melchior's (and others) main concern, rather than the size of our CVS repository itself. Frankly, if we are worried about the size of the repository, we need to create a repository for new aircraft. But that is a different discussion... A separate AI download is a nice idea, but I think it has some issues itself: - It would increase the user workload, and realistically the support workload on here and the forums. I've found that user's rarely read our manual, wiki or FAQ before posting questions. - We (well, probably you Durk!) would have an extra package to manage during the release cycle. - We'd have to document installing it, which is quite a bit harder than you'd expect when dealing with MacOS and people who exclusively use the wizard. -Stuart ___ Yahoo! For Good helps you make a difference http://uk.promotions.yahoo.com/forgood/ - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] AI Aircraft Models
-- On Wed, 9/4/08, AJ MacLeod wrote: On Wednesday 09 April 2008 16:20:05 Stuart Buchanan wrote: How about the following - Maximum size 250KB. - All textures converted to PNG and scaled to 1/4 size in both dimensions. Does that seem reasonable? I think we have two slightly differing concepts of what the MP/AI aircraft are all about. In my view, they are a nice way of providing (at minimal effort to modellers) versions of each aircraft which are visually complete from external views while being very significantly quicker to load than their full counterparts (the vast majority of textures, animations and polys are generally found in the cockpits of most of our more complete models.) Well, this was my original idea behind creating them by chopping out the bits that weren't required. My assumption was that the cost of making these available to all users was sufficiently low to make it a no-brainer. That assumption appears to be false. I don't, however, see any harm in someone providing an optional MP aircraft pack download that provides what Stuart would like to achieve, for those who want it... That would suggest simply providing AI/Aircraft as a separate download. -Stuart ___ Yahoo! For Good helps you make a difference http://uk.promotions.yahoo.com/forgood/ - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] AI Aircraft Models
--- On Wed, 9/4/08, Vivian Meazza wrote: 1. A long time ago in the early days of MP the policy was agreed: If you don't have it you don't see it. No glider, no ufo, nothing. And AFAIK that's still the case. IF we want to depart from this long standing policy, then that's a slightly different debate. I think the v1.0 release has seen a step-change in the use of FG. There are a large number of new (often quite young) users who are generally inhabit the forums rather than the lists. They are tending to use MP all the time, as it is part of their expectations of the system (I'm guessing because they have a background in games like World of Warcraft). Given this, making all the aircraft easily and cheaply available of MP seems a no-brainer to me. IMO the argument is really about how large these aircraft should be, and whether they should be part of the release base-package or not. 4. We don't seriously think that OSG is fit for a release this side of Christmas do we? Should we really be using .png in anything other than osg only models such as the Buccaneer, and even then I think I removed all .png textures from the AI/MP version. (And now I'm going to have to :-)) Yes, I think OSG is going to be fit for release, and quite soon. In fact, setting a target for an OSG release sometime this summer might be a good way to encourage the bugs and rough edges to be smoothed out. -Stuart ___ Yahoo! For Good helps you make a difference http://uk.promotions.yahoo.com/forgood/ - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] AI Aircraft Models
--- On Wed, 9/4/08, Melchior FRANZ wrote: * Stuart Buchanan -- Wednesday 09 April 2008: --- On Wed, 9/4/08, Melchior FRANZ wrote: So, please let's discuss that first, before anyone dumps more of that stuff into $FG_ROOT/AI/! Hence my original post - discussion is good. Yes, discussion is good. But the original post was already a bit past the point where an RFC would have been in order. You had already started with copying textures and asked others to do the same. Time to take a break. Mea culpa. I screwed up and should have posted before committing. My apologies to all. This idea was a lot more contentious than I expected at the time... In that context, another 50 - 100MB of data in the base package seems reasonable. Sound like a rather low estimation to me. Especially considering that helijah adds 5 aircraft every week. :-) Well, I'm not sure I can keep up with that rate ;) How about the following - Maximum size 250KB. - All textures converted to PNG and scaled to 1/4 size in both dimensions. Does that seem reasonable? Maybe. I'd like others to comment on that. I never claimed that it's on me to decide. But I'd like to have such things discussed beforeI don't think that's likely in the near term. Also they are done. You probably know that committing a file means that it will be in CVS *forever*, even if you cvs rm it right after that. No I didn't know that, but thinking about it for 5 minutes should have made me realize that it was probably the case. Whatever we come up with,I don't think that's likely in the near term. Also it would be nice if the LOD handling could always load the full aircraft version if you are very close. Seeing a blurry box parked next to you isn't pretty either. I guess that's a possibility, but I'd prefer not to have a huge new model load just as I start flying formation with another aircraft... ;) -Stuart ___ Yahoo! For Good helps you make a difference http://uk.promotions.yahoo.com/forgood/ - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Generic Headshake/G-compression
Hi All, Enthused by a comment on the forum by snork (http://www.flightgear.org/forums/viewtopic.php?t=1333), I've been working on an extension to the generic blackout/redout script which attempts to simulate the feeling of compression due to g-forces, by moving the pilot viewpoint vertically depending on the apparent g-force. This is a simplified version of what vivian, Josh et al. created for the Buccaneer and other aircraft. Of course, the main advantage of this is that it is completely generic, and pretty lightweight too. The overhead ontop of the redout/blackout is minimal: one extra property read/write per frame, only when the feature is enabled and in cockpit view. A patch for this is available from http://www.nanjika.co.uk/flightgear/headshake.patch Comments are very welcome, but I'm particularly interested in peoples views on the following: 1) Obviously this duplicates some aircraft-specific code, and one can argue that this sort of feature is only important for high-energy jets, where it should be modelled in more detail than I have done. I've been playing with this code on the Stampe, A4-F and Pitts, and have felt that it has improved the feeling of realism, but then I wrote it ;) Do people feel it is worth providing a generic implementation, given that for most GA flying is at 2g or less, and this will move the pilot viewpoint 5cm! 2) Currently the redout and headshake enabling properties are userarchive, which (as I understand it) means that the user's preference will over-write any aircraft setting. Given that both these generic features duplicate existing aircraft-specific code, I think I should remove this flag, so aircraft designers can over-ride it. Any comments? 3) At the moment, this feature is limited to the y-offset of the pilot viewpoint. For non-military aircraft, the most significant g-forces will be felt in the y-axis (in the pilots frame of reference), as they cannot yaw fast enough to cause any in the x-axis, and they don't have enough power to cause any in the z-axis. If it is worth providing a generic feature, is it worth making it multi-dimensional? -Stuart __ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Generic Headshake/G-compression
--- On Sun, 20/4/08, Ron Jensen wrote: On Sun, 2008-04-20 at 12:55 -0700, Stuart Buchanan wrote: Hi All, Enthused by a comment on the forum by snork (http://www.flightgear.org/forums/viewtopic.php?t=1333), I've been working on an extension to the generic blackout/redout script which attempts to simulate the feeling of compression due to g-forces, by moving the pilot viewpoint vertically depending on the apparent g-force. This has now been checked in. 2) Currently the redout and headshake enabling properties are userarchive, which (as I understand it) means that the user's preference will over-write any aircraft setting. Given that both these generic features duplicate existing aircraft-specific code, I think I should remove this flag, so aircraft designers can over-ride it. Any comments? STRONGLY OPPOSE. User preference should absolutely outweigh the aircraft designer. While I might feel, as an aircraft designer, that a function adds a degree of realism, I can't and don't test on different hardware, monitor resolutions, multi-head setups, hardware simulator setups, etc. which head-shake may cause problems with. I personally find it annoying to have the panels jumping around during IFR flight. OK. I've left the enabling properties as userarchive. However, aircraft designers can _disable_ it by simply settings /sim/rendering/headshake/rate-m-g=0 I think that should satisfy both users and aircraft designers. -Stuart __ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Jon Stockill - please read this to protect your models database from copyright problems
--- On Thu, 1/5/08, Georg Vollnhals wrote: Jon Stockill - please read this to protect your models database from copyright problems On a related note, we're going to have to be careful about textures too - see http://www.flightgear.org/forums/viewtopic.php?t=1443 I'll make sure that the scenery FAQ and any appropriate wiki pages make licensing issues clear. -Stuart __ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Texture contribution
Hi All, The maintainer of a textures website has offered some of his textures to be GPL'd and contributed to the project: http://www.flightgear.org/forums/viewtopic.php?p=10163 On the assumption that we should take up his kind offer, who would like to be the point of contact? As anyone who has seen my attempts at aircraft texturing will attest, I'm certainly not an artist, and don't feel best placed to handle this. -Stuart __ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Texture contribution
--- On Thu, 8/5/08, Arnt Karlsen wrote: ..maybe he could join us here? ;o) I don't think he has any interest in FG - he was approached by another forum member who wanted to use his textures in a building. ..I believe he is wrong in his opinion of being unable to make a good living off his texture web site. And I too am happy to help convince him. And the best part is how he starts with a limited set of textures. He will be able to tell us how this impacts his web site business. ;o) I hope he can make a living from his texture website, and I think GPLing some textures is a good marketing tool. However, I can't see any commercial justification for GPLing all the textures, given that they are already fairly free for end-user use. In this case the textures themselves represent a very large part of his IP and business. In contrast, a lot of OSS businesses have professional services ontop of the GPL'd IP as the actual business, so the core software is not as important to them. Anyway, I am not familiar with his business, and it would be presumptious (if not rather rude) of me to comment further. I'm just very thankful he has offered as much as he has. On a more technical note - if we are offered a choice, it might be a good idea to discuss the sort of textures that would be particularly useful to the project. I've had a quick look through the site, and there aren't any that look particularly applicable as ground textures, but there are some nice elevation views of buildings which could be useful. -Stuart __ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Patch to perform airport searches case-insensitively
Hi All, Someone on the Forum (or was it here?) mentioned a problem where they couldn't use the Airport Search dialog easily because some airports in apt.dat are named in mixed case while some are in all-caps. Rather than attempt to fix apt.dat (I'm not completely mad ;) ), I've created a small patch to our airport search function so that this search is done case-insensitively. I've done some minimal testing, and it at least appears to be functionally correct. However: a) As I'm sure many people are already aware, I'm not a very good C programmer, so there may be a better way to do this that I'm missing b) This uses the strcasestr() function, which is part of the GNU C library in string.h. What is the best way to check that such a function is available on all our platforms? -Stuart Index: AirportList.cxx === RCS file: /var/cvs/FlightGear-0.9/source/src/GUI/AirportList.cxx,v retrieving revision 1.18 diff -u -p -r1.18 AirportList.cxx --- AirportList.cxx 11 Mar 2008 15:58:57 - 1.18 +++ AirportList.cxx 31 May 2008 21:12:34 - @@ -30,7 +30,8 @@ AirportList::create_list () const FGAirport *apt = _airports-getAirport(i); STD::string entry(apt-getName() +( + apt-getId() + ')'); -if (!_filter.empty() entry.find(_filter) == STD::string::npos) +// Perform filter check case-insensitively +if (!_filter.empty() (strcasestr(entry.c_str(), _filter.c_str()) == NULL)) continue; content[n] = new char[entry.size() + 1]; __ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch to perform airport searches case-insensitively
--- On Sun, 1/6/08, Frederic Bouvier wrote: I confirm there in no strcasestr or equivalent in MS runtime. The patch below should be portable, although more convoluted. From reading the patch, I don't think this does quite what we want either. My reading is that this ensures that the identifier of the airport is in upper case. However, thanks for pointing out another approach to the problem. What we really want is to ensure that any search is completely case-insensitive. For example, apt.dat contains the following lines: 1 400 1 1 KLVK LIVERMORE MUNI 1 425 0 1 4AK2 Livengood Camp 13982 0 0 LIVD Dobbiaco Currently, searching for LIV returns the first and last lines, while searching for Livermore returns nothing, despite being what most people would search for. I think a use searching for liv would expect to see all the results above, and more. One issue that is worth discussion is that if we make the search completely case-insensitive, we obviously increase the number of results returned. In the example above, searching for liv would return a total of 54 results. A much less unique string, such as san would return over 400. Note that this assumes that the user has the entire world scenery installed, which is pretty unlikely. Nevertheless, I think these are acceptable numbers for a 3 character string. The user can easily perform a more specific search on receiving a large number of results. I will continue looking at this, though if anyone else would like to jump in with suggestions, that would be very welcome. -Stuart __ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch to perform airport searches case-insensitively
--- On Mon, 2/6/08, Melchior FRANZ wrote: * Stuart Buchanan -- Monday 02 June 2008: Nevertheless, I think these are acceptable numbers for a 3 character string. The user can easily perform a more specific search on receiving a large number of results. As I told on IRC already, the current case-sensitive behavior wasn't an accident or laziness. I must have missed that. I have not been paying enough attention to the IRC channel when logged on recently. My apologies. BTW: that ICAO codes are output in parentheses is also not just a cosmetic issue: this was done to allow searching for all French airports with (LF, for (almost) all Austrian military airports with (LOX etc. Thanks for pointing that out. I will ensure that this behaviour is unaffected by any changes. -Stuart __ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch to perform airport searches case-insensitively
--- On Mon, 2/6/08, Stuart Buchanan wrote:
I will continue looking at this, though if anyone else
would like to jump in with suggestions, that would be very
welcome.
... and here's the patch, based on Fred's original patch.
Assuming it passes muster, could someone review and commit please?
-Stuart
Index: AirportList.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/GUI/AirportList.cxx,v
retrieving revision 1.18
diff -u -p -r1.18 AirportList.cxx
--- AirportList.cxx 11 Mar 2008 15:58:57 - 1.18
+++ AirportList.cxx 2 Jun 2008 21:05:01 -
@@ -1,4 +1,4 @@
-
+#include locale
#include Main/globals.hxx
#include Airports/simple.hxx
@@ -22,6 +22,7 @@ AirportList::~AirportList ()
void
AirportList::create_list ()
{
+const std::ctypechar ct = std::use_facetstd::ctypechar
(std::locale() );
int num_apt = _airports-size();
char **content = new char *[num_apt + 1];
@@ -30,8 +31,13 @@ AirportList::create_list ()
const FGAirport *apt = _airports-getAirport(i);
STD::string entry(apt-getName() +( + apt-getId() + ')');
-if (!_filter.empty() entry.find(_filter) == STD::string::npos)
+if (!_filter.empty()) {
+ // Perform filter check case-insensitively
+ std::string cientry(apt-getName() +( + apt-getId() + ')');
+ ct.toupper( (char *) cientry.data(), (char *) cientry.data() +
cientry.size() );
+ if (cientry.find(_filter) == std::string::npos)
continue;
+}
content[n] = new char[entry.size() + 1];
strcpy(content[n], entry.c_str());
@@ -60,7 +66,12 @@ AirportList::destroy_list ()
void
AirportList::setValue (const char *s)
{
-STD::string filter(s);
+std::string filter(s);
+const std::ctypechar ct = std::use_facetstd::ctypechar
(std::locale() );
+
+// convert filter to upper-case for case-insensitive matching
+ct.toupper( (char *) filter.data(), (char *) filter.data() +
_filter.size() );
+
if (filter != _filter) {
_filter = filter;
create_list();
Index: AirportList.hxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/GUI/AirportList.hxx,v
retrieving revision 1.7
diff -u -p -r1.7 AirportList.hxx
--- AirportList.hxx 11 Mar 2008 15:58:57 - 1.7
+++ AirportList.hxx 2 Jun 2008 21:05:01 -
@@ -9,10 +9,6 @@
#include plib/puAux.h
#include dialog.hxx
-
-
-SG_USING_STD(string);
-
class FGAirportList;
class AirportList : public puaList, public GUI_ID
@@ -28,7 +24,7 @@ class AirportList : public puaList, publ
private:
FGAirportList * _airports;
char ** _content;
-STD::string _filter;
+std::string _filter;
};
#endif // __AIRPORTLIST_HXX
__
Sent from Yahoo! Mail.
A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Scotland Scenery
Hi All, For my own amusement, I generated some scenery for Scotland using the GSHHS coastline and OpenStreetMap for roads. Scotland greatly benefits from using GSHHS coastline, as the VMAP0 data doesn't include many of the small islands on the west coast. There are sufficiently few roads that the OSM dataset works quite well also - you can even see some roundabouts! For those who might be interested in doing some flying in Scotland, it is available here: http://flightgear.mxchange.org/stuart/scotland.tar.gz (35MB) Many thanks to Roland Haeder for hosting it. Note that the scenery package is only the Terrain part, and doesn't include any Objects. It should be uncompressed into the Terrain sub-directory of your $FG_SCENERY (e.g. data/Scenery). As always, objects should be downloaded from http://scenemodels.flightgear.org/. For those unfamiliar with Scotland, there is a small suggested flight around my home city of Edinburgh here: As suggested flight for those who have downloaded both the scenery and objects is this: http://wiki.flightgear.org/flightgear_wiki/index.php?title=Suggested_Flights#Scotland_-_Edinburgh_to_Dundee I'd also highly recommend taking off from Oban and As suggested flight for those who have downloaded both the scenery and objects is this: flying in the mountains in a fast military jet. After all, that's what the RAF do! The fact that I was able to generate scenery using TerraGear for amusement is a testament to the effort that the Custom Scenery team (http://www.custom-scenery.org/) have made to make TerraGear easier to use. Many thanks to Martin and Ralf for their work. -Stuart __ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear OSG
--- On Wed, 23/7/08, Vivian Meazza wrote: 3d clouds have not been ported to osg. At the current rate of progress - sometime in the next decade :-). Progress is marginally better than that - I've ported the code and have even got it to compile. I'm now at the stage of crashes-on-startup which will entertain me for some time while I remember how to write C++ code properly :) I expect to progress through the random-black-squares-underneath-the-terrain, thirty-minutes-to-start and one-frame-per-second phases over the next month or so. At this point, Tim will helpfully point out how I can make things much more efficient, and make the squares of texture actually look like clouds. Then finally we'll have 3-D clouds, and everyone will wonder what the fuss was about in the first place. So, I wouldn't stay up late waiting for CVS commit messages, but equally I don't think things are quite as bad as they might seem. Finally, if anyone wants to help out, OSG isn't all that scary ... it is certainly easier to write for than plib! -Stuart __ Not happy with your email address?. Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html - 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] new Cockpit View Options dialog
--- On Sun, 27/7/08, Ron Jensen wrote: http://cvs.flightgear.org/viewvc/data/gui/menubar.xml?view=loghideattic=1 Log of /data/gui/menubar.xml Revision 1.80 - Wed Jun 11 21:20:43 2008 UTC (6 weeks, 3 days ago) by stuart Branch: MAIN Changes since 1.79: +2 -15 lines Collate Dynamic Cockpit view toggle with blackout and G-compression toggles into a new Cockpit View Options dialog. I can't find the cockpit view dialog box anywhere... That'll be because I forgot to commit the changes to the gui/dialogs/ directory. I've now committed them. Apologies for the inconvenience. -Stuart __ Not happy with your email address?. Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html - 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] 3D clouds - progress report·
Hi All, Just to keep everyone up to date on where I am with porting 3D clouds to FG OSG: http://www.nanjika.co.uk/flightgear/clouds.jpg Obviously there is still a lot of work to be done before they are complete, but progress is being made. I'm hoping that once I've completed the OSG part of the work I can get my changes checked in and other people will be able to enhance it further for things like weather radar. -Stuart __ Not happy with your email address?. Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html - 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 - progress report·
--- On Sat, 9/8/08, John Wojnaroski wrote: just 2 more cts. if you're porting to OSG why not consider Mark Harris' cloud code? far superior in texture, appearance, extendibility, transparency, lighting, etc, etc,might require a tad more work but IMHO the results are worth the effort JW I did consider it, but given the problems I've had simply trying to port the existing code, I felt it was too much of a challenge for the moment. -Stuart __ Not happy with your email address?. Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html - 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] black out behavior
--- On Sat, 16/8/08, gerard robin wrote: Coming back to the Erik, Alexis remark and my crazy first answer. Won't it be possible, to include in the Cockpit view parameters the additional parameters delay which gives the delay for 5g blackout and 9 g blackout ? All the code calculating the blackout is in Nasal/redout.nas. Adding a delay should be pretty easy. Please go ahead. and why not, if we want or not want, to have the Hud visible or not during blackout/redout ? That's probably a side-effect of where the redout is applied in the scenegraph. I'll take a look once I've finished 3D clouds. -Stuart Send instant messages to your online friends http://uk.messenger.yahoo.com - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] 3D Clouds - Update on (lack of) progress
Hi All, I was hoping that I'd be able to provide a positive update on my work on 3-D clouds this weekend. Unfortunately, I've hit what appears to be an OSG issue that is beyond my knowledge to solve. The problem I've hit relates to Impostors and Billboards. Impostors are used to reduce the impact of creating large billboarded clouds. The combination of Impostors and Billboards appears to hit a resource limit on my graphics card (even though it is a NVidia 7600GS with 512MB of memory) and produces large numbers of X11 errors: Got an X11ErrorHandling call display=0x9a63a70 event=0xbfea0944 BadAlloc (insufficient resources for operation) Major opcode: 80 Minor opcode: 1b Error code: b Request serial: 14c8 Current serial: 14c9 ResourceID: 1a3 (Often I get a Major opcode of 128 rather than 80) I don't think this is (just) my bad coding, as I've repro'd this in the example osgimpostor application by replacing line 159 of examples/osgimpostor/osgimposter.cpp with the following and rotating the camera for a minute or so: //osg::Geode * geode = new osg::Geode(); osg::Billboard * geode = new osg::Billboard(); geode-setMode(osg::Billboard::POINT_ROT_EYE); geode-setNormal(osg::Vec3(0.0f,-1.0f,0.0f)); Due to other commitments I don't expect to have sufficient time in next 6-12 months to be able to make any more progress on this, so I've uploaded my current patch to http://www.nanjika.co.uk/flightgear/clouds.tar.gz. There is a README file describing the patch within the tarball. In addition to the major Impostor issue, there are a number of other bugs that I'm aware of (and probably many more I haven't discovered yet!): 1) On start-up 3-D clouds aren't be visible - you need to manually select a weather scenario to display them. 2) Currently 3-D clouds are always used if 3D clouds are enabled. The type of cloud used should depend on the cloud cover as well as the user's preference. 3) The cloud tiling code is bugged. Specifically, if you travel far enough in one direction, the clouds start getting lower. This is fairly minor - you'll get a METAR update before you hit this in most cases. 4) The clouds have no effect other than sprite display - visibility doesn't drop when you enter them, they don't appear on radar. 5) Billboards should be probably be replaced with a custom transform that stops billboarding when the camera gets close to the cloud and instead modifies the alpha value so the cloud disappears as the camera intersects it. If someone with some OSG knowledge and sufficient time on their hands would like to pick it up, I'd be very grateful. I realize that this will be quite disappointing, especially given the rapid progress in OSG random objects and trees. Sadly, 3D clouds have turned out to be a lot harder to re-implement than I had expected. -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
Re: [Flightgear-devel] updrafts...
--- On Thu, 25/9/08, Syd wrote: I 've been pondering an idea of adding updraft/downdrafts to the environment, probably as a part of turbulence , so it can be enabled/disabled... My idea is to calculate wind-speed-from -down , by checking wind speed , direction , and the normal of the scenery triangle directly beneath the aircraft , sampling every second or so.Also with a scenery material and time of day check for updrafts over flat country . Ive tried to find a starting point in the code , but get more discouraged as I get lost in it. Hi Syd, I tried doing this a couple of years ago. As I recall, I was able to get the normal informaton from the scenery triangle fairly easily, and calculate the up/down draft. The problem came when I tried to have the affect the aircraft. Unfortunately I can't remember where I inserted the normal calculation code. Sorry I can't be of more help - but at least you know that part of your solution is possible ;) -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
Re: [Flightgear-devel] 3D Clouds - Update on (lack of) progress
(Resend - my previous reply got lost in the ether) --- On Mon, 22/9/08, Csaba Halász wrote: Patch is broken in multiple places (missing line breaks, parts of lines) Sorry you are having problems. I did a comparison between the results of a straight cvs diff and what is in my patch, and they match (apart from date changes, and ignoring some other changes I've been making and removed from the .diff file). I've also checked that I've not got any sticky tags set, so I'm at a loss as to what the problem can be. Any help would be appreciated. For reference, my .cvsrc file looks like this: cvs -z3 -q diff -up update -dP checkout -P rdiff -u -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
Re: [Flightgear-devel] 3D Clouds - Update on (lack of) progress
--- On Tue, 30/9/08, Csaba Halász wrote: In flightgear.diff, however, the hunk at line 36 concerning environment_mgr.hxx doesn't have any modifications even though the line count says a line should have been added: @@ -58,6 +58,7 @@ public: virtual void bind (); virtual void unbind (); virtual void update (double dt); /** * Get the environment information for the plane's current position. That is my fault for not removing some of my other changes properly - sorry for wasting your time. Removing this hunk makes the patch apply. It does crash at runtime, like you described, just with different numbers. So I guess that means it's okay :) Yes - if you ever want some patches that crash at runtime, just ask. I'm an expert ;) -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
Re: [Flightgear-devel] Prospects for a new release
--- 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
Re: [Flightgear-devel] 3D Clouds - Update on (lack of) progress
--- On Mon, 22/9/08, Csaba Halász wrote: Patch is broken in multiple places (missing line breaks, parts of lines) Sorry you are having problems. I did a comparison between the results of a straight cvs diff and what is in my patch, and they match (apart from date changes, and ignoring some other changes I've been making and removed from the .diff file). I've also checked that I've not got any sticky tags set, so I'm at a loss as to what the problem can be. Any help would be appreciated. For reference, my .cvsrc file looks like this: cvs -z3 -q diff -up update -dP checkout -P rdiff -u -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
Re: [Flightgear-devel] Back-porting to the pre-OSG branch (was Re: Only to remember)
--- On Fri, 3/10/08, James Turner wrote: On 3 Oct 2008, at 14:01, Tim Moore wrote: Stuart has run into a bug in OSG with respect to Imposters, which manage the cached rendering of the individual cloud sprites. It's unclear if this ever worked well in OSG. Unfortunately I haven't had the chance to really look at the problem. Yeah, his comments about crashes in a (modified) osgimpostor example make me very nervous. I am going to look at the code anyway, and test the osgimpostor issue locally (on Mac) to see if it behaves any differently from GLX. James - if you could take a look, that would be great. It is entirely possible that I've completely missed something obvious (say, defining the Impostor texture size) and this is user error. In the meantime, I may spend a little time looking at implementing a shader approach. That worked wonders for the tree performance, so it might work for clouds too. -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
[Flightgear-devel] 3D Clouds - progress report
Hi All, As I mentioned in my mail yesterday, I'm taking another look at 3D clouds. Rather than using Impostors, I instead looked at what I could do by using GPU shaders - basically offloading as much processing onto the graphics card as possible. This worked very well for the random-forests, which is in some ways a similar problem - needing to generate huge numbers of very similar pieces of simple geometry. Here's a current screenshot showing my progress: http://www.nanjika.co.uk/flightgear/clouds.jpg So far, I haven't noticed any effect on performance at all. There are still quite a few bugs to be ironed out, but I think I will be finished by Christmas. -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
Re: [Flightgear-devel] Call for aircraft nominations
Heiko Schulz wrote: Martin wrote: Durk Talsma wrote: So, with these criteria in mind, what would be your current top 10 of aircraft? I'd be very happy to see Heiko's overhauled C172 model included in the release. The outer hull is waaay better than the old one, yet the inners still need a little bit more touch, Martin. Very thanks for that. Not today, but till middle of this week, I should be ready with the interior and the new, really 3d-panel. That is great news. I look forward to trying it out! If you are doing all that work, it might be worth de-coupling the c172p from all the other c172 Aircraft in CVS (c172, c172r), so it is self-contained and we only have to include a single directory. -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
Re: [Flightgear-devel] Multiplayer Chat Frequencies?
Csaba/Jester wrote: On Mon, Oct 6, 2008 at 5:51 PM, Michael Smith wrote: Is it possible in Flightgear to chat on mutliplayer though frequencies? Gijs and Natovr found this line in preferences.xml under the mutliplay section: type=string11850 but they changed the line and they still could see others messages. Is this suppost to work or is it something there for a futute feature or what? It doesn't check for frequency match AFAICT, but seems to be pretty easy to add to multiplayer.nas. Might be advisable to change default comm frequency to some magic number meaning all frequencies. Not realistic, I know. So maybe GUARD? And display a simulated ATC warning about that, directing pilots to switch to a proper frequency. When I originally wrote the MP chat, I had quite a lot of difficulty doing the frequency matching between the sender and receiver, possibly because I was doing a float comparison, or because the property is transfered as a float, or because the radio frequency was a float. I'm sure it would be pretty easy to sort out, but I never returned to it. If anyone wants to take a look, they are more than welcome. -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
Re: [Flightgear-devel] Random trees
Gérard wrote: Hello, Is it only me ? or is there a funny behaviour with the random objects ? I have found trees into the stadium :) http://pagesperso-orange.fr/GRTux/RandomTreesAndStadium.jpg No, it isn't just you :) The random objects, including trees, are placed randomly based on the terrain type of the scenery, as defined in materials.xml. IIRC there is no attempt to stop multiple objects being placed at the same location - just the random function - and each object type is considered independantly. Objects from the scenery objects databased are placed as defined in the .stg/.btg files. Again, there is no attempt by the random object code to avoid placing random objects at the same location. In general this isn't a problem - we don't use object densities high enough to see collisions regularly, and usually a larger object will completely obscure a smaller one. If we decide to increase the density of random objects significantly so that collisions become a problem, we'll probably need to change to a different scheme, particularly for towns and cities. One possibility is to use a bitmap to determine possible object locations. This can then be aligned with the texture, so our buildings align with the streets, trees appear on the edges of fields, cows in the middle etc. However, I have enough work on my plate before the 1.9 release to start thinking about that just now! -Stuart Send instant messages to your online friends http://uk.messenger.yahoo.com - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] 3D Clouds - patch and progress report
Hi All, After a lot of effort, and help from Tim, I've finally got some 3D shader-based clouds that work acceptably: http://www.nanjika.co.uk/flightgear/clouds.jpg A patch is available from here: http:/www.nanjika.co.uk/flightgear/clouds.tar.gz I've put quite a bit of effort into making the clouds as configurable as possible. The cloudlayers.xml file should allow any cloud-artists to create much prettier clouds than I have managed. There are quite a few bugs to be ironed out:- 1) The cloud grid should shift when the camera moves out of range, to simulate and infinite set of clouds. This doesn't work very well ATM. 2) Currently the only well-defined clouds are cu's (used in the Fair Weather scenario). Better clouds need to be defined for all the other types. This should be possible with some new textures and editing of cloudlayer.xml 3) The alpha-blending isn't working properly 4) Rolling the camera while pointing vertically down on the cloud causes rotation of the texture. 5) The clouds are bit too transparent at medium distances. Nevertheless, I think it would be worth committing the code with these bugs present, if only so other people can have a look and comment. :) Thanks to Tim and also Heiko who provided some nice cloud textures. -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
Re: [Flightgear-devel] 3D Clouds - patch and progress report
LeeE wrote: On Saturday 25 October 2008, Stuart Buchanan wrote: Hi All, After a lot of effort, and help from Tim, I've finally got some 3D shader-based clouds that work acceptably: http://www.nanjika.co.uk/flightgear/clouds.jpg A patch is available from here: http:/www.nanjika.co.uk/flightgear/clouds.tar.gz I've put quite a bit of effort into making the clouds as configurable as possible. The cloudlayers.xml file should allow any cloud-artists to create much prettier clouds than I have managed. There are quite a few bugs to be ironed out:- 3) The alpha-blending isn't working properly This looks like a z-ordering issue. Is z-ordering used in the cloud routines? It is, but I'm not sure it is working on the level of individual sprites. The clouds are in the correct rendering bin (I think), but because of the use of shaders we currently just render them in an arbitary order within each cloud. I wonder if the problem is the CouldShaderGeometry::drawImplementation(). Does that seem likely? -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
Re: [Flightgear-devel] 3D Clouds - patch and progress report
George wrote: 1. I started FG with --enable-real-weather-fetch, then 2. enabled 3-D-clouds in the Rendering Options submenu - and did not see anything like you. Until I 3. enabled Environment = Weather scenerio from none to METAR. Does also work if I enable Thunderstorm or fair weather. As I don't know how Stuart intended it to work I only know that step 3 is absolute necessary. Initially I thought this was because we didn't have the appropriate clouds defined in cloudlayers.xml, but looking again that is not the case. I will investigate. -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
Re: [Flightgear-devel] Flightgear contest
James Sleeman wrote: On Sat, 2008-10-25 at 23:55 -0400, Ampere K. wrote: On October 24, 2008 12:38:46 pm Curtis Olson wrote: 1. Do we like the idea of a scavenger hunt type contest? If so, what types ... If you want a scavenger hunt, then this is one idea. Through an add-on package, the company's logos can be placed in a few places on the scenery, or ... (free as in freedom). This is a legal aspect that will have to be worked Forgive me if I'm wrong, but wouldn't the main flaw in a scavenger hunt be that it would be fairly easy for somebody to dig through the scenery definition to find what they are looking for? If someone is prepared to learn enough about the scenery definitions to do that, then I think we've achieved our own goal of getting people involved :) The target here is people who haven't used FG before downloading v1.9 and having a play. If we put the advertisement on a relatively generic mode (say, the sign on top of the FBO), I'm sure Melchior can come up with some appropriately obfuscated Nasal code to make it very unlikely anyone will be able to work it out which FBO it is without visiting them all :) -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
Re: [Flightgear-devel] 3D Clouds - patch and progress report
Fred wrote: I missed the Weather scenario thing. But when enabling Fair weather I got : VERTEX glCompileShader FAILED VERTEX Shader infolog: (1) : error C0201: unsupported version 120 glLinkProgram FAILED Program infolog: Vertex info --- (1) : error C0201: unsupported version 120 on the console. Luckily, a driver update fixed the problem. Now committing ... Thanks for committing this. I may be able to change the shader to get around the unsupported version 120, if lots of people are seeing it. The only GLSL v120 function I'm using is a sub-matrix that I can derive in other ways. I'll update the rendering dialog to remove the now redundant options. -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
Re: [Flightgear-devel] 3D Clouds - patch and progress report
Ron Jensen wrote: I could never see the clouds with --enable-real-weather-fetch set There's an interaction between the real weather fetch code and the 3D cloud that I'm still working out. I think the root problem is that the 3D clouds are bolted onto the side of the 2D ones, and don't always get updated in sync. Until I 3. enabled Environment = Weather scenerio from none to METAR. Does also work if I enable Thunderstorm or fair weather. As I don't know how Stuart intended it to work I only know that step 3 is absolute necessary. Once I perform step 3 (without --enable-real-weather-fetch set) I see an extreme drop in frame rate, from around 70 fps to under 20 fps. That's bad. What happens if you disable the 3D clouds after this point? Also, I started at KSFO and flew the UFO to Ogden, UT. (Lat 41.1, Long -111.1) somewhere along the trip, the 3d clouds disappeared, although frame rates stayed very low. That's one of the bugs. The 3D layer is repeated in a 3x3 grid, and there is code to designed to handle when you move out of the middle layer, shifting the grid across. -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
Re: [Flightgear-devel] 3D Clouds - patch and progress report
Martin wrote: 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. I think it's a bug, rather than confusing :) 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. Me too ;) -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
Re: [Flightgear-devel] 3d clouds
Roman Grigoriev wrote: I try to dig clouds problem and come across to this situation Clouds particles are improperly sorted from back to front So DepthRenderBin doesn’t sort cloud particles Here is to screen shots First I made by manual placing clouds particles so 1st particle is near to viewer and 10th is far Here we have incorrect.jpg but when I placed 1 particle far from viewer and 10th near you see correct picture correct.jpg Maybe if we are using shaders and osg::Drawable depthrenderbin sorting in osg doesn't work? And we have to do sorting manually? I have come to the same conclusion. The depthrenderbin sorting doesn't work in this case because the draw order of the sprites is defined by the CloudShaderGeometry itself. The solution as you have pointed out is to do the sorting manually before rendering. Unfortunately this needs to happen every frame (in CloudShaderGeometry::drawImplementation) The sort needs to be on the z axis of the view fustrum, which can be derived by passing the sprite positions through the Camera ViewMatrix. I'm working on code to do all this, but don't expect to have code available until sometime next week. If anyone wants to look at it before then, they are very welcome! -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
[Flightgear-devel] Improved 3D Clouds patch
Hi All, I've put together an improved 3D clouds patch, available from here: http://www.nanjika.co.uk/flightgear/clouds2.tar.gz It fixes the following issues (to a greater or lesser extent): 1) Performance. Quad trees used to improve culling, and the sprites are placed on the surface of a sphere rather than randomly throughout the cloud, requiring fewer textures. This saves about 5-10fps on my machine. 2) Disabled 3D clouds have no performance impact. Previously they were still in the scenegraph. Now they are removed. 3) Clouds are now loaded on start-up, and don't require the scenario to be changed, they also work with METAR. 4) The cloud field is shifted as you travel. There's a small bug in that the clouds jump as you reach the edge of the field. 5) Iterative sorting of sprites. This doesn't appear to solve the alpha blending problem completely, but may help a bit. Could someone please check it in? On a related note, it would be great if people could create cloud textures. The cl_cu.png texture appears to work quite well, but the cl_st.png shows very bad alpha blending. If someone could take the time to improve it, that would be great. Feedback is very welcome, particularly if you are seeing performance problems, or if the shaders don't work on your graphics card. -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
Re: [Flightgear-devel] Improved 3D Clouds patch
Tatsuhiro Nishioka wrote: By the way, I found a very interesting thing that the clouds always face to the aircraft. I placed ufo in the middle of clouds and made a spin by pressing left cursor. Then all the clouds were turning toward me, changing their order. I don't complain about this. it's rather cute to see these are facing me and say Hi! :-) Unfortunately the billboarding scheme isn't perfect. Effectively the texture is rotated so that it is at right angles to the viewing direction, with the bottom of the texture pointing down in the world-coordinate system. This works pretty well most of the time, but if your view direction is close to vertical, and you rotate the viewpoint, it is very obvious that the textures rotate with you. The easiest way to see this is to do an aileron roll in a vertical dive. -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
Re: [Flightgear-devel] Improved 3D Clouds patch
Heiko Schulz wrote: For now I which a bit more documentation about making the cloudshapes. I did understand that there are layers with Boxes with a set of clouds. But I have problems with these coordinates: box x3200/x y0/y z2400/z typest-large/type /box and grid sizes. I've checked in a new data/Docs/README.3DClouds, which should explain how the cloudlayers.xml file works. Please let me know if any of it is unclear. Thanks very much for all the feedback and help everyone has provided in the past week. I've been humbled by the help and encouragement everyone has shown, and the 3D clouds have improved greatly due to this. A superb example of FG community development at its best! Best regards to all, -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
Re: [Flightgear-devel] Improved 3D Clouds patch
Gerard Robin wrote: I do like that new version , i hope that the next one without that ordering problem will be perfect. It appears that Manuel has solved the ordering bug. http://pagesperso-orange.fr/GRTux/3DClouds-img6.jpg with that screenshot we may identify where the problem is: -no clouds layer behind it is very good ( bottom part of the sky ) - with clouds layers behind ( upper part of the sky ) we get that ugly blue color I think this might be something to do with the draw order relative to the cloud layers. I'm sure Tim will know :) -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
Re: [Flightgear-devel] Improved 3D Clouds patch
Manuel Massing wrote: Attached is a small fix for the sorting in CloudShaderGeometry.cxx. I think the sorting problem stems from the osg idiosyncracy to store transposed matrices...so the intuitive osg::Vec4f p = vm * osg::Vec4f(_cloudsprites[i]-position.osg(), 1.0f); needs to be replaced with... osg::Vec4f p = vm.preMult(osg::Vec4f(_cloudsprites[i]-position.osg(), 1.0f); The patch also optimizes the distance calculation - it evaluates the distances in model space instead of eye space, which reduces computation to a dot- product instead of a matrix multiplication. Great - I was wondering if my sorting was working properly. Obviously it wasn't! Thank-you very much for taking the time to look at the problem and for the patch. I really appreciate you taking the time to correct my programming errors. -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
Re: [Flightgear-devel] Improved 3D Clouds patch
Ron Jensen wrote: Well, that seems to have solved the alpha blending issues! Thanks! Is this applicable to the trees, too? The cloud code does a single bubble sort pass per frame, to avoid the performance penalty of sorting the entire cloud set each frame. We could do something similar for the trees if we were within a given distance of the tree set. However, I'm not sure if it worth the performance penalty. -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
Re: [Flightgear-devel] Improved 3D Clouds patch ( further invesigations )
Heiko Schulz wrote: There is only thing I miss, or can't see it really- are the clouds moving due to the wind? I know that the old clouds did this... Not yet.That's on my list of things to solve next. -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
Re: [Flightgear-devel] TerraSync/SVN should be ready to use
Frederic Bouvier wrote: I'll be able to build Unix binaries for the most common platforms. Would someone do us the honour of providing a standalone 'terrasync' binary for Win32 - statically linked against libsvn in order to save the users from installing yet another dependency ? Terrasync/SVN is already included in the win32 builds I push to ftp.ihg.uni-duisburg.de That's great news. I think it would be very good to have this documented in The Manual for windows users, as it should make using new scenery easier for them, and reduce the load on our FTP sites. Could someone with a Windows system take a little time to use this with FGRun, and write up some simple instructions ? If they want to write them to the wiki that is fine - I'll convert them to Latex for The Manual afterwards. 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
Re: [Flightgear-devel] Improved 3D Clouds patch ( further invesigations )
Heiko Schulz wrote: I began with making new cloud textures and shaping via xml. Creating clouds is easier than I thought though it is a lot of work- like building an aircraft! ;-) Here is a video featuring the 3d-clouds with new textures. I need still work on shaping and creating the other cloud types- in the moment I have only Cumulus: http://de.youtube.com/watch?v=li8nb3rGuHA Unfortunately the video is too compressed- It still needed an hour for upload and another one for processing... They look fantastic ! Thanks for taking the time to improve them. Could you make them available for check-in? BTW I have been working on some minor code improvements for the 3D clouds: - placing the sprites on a sphere rather than a cylinder (a code bug) - Only checking for repositioning of the cloud layer every 60 frames. - Improving the culling heuristic to remove sprites that are too close together. - Performing better shading of the bottom of the cloud. None of these things should affect the work you have been doing. I hope to get these checked in soon - but the weather today is nice so I'm going out to fly my microlight first. I'll make sure to take some photos of clouds! -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
Re: [Flightgear-devel] Another person selling FlightGear under dubious pretenses
--- 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
[Flightgear-devel] Further 3D Clouds updates
Hi All, Attached is a small patch for 3D clouds. It provide the following: 1) Proper spherical distribution of sprites (previously they were distributed cylindrically - whoops) 2) Better shading, so the bottom of the cloud is darker than the top. 3) Fixed a couple of texture sizing bugs. I don't think any of these are controversial, so if someone would commit it, I'd be grateful. Thanks, -Stuart simgear.patch.gz Description: GNU Zip compressed data - 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
James Sleeman wrote: Arnt Karlsen wrote: [a whole bunch of stuff cut] Sigh, I'm sorry Arnt but trying to debate this with you seems to be a waste of time, and it's just getting off topic in my opinion. For once and for all, I have nothing to do with this other than as an observant bystander trying to be helpful, I am not a sock puppet of this fellow Casey as you seem clearly to think I am, I have never so much as met the guy. And with that, I bid you adieu, I hope that a resolution can be made between the developers and Mr Casey quickly so FlightGear developers can sleep easy again, but I can't and won't waste further time on this. Thanks very much for your efforts to find a resolution to this. I really appreciate that you took the time to contact Andrew and bring him onto the list. BTW, don't think Arnts opinion carries any particular weight on this list. AFAIK he has not contributed anything to FG other than the occasional request for dynamic sea-levels (nice idea, but way down the priority list) and noise about GPL violations liberally sprinkled with groklaw URLs and paranioa. PS: I apologise to the list unreservedly if I have upset readers in any way or dragged this so far off topic, my intention was to help, not cause an argument. I'll just go back to lurking now in the perhaps vain hope that one day FlightGear may need something done which is in my small realm of skill that I may render assistance to this noble project. I'm sure you'll find something :) - 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
Frederic Bouvier wrote: I applied your patch. I noticed this message being repeated endlessly when clouds are activated : Warning: detected OpenGL error 'valeur non valide' after RenderBin::draw(,) I'm not sure what is going on here. I'm seeing the same warning, but I haven't yet managed to track it down. I also noticed that even in the Thunderstorm scenario, the cloud coverage is very sparse. Maybe the message tells us it doesn't draw every cloud instance. Possibly, though there is an existing bug that not all cloud tiles are being drawn. In fair weather, I have no clouds ( my cloud density is set at 100% in the rendering options ) This is a new bug, but I don't think it has been introduced by the patch. Still working on it :) -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
Re: [Flightgear-devel] Further 3D Clouds updates
Frederic Bouvier wrote:
Stuart Buchanan a écrit :
Hi All,
Attached is a small patch for 3D clouds.
It provide the following:
1) Proper spherical distribution of sprites (previously they were
distributed
cylindrically - whoops)
2) Better shading, so the bottom of the cloud is darker than the top.
3) Fixed a couple of texture sizing bugs.
I don't think any of these are controversial, so if someone would commit
it,
I'd be grateful.
I applied your patch. I noticed this message being repeated endlessly
when clouds are activated :
Warning: detected OpenGL error 'valeur non valide' after RenderBin::draw(,)
Fixed in the patch below. For some reason the shader didn't like index 16 being
used...
The patch also fixes the chequer-board effect that was causing very sparse
cloud cover.
I've still to work out why the Fair Weather scenario isn't displaying clouds
consistently.
-Stuart
Index: CloudShaderGeometry.hxx
===
RCS file:
/var/cvs/SimGear-0.3/source/simgear/scene/sky/CloudShaderGeometry.hxx,v
retrieving revision 1.3
diff -u -p -r1.3 CloudShaderGeometry.hxx
--- CloudShaderGeometry.hxx23 Nov 2008 12:14:57 -1.3
+++ CloudShaderGeometry.hxx24 Nov 2008 01:19:56 -
@@ -42,12 +42,12 @@ class CloudShaderGeometry : public osg::
{
public:
+const static unsigned int CLOUD_HEIGHT = 10;
const static unsigned int TEXTURE_INDEX_X = 11;
const static unsigned int TEXTURE_INDEX_Y = 12;
const static unsigned int WIDTH = 13;
const static unsigned int HEIGHT = 14;
const static unsigned int SHADE = 15;
-const static unsigned int CLOUD_HEIGHT = 16;
CloudShaderGeometry()
{
Index: cloudfield.cxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/scene/sky/cloudfield.cxx,v
retrieving revision 1.22
diff -u -p -r1.22 cloudfield.cxx
--- cloudfield.cxx23 Nov 2008 12:14:56 -1.22
+++ cloudfield.cxx24 Nov 2008 01:19:56 -
@@ -157,14 +157,16 @@ SGCloudField::SGCloudField() :
}
}
+int leafs = QUADTREE_SIZE / BRANCH_SIZE;
+
for (int x = 0; x QUADTREE_SIZE; x++) {
for (int y = 0; y QUADTREE_SIZE; y++) {
field_group[x][y]= new osg::Switch;
field_group[x][y]-setName(3D cloud group);
// Work out where to put this node in the quad tree
-int i = (int) (BRANCH_SIZE * ((float) x) / ((float)
QUADTREE_SIZE));
-int j = (int) (BRANCH_SIZE * ((float) y) / ((float)
QUADTREE_SIZE));
+int i = x / leafs;
+int j = y / leafs;
quad[i][j]-addChild(field_group[x][y].get(), 0.0f, 2.0f);
}
}
-
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- Texture updates
Heiko Schulz wrote: To: FGFS Developers Mail List flightgear-devel@lists.sourceforge.net Sent: Monday, 24 November, 2008 23:24:52 Subject: [Flightgear-devel] 3d-clouds- Texture updates Hi, There is a lot of improvement left- some days ago I used for testing the cloudstextures from X-pLane, and they worked better. So we just need better textures. So I did my try and finished today the cl-cumulus textures, and added some first nimbustratus and stratos-textures. -Well with the last one I'm not satisfied- and there is still the issue with the ugly borders. But they only appear on near clouds- not on far distance clouds. Maybe a hint... I've still to work on that issue... -I still need to shape the clouds- If I had knowledge about using Phython I would make a script for Blender Here some pics: http://www.flightgear.org/forums/download/file.php?id=379 http://www.flightgear.org/forums/download/file.php?id=378 http://www.flightgear.org/forums/download/file.php?id=377 Looks good. Thanks for your work on this. I didn't use the latest snapshots with the improvements, but there should be not much change. I don't expect to change the XML format or the cloud modeling from now. Mainly I'll be bug-fixing and making performance improvement. -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
Re: [Flightgear-devel] Fwd: Astrasim Expo Flight Simulation Shows 2009
James Turner wrote: On 24 Nov 2008, at 20:30, Curtis Olson wrote: I received this email today and am forwarding it to our devel list so all our UK based developers can see. Assuming the packs are free, worth considering. We have enough people in the UK (or close to it). Depends if they're offering free space or paid space, however. I suspect they may be expecting us to pay for space - the Sherburn event is free to attend, and they've got to make money somehow. Unfortunately these are both probably a bit too far for me to travel. However, if they were to run one in Scotland ;) -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
Re: [Flightgear-devel] Further 3D Clouds updates
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 clouds.diff.gz Description: GNU Zip compressed data - 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
Frederic Bouvier wrote: I cheched your patch in but I still have the checkerboard : http://frbouvi.free.fr/flightsim/fgfs_clouds_checker.jpg but only when the weather scenario is set to none. -Fred Thanks for checking in all my patches. I'm aware that there are still checkerboard issues. That's next on my list :) -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
Re: [Flightgear-devel] 3d clouds interaction with overcast layer
Hi James, James Sleeman wrote: Sorry if this has already been noted, I don't remember seeing it in the recent discussions. A picture is worth 1000 words... http://sirius.gogo.co.nz/fgfs-invisible-cloud.png Taken from about 7000ft, 1500 ft thick overcast layer at low level, scattered 3d clouds with bases a couple thousand feet above the overcast top. The areas of overcast which are drawn under the 3d clouds are rendered transparent. No, I hadn't seen that bug before. Very amusing (OK, I'm easily amused...) Thanks very much for posting it. I guess the problem is the draw order of the different cloud layers, but I must admit that we're reaching the limits of my graphics programming knowledge again. Question for Tim: What's going on there - do I need to put the 3D clouds in a different rendering bin perhaps? -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
Re: [Flightgear-devel] 3d clouds interaction with overcast layer
Tim Moore wrote: The 2D layers are drawn in that order, relative to each other. I didn't consider 3D clouds when I implemented that in OSG. Grep for setRenderBinDetails in simgear/scene/sky/cloud.cxx to see how to insert the 3d clouds into the cloud layer rendering order. Tim Thanks Tim. I'll take a look. I suspect that, as usual, a quick point in the correct direction from you will solve me hours of work :) -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
Re: [Flightgear-devel] FlightGear 1.99.5: Release Candidate
Durk Talsma wrote: I just placed the sources and base package for the pending FlightGear 1.9 release on my webserver: http://durktalsmal.xs4all.nl/SimGear-1.99.5.tar.gz http://durktalsmal.xs4all.nl/FlightGear-1.99.5.tar.gz http://durktalsmal.xs4all.nl/FlightGear-data-1.99.5.tar.bz2 Thanks! Please note that I made an aircraft selection that was based on various suggestions made on the list, but that -as far as I'm concerned - this selection is not yet final. I've been trying to cut down the total number of aircraft in the base package, yet preserve the variety in feature richness that we originally had. Based on this, I came to the following list: 777ER : Fairly Complete Airliner B1900d : Very complete Commuter jet, Twin Turbo Prop. bocian : Our most complete SailPlane c17p: Light Single GA; our default aircraft dhc2: Versatile Tail Dagger, with Aerotowing Capability Concorde: Supersonic Transport Dragonfly : Nice ultralight. F14 : Omnipowerful Jet Fighter; has so many features, it is very well capable of representing the category Fighter Jet CitationX : Small Commuter Jet SopwithCamel: Historic Aircraft UFO : Classified Zeppelin NT : Airship Zero: WW-II Fighter The lack of a helicopter seems like an omission. I note that the base package size above is 200MB. I did a quick look at the (uncompressed) size in KB of each of these aircraft, excluding the CVS directories. 5564777-200 6208b1900d 13528 bocian 17708 c172p 6752dhc2 20656 Concorde 876 Dragonfly 29428 f-14b 4360CitationX 14464 sopwithCamel 232 ufo 2148ZLT-NT 3968A6M2 As can be seen, there is a huge variation, and some pretty huge planes. I would suggest: - Dropping Concorde It is very nice, but also very advanced for new users. - Replace the Sopwith Camel with the Stampe. The Stampe is much easier to fly, and saves us 6.5MB - Look at reducing the size of the c172p. The Liveries directory is 9MB, and each tailplane texture is currently 1MB. - Adding the bo105. This means we have a helicopter, and the aircraft is only 3MB in size. -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
[Flightgear-devel] Yet Another Clouds Patch
Hi All, Attached is another clouds patch. This does the following: 1) Puts the 3D clouds in a cloud rendering bin, to reduce the transparent edge problem. Viewing 3d clouds against a 2D layer _above_ it now blends correctly. There is still a problem when viewing a layer below the 3d clouds, and I'm not sure if/how I'll manage to solve that. Thanks to Tim for pointing me at the correct code (again). 2) Performance improvement by calculating the Bounding box when the cloud is generated rather than ever time it is requested. Could someone please apply it to CVS. As always, please let me know of any (new) bugs you find. I'd also be interested if anyone sees a major performance improvement with this patch - I got a decent improvement with it (30 - 35fps) I am aware of bug causing chess-boarding on stratus layers. I've still to track that down. -Stuart clouds.diff.gz Description: GNU Zip compressed data - 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] Aircraft inter-dependencies for sound and OpenAL
Hi Guys, On some systems (in particular Windows I think), if an aircraft refers to a .wav file in another, not installed aircraft, OpenAL prints the following error and FG exits: (AL_INVALID_VALUE): constructor (alBufferData) Fatal error: Failed to buffer data. This makes diagnosis particularly difficult, and has generated a couple of topics on the Forums: e.g. http://www.flightgear.org/forums/viewtopic.php?f=2t=2191 I've tried putting together a patch for this, but my OpenAL version doesn't suffer from this problem, and I've currently got my hands full trying to get 3D clouds into an acceptable state for the release. If someone is just itching for a bug to fix, they might want to take a look. I think it would be sufficient simply to output the path of the missing .wav file. Additionally, aircraft designers may want to bear this in mind, and suggest that common sounds (the dc3 sounds are often used by other prop planes) are moved into data/Sounds/. -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
Re: [Flightgear-devel] FlightGear 1.99.5: Release Candidate
James wrote: A light sport aircraft or something close would be good, there is a big gap between the Dragonfly and a 172, this in fact is probably the biggest growth area of aviation these days so seems a shame to skip over it. Likely candidates (one of): Lionceau Skyranger J3 Personally, I've always had a soft spot for the J3 Cub. It doesn't have a high-poly model or an advanced 3D cockpit, bit it something that people with low-spec machines can run, and it is pretty small (400kb gzipped). It has also been in the base package for as long as I can remember, so provides some continuity. Don't know about the Camel, it doesn't have good sound, the wheel chocks don't appear to disappear, having engine throttle is really not realistic etc... I'd prefer the Stampe or AN-2 to be the biplane, both are very nice. I'm not at my main machine right now, so I can't check, but I think the AN-2 is about 30MB in size, so probably a bit big for the base package. -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
Re: [Flightgear-devel] FlightGear 1.99.5: Release Candidate
James Turner wrote: On 30 Nov 2008, at 22:23, gerard robin wrote: For instance, yes, the Stampe is easy to fly but not realistic regarding the FDM. Don't forget we don't make a Game. I think the Stampe has fairly good FDM. From my limited experience, it flies as described here: http://www.airbum.com/pireps/PirepStampe.html I am quite aware that we do not make a game. I've actually used FG for some cross-country flight planning in real life - it was useful to be able to visualize the terrain prior to flying it. But equally, the C172, and the 777 handle 'predictably'. Giving new users aircraft which they might *want* to fly, but which are difficult to fly (without, for example, reading a tutorial) are not the best choice for the base package. Concorde and the P51-d are both in this category I think - they have excellent, well-developed and complete models, but neither are a great choice for a new user to pick up and get into the air with. They will produce lots of 'I tried FG, but all I do is crash and crash and crash' feedback. Unlike other sims we have no 'easy' mode in terms of FDM realism to solve this. (And look at all the P-factor feedback even in the C172) Exactly my thoughts. The Concorde may have changed since I last tried it, but as I recall, it starts with quite limited fuel. This is appropriate for a landing, but means that it runs out after about 15 minutes on full throttle/afterburner. A new user is likely to load the Concorde from the launcher, take off on full throttle, fly around of 10 minutes annd then run out of fuel without realizing it and crash. They won't have read the README file, noticed the Flight Engineer view, or understood the fuel dials, fuel transfer system, advanced autopilot etc. Flying the Concorde well requires a lot of study and effort. A completely new user of FG needs to be offered a set of aircraft that they can have a positive experience flying. Once we've got them hooked, they will then be prepared to put the time into flying the challenging planes like the Concorde. -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
Re: [Flightgear-devel] 3D Clouds Check Board
gerard robin wrote: Hello, I recently succeeded to build FG CVS with osg 2.7.5 and boost ( ouf , but on only one computer) . I get that strange 3D clouds mapping , is it just me ? http://pagesperso-orange.fr/GRTux/checkboard.jpg No, it's not just you. It is a (rather poor) attempt by the code to handle cloud coverage. I have a fix for this, along with some further performance tweaks I expect to have them available shortly. -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
Re: [Flightgear-devel] Aircraft inter-dependencies for sound and OpenAL
Geoff Air wrote: (AL_INVALID_VALUE): constructor (alBufferData) Fatal error: Failed to buffer data. I think the ONLY reason you would get this not very helpful specific message is that the FG/SG is compiled against an ALUT previous to version 1, if it still exists?, or the header alut.h has NOT been included - see CVS simgear\sound\sample_openal.cxx, around line 147 and above for later code ... OK. Is this a likely scenario v1.99 then? In particular I'm thinking about the pre-built Windows binaries. Perhaps Fred can comment? -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
[Flightgear-devel] Yet another Clouds Patch (again)
Hi All, Attached is yet another patch for 3D clouds. Could someone please apply it to CVS? This provides the following enhancements bug fixes - Fix the chequer-board bug. - Add proper cloud coverage function - so scattered clouds are now truly scattered. - Add real-time control for visibility range. - Use a limited set of clouds rather than generating a completely new Geode for each cloud. This saves sorting and display time. - Add controls to Rendering dialog to allow fine-tuning of the number of sprites, cloud visibility and the number of different types of cloud. - Add some variance to the sort back-off to avoid all clouds being sorted at the same time. - Pack attributes into vectors for performance - Re-order the cloud type determination code so that if a cloud layer could either be stratus or cumulus, cumulus is used. - Lowered the cloud level in the standard cloud configuration slightly so a cumulus layer is generated rather than stratus. These last two mean that you should see some 3D cumuli if disabling real weather fetch. My thanks to Yon Uriarte for his help with performance work. On my system, this has saved around 10fps - I'm now getting around 38fps instead of 28fps. As always, feedback is appreciated. -Stuart clouds.tar.gz Description: GNU Zip compressed data -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Yet another Clouds Patch (again)
Curt wrote: I did think of that after scratching my head a while ... the metar reported several cloud layers and I did try to switch to a new location as well as switching to fair weather and thunderstorm ... I did get snow and rain, but with a perfectly clear sky. I think there's a bug. I've repro'd it here. I _think_ it may be related to the weather interpolation code I added in the last release. BTW - I've found the source of a long-standing bug were changing the weather scenario when real-weather-fetch was enabled didn't work. -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Final (?) 3D clouds patch
Hi All, Attached is what I'm hoping will be the final 3D clouds patch. It does the following: - Replaces simple shader attributes with vectors (this was missed out of the last patch by mistake) - Includes Yon's Fog update code (Thanks!) - Fixes a bug since 1.0 where --enable-real-weather-fetch stopped the other weather scenarios from working. Let me know of any bugs. -Stuart -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Final (?) 3D clouds patch
I wrote: Hi All, Attached is what I'm hoping will be the final 3D clouds patch. Nope, it wasn't attached, because I hit Send rather than Attach. This time it is attached. Sorry for the noise. It does the following: - Replaces simple shader attributes with vectors (this was missed out of the last patch by mistake) - Includes Yon's Fog update code (Thanks!) - Fixes a bug since 1.0 where --enable-real-weather-fetch stopped the other weather scenarios from working. Let me know of any bugs. -Stuart clouds.tar.gz Description: GNU Zip compressed data -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Final (?) 3D clouds patch
Heiko wrote: The clouds looking great now- the order problem is 99% solved so much as I can see! Yes - I think we're pretty much done. I see only some few problems still: -against a second 3d-clouds layer, the problem with z-drawing appears again I don't know how to solve this at the moment. Sorry :( -setting thunderstorm: the clouds has this transparency problem again, perfomance is weak, no lightning and thunder back (o.k. missing feature) maybe (just an idea) we can create a special set of a thunderstorm which is loaded instead the usual set which seems to be changed for fitting. The Thuderstorm scenario has a very specific METAR. We could easily change this to something that looks better. One of the enhancements I'd like to make after the release is to allow the scenario METAR strings to be defined in a properties file, so a user can save METARs they want to fly in the future. -ns and st-layers covers now full, but also decrease dramatically the fps. Even on my fast machine I only get around 8-12fps- not usuable! Maybe it helps a bit if we couple the cloud visibility range with the generell visibility. Or we should use of the old, 2d-layers instead! I don't think we're likely to find massive performance improvements, so I think using 2-D layers for stratus might be the best solution for the moment. This is very easy to do : The 3D cloud code defaults to a 2D layer if it can't find an appropriate cloud definition in the cloudlayers.xml file. So, you can simple remove the st and ns sections from cloudlayers.xml. If you agree, I'll look at doing that tonight. This may also help with the Thunderstorm scenario. -Stuart -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Final (?) 3D clouds patch
Dave Perry wrote: The 3D cloud appearance is much improved. Thanks to all involved! Several questions and comments. 1. At night, the emmissive seems very very bright. 2. Are you intending that the 3D cloud base should match the lowest level in the current METAR? I just flew with a KDSM METAR using real weather fetch (current METAR copied from ADDS:* KDSM 081954Z 10007KT 10SM BKN130 OVC160 01/M03 A2964 RMK AO2 SLP047 T00111033. * ) This gives a broken layer at 13000 ft AGL but the 3D clouds started at 2000 AGL. Was the weather scenario set to METAR as well - one of the bugs I fixed with the latest patch was that previously --enable-real-weather-fetch over-wrote the various scenarios. Now, you will only get METAR if you have METAR as the scenario, as well as --enable-real-weather-fetch. -Stuart -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Final (?) 3D clouds patch
Curt wrote: I wonder if there is some sort of floating point resolution / rounding problem with the sort? I see a lot of flickering myself. Also if I look some particular direction and the clouds get sorted ok, then look away for even a second, and then look back (by changing the view direction) the clouds seem to have totally lost their previous correct sort and need to be sorted again ... but that doesn't happen until the clouds come back in view. I'm not sure what the sort criteria is, but it seems strange that the sort order would get messed up in a brief second of not having a particular set of clouds in view. One of the performance improvements introduced with the last patch is to re-use clouds rather than generating unique clouds for each position. This makes a significant performance difference on my system (about 5fps IIRC), but means that occasionally you end up between two instances of the same cloud, and the sprites need resorting as you change the view. You can avoid this by increasing the number of cloud types in the Rendering Options dialog, then toggling Enable 3D clouds to cause re-generation. At the moment the slider goes to 20, which minimizes the probability of hitting this issue. Obviously, we could increase the limit still further if required. -Stuart -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Final (?) 3D clouds patch
gerard robin wrote: However i am , now, a bit disappointed with these flickering ( too often, may be it is my graphics cards NVIDIA 7800 GS 512 mo) which decrease dramatically the result (mainly with Metar) . And which make me to come back to the 2D clouds, with the GUI preference. I can understand that, with that last patch you have tried to answer to the low cpu performance, when we are using old computers. It was the case with the old 3D clouds version and nobody apologized about it since we had ever the choice 2D clouds or 3D clouds. I did like better one of your previous version. Yes we had that ugly blue edge ( sometime only when we had a 2d Clouds layer behind), but now, i have blue edge randomly coming on and flickering, which is worth. Wont it be possible to have a version which will come to a better eye candy, even if it is more cpu eater. ? Hi Gerard, Thanks for the feedback - much appreciated. I'll put in an extra option this evening so you can toggle whether the number of cloud types is limited or not. -Stuart -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Final (?) 3D clouds patch
dave perry wrote: You were correct. I had not set the weather scenario to METAR. I ran fgfs once with 3D clouds and once w/o 3D clouds, both with real-weather-fetch and scenario METAR. I only got 1 fps with the 3D clouds. Earlier with 3D clouds, I got about 21 fps. I assume you mean Earlier with 2D clouds, I got about 21fps ? That's very low. I'd expect a drop of about 10fps. What graphics card are you using? Also for both 2D and 3D clouds, the field elevation is not accounted for in applying the cloud base MSL height. The METAR for these 2 runs showed broken at 011 (translates to 1,100 ft AGL) but leaving KDSM field elevation of 957 ft MSL, I was in the clouds by 1100 ft MSL or only about 150 ft AGL. Are we not applying the metar field elevation + metar AGL to get the cloud level? This sounds like a bug, though I thought I saw something adding the field elevation. I'll check. Thanks for pointing it out. -Stuart -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] More 3D cloud changes
Hi All, Those keeping an eye on CVS will notice that Tim Moore has committed some changes to the clouds code. His changes massively improve performance - way above what I've been achieving with my attempts to re-use cloud definitions. I am very grateful to Tim for showing me once again how performance improvements should be done! Attached is yet another clouds patch. This one - Removes the cloud type re-use code - I think they aren't worth the graphical artefacts that they cause in light of Tim's improvements - Changes the transparency of the clouds. Previously, the clouds were transparent at 0m distance, opaque at 200m, then gradually more transparent to the fog limits. This meant they were generally quite transparent. Now, they are opaque from 200m to 15km, then become transparent at 20km. A side effect of this is that the current textures could probably benefit from being made slightly transparent to improve the blending of the sprites against each other. -Stuart clouds.tar.gz Description: GNU Zip compressed data -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] More 3D cloud changes -Yes there is a bug with METAR
Heiko wrote: since when are the 2d-clouds moving? Well exactly- the clouds aren't moving- but there is something between the 2d and 3d-clouds - maybe this explains some renderings bugs Gerad found? This is the weather being interpolated between METAR states. Rather than immediately changing the cloudsbase from 1000ft to 1400ft, the cloudbases are slowly raised. -Stuart -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] More 3D cloud changes -Yes there is a bug with METAR
Heiko wrote: Flickering -o.k. I can live with that. I noticed the same issue on the MSFS x-Demo with their clouds. But it seems that they interpolate the color and alpha values of the sprites which makes the clouds soft and maybe prevent this visible sorting we still have. And well- MSFS has money and a lot more people working on the clouds than we have! (X-pLane has these flickerings too- you can notice on a video on youtube) If I can see right- you have a fps of 26- that's rather high- how you did this? With this clouds I have around 6fps- and I have usually about 60fps. Is this with Tim Moore's latest patch? On my system it increases frame-rates significantly with 3D clouds enabled. I really have big fps troubles with stratus and nimbus cloud layers here and usually I have no problems to reach 60-100 fps with all features enabled. In the moment I don't see that we can get this with 3d-clouds and from the commercial (game)sims I know, that they even use 2d-layers instead. So we should use the 2d-layers instead. Maybe we can improve the textures for these 2d-clouds. OK. I'll comment out the stratus and nimbus 3D cloud layers in cloudlayers.xml Generelly the clouds appearence is better though of course we should add some alpha to the textures. I will try this to make this weekend. Thanks. If that doesn't work very well, I can add some alpha within the shader. The only thing I don't like, that is that the cloud visibility range is only to 20km and at the horizon they look very blueish- never seen in reality. This is due to the fog blending. They should still be affected by the sun position, colour etc. -Stuart -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ 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
Csaba wrote: Also, add one new bug reported by Jano: even if you are using METAR scenario, METAR updates don't affect the visuals. That is, if you fly to another airport, or wait for the 15 minute update interval, nothing changes even though the new values show in the property browser. The attached patch fixes this - the 3D clouds now respect changes to the environment caused by updated METAR etc. It also increases the AlphaFunc as suggested by Tim. I've also committed Heiko's latest cloud changes. Please let me know if these improve things. -Stuart clouds.tar.gz Description: GNU Zip compressed data -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___ 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
Martin Spott wrote: Not meaning to complain or trying to urge anyone, I just wanted to report back that setting: --prop:/environment/weather-scenario=METAR either on the command line or in the ~/-fgfsrc file still does neither set the Weather source to METAR in the Weather Scenario menu nor does it set the respective entry in the property tree (according to the Property Browser). When setting the string to METAR in the Property Browser I _do_ experience a visible change in the cloud scenario and the Weather source indeed lists METAR, but the clouds still look different from those which I get by selecting the respective Weather source again, directly in the Weather Scenario menu. Hi Martin, I agree that this is a serious bug, and is next on my list to fix. I hope to get around to it on Tuesday evening, but if anyone has too much time on their hands in the meatime ... :) I think the root of the problem is that the Weather Scenario dialog forces a rebuild of all the clouds. I think this should be done whenever the /environment/weather-scenario is changed. -Stuart -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Nasal globals.nas, 1.42, 1.43
Melchior FRANZ wrote: * James Turner -- Wednesday 17 December 2008: + var KT2MPS = 0.51; # knots to m/s Personally I think all these constants would be easier to read if they were written the same way as the Simgear ones, i.e MPS_TO_KT, NM_TO_M and so on. I find them equally easy to read and decided to use the way that YASim uses (from the same author as Nasal, as you probably know). See ./src/FDM/YASim/FGFDM.cpp. I only made the DEG2RAD even shorter (which might indeed have been a mistake). But you can easily do something like this in your Nasal code (once there is something like your Nasal code, that is ;-): var MPS_TO_KT = MPS2KT; What do other Nasal developers think? I'm willing to change it if others have problems with that, too. (And to change all occurrences in the repository.) Well, it's been a while since I wrote some Nasal code, but I personally prefer the longer names. But then my code tends to be very verbose anyway. :) BTW (or BY_THE_WAY, as some say): LAUGH_OUT_LOUD -Stuart -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] (no subject)
Hi All, Attached is a very small patch that fixes the issue reported by Martin where --prop:/environment/weather-scenario=METAR had no effect. I think this is a pretty safe patch that should be included in the release. -Stuart flightgear.patch.gz Description: GNU Zip compressed data -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] METAR Patch (was : no subject)
I wrote: Subject: Hi All, Attached is a very small patch that fixes the issue reported by Martin where --prop:/environment/weather-scenario=METAR had no effect. I think this is a pretty safe patch that should be included in the release. -Stuart Sorry for the lack of subject. -Stuart -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear-1.99.5-RC2
John Denker wrote: On 12/17/2008 08:04 PM, Csaba Halász wrote: I assume you are not using sync-to-vblank or fps throttle. That's a correct assumption. Forsooth, I've never heard of sync-to-vblank or fps throttle in this context. The names sound nice, but -- They are not mentioned in --help --verbose -- They do not appear in the drop-down menus AFAICT. -- They do not appear in the getstart manual or in any of the plain-text documents in data/Docs AFAICT. Good point. If I get the chance before the release I'll check the manual and make sure they are mentioned. I mention this because I'm trying to test things from the user's point of view. If these features are going to be important to users, it would be useful to put them where users can find them. Or ... maybe turn them on by default. Recomputing the image at a rate that exceeds the refresh rate of the display seems kinda pointless, unless I'm overlooking something. That is a fair point, but I don't think we have any easy way to determine the refresh rate of the display. Setting the fps throttle by default in preferences.xml might be worthwhile. I don't have it set myself, but I believe that many people use it to provide more consistent frame-rates. -Stuart -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear-1.99.5-RC2
Durk Talsma wrote: Okay, of the people who responded, the vote was unanimously against this idea. If it's up to me, I vote for going back to our original consensus, and releasing this version as 1.9.0. As far as I can tell, this number has the majority vote, and although not Curt's preference, he can live with it. OK. I'll update the manual source to say 1.9.0 rather than 1.99.5. Durk - if you change your mind right before the release, can you make sure that Martin has checked in a new version of the manual with the new version number. Martin - I'll assume you are happy to generate the manual for the release and check it in. Let me know if you're too busy. -Stuart -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Further 3D clouds patch
Vivian wrote: I hope I'm doing something wrong with cvs-head source and data as of this morning. I'm seeing this (using METAR at KSFO): ftp://ftp.abbeytheatre2.dyndns.org/fgfs/Screen-shots/clouds.jpg apart from this the recent cloud update is working well. Cumulus looks particularly well, and the frame rate hit is just bearable. Could you post the METAR you had when you saw this? The white layer looks like stratus, which should have been disabled by the latest changes to cloudlayers.xml. I'm not sure what the dark gray boxes are - possible nimbo-stratus. We may need to disable everything by Cu and Cb for the release. -Stuart -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Further 3D clouds patch
Vivian wrote: Of course, by the time I looked the METAR had changed. No matter - this gives a very similar effect: SCTO36 BKN047 OVC060 Don't suppose that helps much Yes, it helps. I can put together the appropriate cloud layers from that information. Thanks, -Stuart -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] METAR interpolation?
Curt wrote:
I just did a cross country flight with the latest CVS cloud/weather/metar
changes and I noticed that the weather interpolation that smoothed out
abrubt changes to wind and clouds when a new METAR report comes
in seems to have now been lost. We are back to abrubt wind and cloud
changes. I haven't had a chance to dig in myself, but thought I'd mention
this to the folks that currently have their heads immersed in that section of
the code.
Thanks for the bug report.
The culprit as you guessed is some of the 3D cloud changes. The attached patch
reverts one of my changes which ensured that the 3D clouds were updated with
METAR. Unfortunately this had the side-effect of over-writing the environment
properties, and therefore nuking the interpolation work.
The patch below backs out that change. Unfortunately this means the change
to the cloud coverage due to changing METAR will not be reflected in the 3D
clouds
(2D clouds are unaffected). Unfortunately I don't think it will be possible to
fix
this before the release.
Could someone please commit this? Thanks.
-Stuart
Index: environment_ctrl.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Environment/environment_ctrl.cxx,v
retrieving revision 1.58
diff -u -p -r1.58 environment_ctrl.cxx
--- environment_ctrl.cxx19 Dec 2008 07:42:13 -1.58
+++ environment_ctrl.cxx19 Dec 2008 22:36:48 -
@@ -502,7 +502,6 @@ FGMetarEnvironmentCtrl::update_env_confi
double aircraft_alt = fgGetDouble(/position/altitude-ft);
char s[128];
int i;
-bool rebuild_clouds = false;
for (i = 0, layer = layers.begin(); layer != layers_end; ++layer, i++)
{
double currentval;
@@ -520,7 +519,6 @@ FGMetarEnvironmentCtrl::update_env_confi
const char* coverage = (*layer)-getStringValue(coverage,
clear);
if (strncmp(fgGetString(s), coverage, 128) != 0) {
fgSetString(s, coverage);
-rebuild_clouds = true;
}
snprintf(s, 128, cl, i);
@@ -570,10 +568,6 @@ FGMetarEnvironmentCtrl::update_env_confi
}
}
-if (rebuild_clouds) {
-// Force an update of the 3D clouds
-fgSetDouble(/environment/rebuild-layers, 1.0);
-}
} else {
// We haven't already loaded a METAR, so apply it immediately.
dir_from = fgGetDouble(/environment/metar/base-wind-range-from);
--
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] METAR interpolation?
Csaba wrote: On Fri, Dec 19, 2008 at 11:38 PM, Stuart Buchanan wrote: The patch below backs out that change. Unfortunately this means the change to the cloud coverage due to changing METAR will not be reflected in the 3D clouds (2D clouds are unaffected). Unfortunately I don't think it will be possible to fix this before the release. I personally consider that a show-stopper (unless we disable 3d clouds in the release). Just to be clear: a) The patch I provided fixes METAR interpolation. b) However, it means that 3D clouds are not completely interpolated. A change in cloudbase will be interpolated (quite nicely). However, a change in cloud coverage (including the removing or adding of layers) will _not_ have any effect. I agree that its bad. Unfortunately I don't have time to fix it this weekend before the release. If someone else wants to look, the place to start is the fgclouds.cxx code, in particular update_metar_properties() and update_env_config(). There is currently a split between fgclouds and the environment manager setting up these properties. -Stuart -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] METAR interpolation?
I wrote : Csaba wrote: On Fri, Dec 19, 2008 at 11:38 PM, Stuart Buchanan wrote: The patch below backs out that change. Unfortunately this means the change to the cloud coverage due to changing METAR will not be reflected in the 3D clouds (2D clouds are unaffected). Unfortunately I don't think it will be possible to fix this before the release. I personally consider that a show-stopper (unless we disable 3d clouds in the release). Just to be clear: a) The patch I provided fixes METAR interpolation. b) However, it means that 3D clouds are not completely interpolated. A change in cloudbase will be interpolated (quite nicely). However, a change in cloud coverage (including the removing or adding of layers) will _not_ have any effect. I agree that its bad. Unfortunately I don't have time to fix it this weekend before the release. I've managed to fix this by differentiating rebuilding the 3D layers (e.g. due to METAR updates) from rebuilding the entire environment (due to a change in scenario). Could someone apply the attached patch please? Thanks -Stuart clouds.tar.gz Description: GNU Zip compressed data -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] screenshots for v1.9
Heiko Schulz 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 Absolutely superb! Merry Christmas and a happy new year to all! HHS And to you too. -Stuart -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC : FlightGear Roadmap for 2.0 and further
Tat wrote: I'm very happy that we finally released 1.9.0. Thanks for your hard work in making it happen! According to the discussions before the release, I believe that many of us are willing to release FlightGear more often, like semiannually or quarterly (or even more often). To release more than once a year, I believe that we need to have clearer roadmap, versioning policy, and the release process. Here are my opinions so please give me comments and feedback please. A roadmap would be a great idea. However, I'm not sure a quarterly release cycle is realistic. Allowing for a 2 week RC test, you're talking about less than 3 months of actual development between releases. That's not much time. For example, I think we've had 3D clouds in CVS for 3 months at least, and we certainly haven't ironed out all the bugs yet. 1) The version numbers and release dates Here's an example list of version numbers and release dates when FlightGear will be released quarterly. 2.0 - at the end of March, 2009 2.1 - at the end of June, 2009 2.2 - at the end of September, 2009 2.3 - at the end of December, 2009 0.1 is increased on every release until it reaches the goal of 3.0.0 (it can be 2.10.0 or 2.150.0 :-p) I'd prefer to name something 2.0 or 3.0 when we think we are producing a major release, with significant new features. Producing 3.0 simply because the last release was 2.9 will set false expectations for users - they will be expecting significant feature improvements. Much better would be 2.01, 2.02 ... that gives us much more leeway before the next major release. I think incrementing minor version number on each release is enough for our project, and micro version number can be reserved for bug-fix releases between two releases. That's certainly sensible. 2) Milestones (Goal for each release) Here's an example list of must-achieve things for 2.0.0 (based on discussion on the list, I believe). [2.0.0 - at the end of March, 2009] Functionality: - Landing Lights - Shadows - More improvements in 3D clouds (I don't know the exact goal on this though...) These seem like sensible goals for a 2.0 release. However, they appear to be very dependant on Tim and myself. Regarding 3D clouds: - There are significant ordering issues, quite apart from the challenge posed by creating stratus layers. Frankly, unless someone else is intending to spend significant time writing 3D clouds _code_, I don't think 3 months is going to be enough time for me to fix all the issues. I made myself enough of a hostage to fortune last time by saying I'd have them ready by Christmas - I'm not making that mistake again ;) I believe Tim has spent some time working on Shadows (don't know about landing lights). He's much more sensible than me and hasn't said when he'll have any code ready ;) Pushing for a release in 3 months without any commitment from the developers involved in the main feature improvements is pretty high risk. [We'll gloss over the fact I'd be a bit disgruntled being told when to have something ready. That's far to close to work, and FG dev is pretty close already ;) ] Reliability: - NaN things must be eliminated I completely agree on this one. We can add more items on each category (I took these categories from ISO-9126, but we can express the must-achieve things in a different categorization) Maybe we need to separate general FG things from per aircraft things. It is also very good to organize the must-achieve items for each release based on the following documents: - http://wiki.flightgear.org/index.php/Long_Term_Goals - http://wiki.flightgear.org/index.php/FGFS_Todo - http://wiki.flightgear.org/index.php/Feature_Requests_/_Proposals_/_Ideas As far as I am aware, none of those documents is up to date, or reflects current development. I think a roadmap checked into CVS would be more sensible. We have a docs repository for exactly this sort of thing. At the very least it would mean that some random user can't just add features to the roadmap. snip 3) Release branch I believe that we need to have a release branch for both developers and release organizers. The main reason is to separate bug fixes from implementing a new features. This way, developers don't have to wait for the release to check in attractive but likely buggy code to cvs. Usually you must not include a new feature to the release branch once it is created. However, if many developers want to include one to the release branch, then we can discuss it in the list. After each release, we'll merge the bug fixes to trunk. If we get used to this release process, maybe a branch exists only for a few weeks, and thus merging changes to trunk is not gonna be that hard. I think cutting a release branch just prior to the release makes sense, but having long-term release branches and only merging from trunk when you're confident a feature is
Re: [Flightgear-devel] 1.9.0 feedback
James Turner wrote: I'm noticing quite a few people on the forums with difficulty running 1.9.0 - either long delays on startup, hangs while loading scenery, crashes or rendering issues. Some of these are certainly driver issues, especially with ATI and the dreaded Intel chipsets. And of course people who're having problems are the most vocal on forums :) In fact, sadly it seems pretty difficult to find a positive comment about 1.9 :( Unfortunately, it appears that nowadays pretty much every FG developer runs NVidia, and often Linux, so we're simply not using the same platform as a lot of our users. I think it's something we need to bear in mind for the next release. We'll need to put more effort to get external testing of RCs on Windows/ATI. It does seem as if the message that 1.9.0 is a release *leading towards* 2.0 has not been communicated very clearly outside this list, though - I'm not sure if there's any way that could be achieved? We need people to run the code to get feedback, obviously, but some people seem to think that 1.0 has been 'replaced', and while that's sort of true, I figured both would remain available in parallel until the 2.0 timeframe. Except that the aircraft downloads etc. on the flightgear website are now only 1.9... Given that the only announcement for 1.9 is a single line on the website, this isn't surprising. As far as I am aware, we haven't really announced 1.9 either through the -user mailing list, or the Forum. Durk - do we have a change-log we can advertize yet? -Stuart -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 1.9.0 feedback
Durk wrote: In the mean time, here is the changelog. A couple of comments on reading this again. rendering bugs). The switch to OpenSceneGraph marks an important milestone for FlightGear, as it allows us to make full use of the advanced rendering options already available in OpenSceneGraph, such as stereographic view modes on screen statistics, easy definition of cameras for multiscreen systems, onscreen statistics, native OpenSceneGraph 3D model loaders and much more. onscreen statistics is mentioned twice. Major new developments and features: - Major overhaul of the graphics code. FlightGear 1.9.0 makes use of the OpenSceneGraph library - Easy setup of multidisplay systems using multiple OpenSceneGraph Cameras driven by one single instance of FlightGear. - Multithreaded 3D model loader leads to much smoother performance - New particle system based precipitation code - configurable XML particle animations for smoke, spray, fire, etc - New dynamically configurable 3D Clouds. - pick animations, which allow for better clickable instrument panels - multiplayer specific on-screen menu - AI code can generate wingmen - At selected airports, it is now possible to start at a predefined parking position, as an alternative to starting at the runway. - Support for Lighter than air vehicles - Shader based tree rendering. This new feature allows For much denser tree Reads better as This new feature allows for much higher tree density without any reduction in frame rate -Stuart -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
