Re: [Flightgear-devel] Future Weather System
> Here, with a Core 2 Quad, 4Gb RAM, nVidia GTx285 with 2Gb VRAM there is a > huge difference in performance. At EGMH and using METAR, I get 75 fps > with > Global Weather, but when I use Local Weather, using the same METAR, I > get a > little over half that. I hate to repeat myself, but what set of options (cloud view range, dynamics on/off, dynamical convection on/off, thermals on/off are we comparing here? If you're running default settings, you're asking ~3 times the area cloud coverage from Local Weather... naturally that is a bit slower. If you have dynamical weather (= moving clouds) on, then indeed you're not only losing plenty of framerate as compared to global but you're also getting frequent garbage collection due to loads of Nasal work running per frame, i.e. frame delays. Which is why we're moving cloud generation to Stuart's system which moves clouds much more efficiently. We know that already - in the mean time, if it's bothersome, switch dynamical weather off. You can (by maxing out all options) easily design a situation in which Local Weather freezes your system to 6 frames. Rather than doing that, it allows you to make a choice what is important for you and where you want to use the resources. I also don't get any flickering... so I can't really diagnose what is going on, but basically you're looking at models in the scenery, so either it's a shader problem (which'd be odd since it is basically the same shader for all the clouds) or some deeper rendering issue - but nothing I could fix. I have to rely on the Flightgear core to display a model correctly if I ask it to place it into the scenery. > And if we could loose the hard edges around some of the textures that > would help. Gimp does the trick. It's mainly down to someone doing it (either working out an efficient way of cleaning the texture, or doing it pixel by pixel manually) - it's not exceedingly high up on my to-do list. Cheers, * Thorsten -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Future Weather System
>> You can enable a better property to compare performance using "View" => >> "Show worst-case frame delay". It shows the longest delay in between two >> frames within the last second of simulation (lower left corner). The >> lower the number, the better. In order to maintain an acceptable 25Hz >> simulation, the frame delay must never exceed 40ms. >> Is anyone capable of running FlightGear with either global or local >> weather enabled with a frame spacing not exceeding 40ms? Quick test at KSEA with the F-16 and current METAR, cloud visibility range 20 km, dynamical weather off (as I said, that is indeed much slower): Local 25-48 ms, 48 fps indicated Global 25-50 ms 40 fps indicated I hold to what I stated earlier... * Thorsten -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FG 2.4 consistency
FG 2.4 consistency. Hello, You don't know us since we are newbee, (3 months working seriously with FG). We are a team ( 4 guys and a lady ). We have had several talks with several devel team persons about a Catalina model update. That update has been rejected arguing that everything is frozen until FG 2.4 will be freed, considered consistent, without any bug. We can understand such rule, it is the best way in relation with programs simgear , flightgear, osg, plib, nd a lot of data from data directory (gui, nasal, and others we are forgetting) . It is the Wrong way for the Aircraft models, since the checking of consistency wants first a consistent FG program. With Catalina, our target was to make an update consistent with the coming FG 2.4 in order to replace the old Catalina buggy idiot version (was probably right with an older FG version 1.9 ?) which is in the "FG DOWNLOAD PAGES". Unfortunately we discovered quickly we could not get any good result with FG git, which was that buggy it could not work correctly (mainly with the MS Windows version), we were met with that difficulty for a long period. We were patient, waiting for fixes , contributing also to the Fg Google Bug List, and working partly with a Linux version. How are you walking ? on the head ? since you reverse the priority. The answer from these devel team persons, was a joke, at least to us, they said "we will include your project with FG 2.6" ( February ?), they probably make fun of us ( do you consider newbee are not serious ?). That model will be again not consistent , how will be FG 2.6 ? we don't know. In spite of the good level of our team, nobody here is able to answer that question, even if we are studying carefully the progress on JSBSim-devel ( congratulation to the jsbsim team ). Don't tell us we can work and update in parallel since testing a model is ever BEHIND a WORKING FG program. We don't mind the lost of "our fives persons" time spent on the Catalina, since we can learn from it. We have learnt we must not contribute to GPL update within FG, since the FG team answers does not convince us to contribute, we do not want to waste time. To please to the users, our model will be ever checked against an FG stable version. We will start that rule with FG 2.4, offering our models within our pages, but, under an other license. Sorry for our English, mainly middle east native ( and living partly in France , south ). Best regards Sent through FG devel-mail without subscribing (we hope it will be sent) And sent to the fg forum -- David and Josh ( the others are in vacation) for the E.E.K.P.O. GrthTeam https://sites.google.com/site/grtuxhangar/home -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG 2.4 consistency
"grth_team" wrote: > How are you walking ? on the head ? since you reverse the priority. > > The answer from these devel team persons, was a joke, at least to us, I think this flavour of 'feedback' is not worth discussing. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG 2.4 consistency
On Wed, 13 Jul 2011, Martin Spott wrote: > "grth_team" wrote: > >> How are you walking ? on the head ? since you reverse the priority. >> >> The answer from these devel team persons, was a joke, at least to us, > > I think this flavour of 'feedback' is not worth discussing. > Martin, I suspect that there is a _drastic_ translation issue involved. I'm willing to give them the benefit of the doubt - I don't think his intention was to be a jerk about it. It may just be either his command of English or the translation engine he used that gives the message the hard edge it has. g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.simpits.org/geneb - The Me-109F/X Project Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Political correctness is a doctrine, fostered by a delusional, illogical minority, and rabidly promoted by an unscrupulous mainstream media, which holds forth the proposition that it is entirely possible to pick up a turd by the clean end. -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG 2.4 consistency
On Wed, Jul 13, 2011 at 2:24 PM, grth_team wrote: > The answer from these devel team persons, was a joke, at least to us, > they said "we will include your project with FG 2.6" ( February ?), > they probably make fun of us ( do you consider newbee are not serious > ?). As one of the people who originally replied to the forum post regarding an update to the Catalina, I should respond to this. It certainly was not my intention to make fun of you, nor to make a joke. > That model will be again not consistent , how will be FG 2.6 ? we > don't know. > In spite of the good level of our team, nobody here is able to answer > that question, even if we are studying carefully the progress on > JSBSim-devel ( congratulation to the jsbsim team ). > > Don't tell us we can work and update in parallel since testing a model > is ever BEHIND a WORKING FG program. The Catalina update is quite a significant change. However, once it is applied after the 2.4.0 release, any further updates to keep it in sync with the upcoming 2.6.0 release will be minor, and therefore appropriate up until a much later point in the release cycle. > We don't mind the lost of "our fives persons" time spent on the > Catalina, since we can learn from it. > We have learnt we must not contribute to GPL update within FG, since > the FG team answers does not convince us to contribute, we do not want > to waste time. I'm very sorry you feel this way. Fortunately most FG developers do not, otherwise FG would cease to exist. -Stuart PS: I'll copy this response to the Forums. -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG 2.4 consistency
I fail to understand why an aircraft that does not feature in the core release package should come under the freeze. Also, as we are so often told that git can do everything, why can a post-release branch not be set up for new source code developments, or a new release/freeze branch specifically for the new release? I thought that was the whole raison-d´etre of the devel branch. I´m sure that there must be some administrative reason for this as the release team probably have enough on their plate, but it is a pity to turn away possible new contributors. Alan -Original Message- From: grth_team Sent: Wednesday, July 13, 2011 2:24 PM To: flightgear-devel@lists.sourceforge.net Subject: [Flightgear-devel] FG 2.4 consistency FG 2.4 consistency. Hello, You don't know us since we are newbee, (3 months working seriously with FG). We are a team ( 4 guys and a lady ). We have had several talks with several devel team persons about a Catalina model update. That update has been rejected arguing that everything is frozen until FG 2.4 will be freed, considered consistent, without any bug. We can understand such rule, it is the best way in relation with programs simgear , flightgear, osg, plib, nd a lot of data from data directory (gui, nasal, and others we are forgetting) . It is the Wrong way for the Aircraft models, since the checking of consistency wants first a consistent FG program. With Catalina, our target was to make an update consistent with the coming FG 2.4 in order to replace the old Catalina buggy idiot version (was probably right with an older FG version 1.9 ?) which is in the "FG DOWNLOAD PAGES". Unfortunately we discovered quickly we could not get any good result with FG git, which was that buggy it could not work correctly (mainly with the MS Windows version), we were met with that difficulty for a long period. We were patient, waiting for fixes , contributing also to the Fg Google Bug List, and working partly with a Linux version. How are you walking ? on the head ? since you reverse the priority. The answer from these devel team persons, was a joke, at least to us, they said "we will include your project with FG 2.6" ( February ?), they probably make fun of us ( do you consider newbee are not serious ?). That model will be again not consistent , how will be FG 2.6 ? we don't know. In spite of the good level of our team, nobody here is able to answer that question, even if we are studying carefully the progress on JSBSim-devel ( congratulation to the jsbsim team ). Don't tell us we can work and update in parallel since testing a model is ever BEHIND a WORKING FG program. We don't mind the lost of "our fives persons" time spent on the Catalina, since we can learn from it. We have learnt we must not contribute to GPL update within FG, since the FG team answers does not convince us to contribute, we do not want to waste time. To please to the users, our model will be ever checked against an FG stable version. We will start that rule with FG 2.4, offering our models within our pages, but, under an other license. Sorry for our English, mainly middle east native ( and living partly in France , south ). Best regards Sent through FG devel-mail without subscribing (we hope it will be sent) And sent to the fg forum -- David and Josh ( the others are in vacation) for the E.E.K.P.O. GrthTeam https://sites.google.com/site/grtuxhangar/home -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG 2.4 consistency
I think Gene put it well. We need to give them the benefit of the doubt and cut them some slack due to potential language/translation issues and if they are newer to the project they need some time to figure out our project culture and how things get done here. Likewise I hope they will also be willing to give us the benefit of the doubt, cut us some slack, and be willing to learn our project culture in return. Flexibility and good will on both sides usually yields the happiest results. Curt. On Wed, Jul 13, 2011 at 9:49 AM, Alan Teeder wrote: > I fail to understand why an aircraft that does not feature in the core > release package should come under the freeze. > > Also, as we are so often told that git can do everything, why can a > post-release branch not be set up for new source code developments, or a > new > release/freeze branch specifically for the new release? I thought that was > the whole raison-d´etre of the devel branch. > > I´m sure that there must be some administrative reason for this as the > release team probably have enough on their plate, but it is a pity to turn > away possible new contributors. > > Alan > > -Original Message- > From: grth_team > Sent: Wednesday, July 13, 2011 2:24 PM > To: flightgear-devel@lists.sourceforge.net > Subject: [Flightgear-devel] FG 2.4 consistency > > > FG 2.4 consistency. > > Hello, > > You don't know us since we are newbee, (3 months working seriously > with FG). > We are a team ( 4 guys and a lady ). > > We have had several talks with several devel team persons about a > Catalina model update. > > That update has been rejected arguing that everything is frozen until > FG 2.4 will be freed, considered consistent, without any bug. > > We can understand such rule, it is the best way in relation with > programs simgear , flightgear, osg, plib, nd a lot of data from data > directory (gui, nasal, and others we are forgetting) . > > It is the Wrong way for the Aircraft models, since the checking of > consistency wants first a consistent FG program. > > With Catalina, our target was to make an update consistent with the > coming FG 2.4 in order to replace the old Catalina buggy idiot > version (was probably right with an older FG version 1.9 ?) which is > in the "FG DOWNLOAD PAGES". > Unfortunately we discovered quickly we could not get any good result > with FG git, which was that buggy it could not work correctly (mainly > with the MS Windows version), we were met with that difficulty for a > long period. > We were patient, waiting for fixes , contributing also to the Fg > Google Bug List, and working partly with a Linux version. > > How are you walking ? on the head ? since you reverse the priority. > > The answer from these devel team persons, was a joke, at least to us, > they said "we will include your project with FG 2.6" ( February ?), > they probably make fun of us ( do you consider newbee are not serious > ?). > That model will be again not consistent , how will be FG 2.6 ? we > don't know. > In spite of the good level of our team, nobody here is able to answer > that question, even if we are studying carefully the progress on > JSBSim-devel ( congratulation to the jsbsim team ). > > Don't tell us we can work and update in parallel since testing a model > is ever BEHIND a WORKING FG program. > > We don't mind the lost of "our fives persons" time spent on the > Catalina, since we can learn from it. > We have learnt we must not contribute to GPL update within FG, since > the FG team answers does not convince us to contribute, we do not want > to waste time. > > To please to the users, our model will be ever checked against an FG > stable version. > We will start that rule with FG 2.4, offering our models within our > pages, but, under an other license. > > > > > Sorry for our English, mainly middle east native ( and living > partly in France , south ). > > Best regards > > Sent through FG devel-mail without subscribing (we hope it will be > sent) > And sent to the fg forum > > -- > David and Josh ( the others are in vacation) for the E.E.K.P.O. > GrthTeam > https://sites.google.com/site/grtuxhangar/home > > > -- > AppSumo Presents a FREE Video for the SourceForge Community by Eric > Ries, the creator of the Lean Startup Methodology on "Lean Startup > Secrets Revealed." This video shows you how to validate your ideas, > optimize your ideas and identify your business strategy. > http://p.sf.net/sfu/appsumosfdev2dev > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > > > -- > AppSumo Presents a FREE Video for the SourceForge Community by Eric > Ries, the creator of the Lean Startup Methodology on "Lean Startup > Secrets Revealed." This video sh
Re: [Flightgear-devel] FG 2.4 consistency
Am 13.07.2011 19:00, schrieb Curtis Olson: > I think Gene put it well. We need to give them the benefit of the doubt > and cut them some slack due to potential language/translation issues and > if they are newer to the project they need some time to figure out our > project culture and how things get done here. > > Likewise I hope they will also be willing to give us the benefit of the > doubt, cut us some slack, and be willing to learn our project culture in > return. > > Flexibility and good will on both sides usually yields the happiest > results. Wise words. This issue was the reason for my call for help yesterday. Fortunately, a well-known contributor has offered his help and I am sure he will find a bridge over the language gap (which I am convinced is the only reason for the trouble). Torsten -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG 2.4 consistency
> Also, as we are so often told that git can do everything, why can a > post-release branch not be set up for new source code developments, or a new > release/freeze branch specifically for the new release? I thought that was > the whole raison-d´etre of the devel branch. You certainly can do that - and there are probably 50 more ways to prepare for a release. We chose a slightly different approach, laid out by a handful of developers and active users during three evenings at LinuxTag. The strategy was discussed and agreed on on this mailing-list without a single objection. There will be a retrospective when we can discuss if it was a success or not, if we can improve the process or not. For now, let's try to get the release out as planned. Don't change the aircraft in the middle of the flight (and we are already turning to final approach). Torsten -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG 2.4 consistency
Curtis Olson wrote: > I think Gene put it well. We need to give them the benefit of the doubt and > cut them some slack due to potential language/translation issues [...] Sure, I doubt that this is a translation issue here: Does it strip the affront off an affront just by passing it through a slightly too straightforward translation ? I'd recommend to apply the "potential language/translation issues" on a case-by-case basis. > Likewise I hope they will [...] be willing to learn our project culture in > return. Precisely this is the point. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG 2.4 consistency
Every road runs in two directions, and if we are all willing to go a little bit beyond half way to meet each other, we most often will get there. On Wed, Jul 13, 2011 at 1:01 PM, Martin Spott wrote: > Curtis Olson wrote: > > > I think Gene put it well. We need to give them the benefit of the doubt > and > > cut them some slack due to potential language/translation issues [...] > > Sure, I doubt that this is a translation issue here: Does it strip the > affront off an affront just by passing it through a slightly too > straightforward translation ? I'd recommend to apply the "potential > language/translation issues" on a case-by-case basis. > > > Likewise I hope they will [...] be willing to learn our project culture > in > > return. > > Precisely this is the point. > > Cheers, >Martin. > -- > Unix _IS_ user friendly - it's just selective about who its friends are ! > -- > > > -- > AppSumo Presents a FREE Video for the SourceForge Community by Eric > Ries, the creator of the Lean Startup Methodology on "Lean Startup > Secrets Revealed." This video shows you how to validate your ideas, > optimize your ideas and identify your business strategy. > http://p.sf.net/sfu/appsumosfdev2dev > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG 2.4 consistency
On Wed, Jul 13, 2011 at 3:24 PM, grth_team wrote: > > We have learnt we must not contribute to GPL update within FG, since > the FG team answers does not convince us to contribute, we do not want > to waste time. > > To please to the users, our model will be ever checked against an FG > stable version. > We will start that rule with FG 2.4, offering our models within our > pages, but, under an other license. I fail to see how your problem has anything to do with licensing. -- Csaba/Jester -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG 2.4 consistency
The nice thing about FlightGear is freedom. The grth_team is free to do what they wish. They can develop what ever they want and they can support whichever versions they deem best as long as they abide by the terms of the gpl. It might take some time to realize this, but it is very hard to guilt and bully open-source folks into doing something. For many of us, we put up with too much of that in our day jobs and we come to projects like FlightGear to outlet our talents in a more relaxed and positive environment. The Cat is a cool airplane (I've flown in one myself when I was 5 years old), but it seems a little childish if someone wants to threaten that they will take all their toys and go home if we don't do things exactly as they wish. I've heard many variants on that theme over the years. I want to do whatever I can to create an environment where people can have a positive outlet for their talents and energy, and I want to encourage that process as much as possible. But if people don't feel that this is the place for them, why make a big deal out of it and setup various ultimatums and backhanded threats. Find someplace better, may the force be with you, thanks for all the fish. Peace! Curt. On Wed, Jul 13, 2011 at 5:56 PM, Csaba Halász wrote: > On Wed, Jul 13, 2011 at 3:24 PM, grth_team wrote: > > > > We have learnt we must not contribute to GPL update within FG, since > > the FG team answers does not convince us to contribute, we do not want > > to waste time. > > > > To please to the users, our model will be ever checked against an FG > > stable version. > > We will start that rule with FG 2.4, offering our models within our > > pages, but, under an other license. > > I fail to see how your problem has anything to do with licensing. > > -- > Csaba/Jester > > > -- > AppSumo Presents a FREE Video for the SourceForge Community by Eric > Ries, the creator of the Lean Startup Methodology on "Lean Startup > Secrets Revealed." This video shows you how to validate your ideas, > optimize your ideas and identify your business strategy. > http://p.sf.net/sfu/appsumosfdev2dev > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Future Weather System
Hi, On Wednesday, July 13, 2011 02:16:29 Peter Sadrozinski wrote: > You mentioned earlier that a lot of the performance issues would disappear > if we could probe the terrain 100 times faster. I've been thinking about > this for a while for ai traffic, skyop's moving map instrument, and > weather. > > I'm thinking of storing some resolution of altitude data in the tile > itself, making altitude queries very fast at the expense of a larger tile > (in memory and disk). > > I'm just starting the work, but I would like any feedback on the idea. It > may require some lod implementation if the base tile size gets too big. > I've been thinking about trying to get osg paged lod working with a new sg > bucket. While being able to do a croase ground query on such a kind of regular grid might be beneficial for the weather module. I would prefer the ai module just using the already available bounding volume tree that is used for the main aircrafts elevation queries. This is already really fast. Also, may be making use of these bounding volume hierarchies for the weather module as an intermediate step might be a good idea? Greetings Mathias -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG 2.4 consistency
On Wed, 2011-07-13 at 15:24 +0200, grth_team wrote: > FG 2.4 consistency. > > Hello, > > You don't know us since we are newbee, (3 months working seriously > with FG). > We are a team ( 4 guys and a lady ). > > We have had several talks with several devel team persons about a > Catalina model update. > > That update has been rejected arguing that everything is frozen until > FG 2.4 will be freed, considered consistent, without any bug. It's not so much rejected, but declined to be included in GIT. The current release process is quite new to all of us so there might come up some unforeseen problems. Clearly this is one of them. It's unfortunate since you've put so much work in it, but then remember; so have all of use (or at least the great majority has). Judging from this email it wasn't the intention just to drop your efforts with the flip of a switch but it just happens to be bad timing; if you could have offered it three weeks ago everything would have been fine. You are free to offer the model on your own (many aircraft developers to this for one reason or another) and I for one am pleased to see others to step up to improve upon our current aircraft. So I would advise to try to get it included just after the new release and then when the 2.6 release is in feature freeze you could still get bug fixes included (which are probably minor compared to a complete overhaul). > To please to the users, our model will be ever checked against an FG > stable version. > We will start that rule with FG 2.4, offering our models within our > pages, but, under an other license. I have tot state that it is not allowed to change the license unless: * everything you use is your own work * or you're moving to a more restrictive license that is still open source (which is hard in case of the GPL). Erik -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
