Re: [Flightgear-devel] materials.xml request
On Monday 01 Feb 2010, Stuart Buchanan wrote: > leee wrote: > > On Sunday 31 Jan 2010, Erik Hofman wrote: > > > Stuart Buchanan wrote: > > > > It's been a long time since I (re-)wrote the random object > > > > code for OSG, but my recollection is that we use the same > > > > random number seed when generating random model placements, > > > > to ensure that a building is in the same place on every > > > > computer. > > > > > > Looks like that part is gone, at least the part where every > > > random object in the scenery was in the same place every time > > > you start up FlightGear. This used to be working at some > > > point (and could be used for landmark navigation). > > > > > > Erik > > > > It's a sad fact that much of which used to make FG extremely > > stable and consistant has been sacrificed to implement new > > features. > > > > Sorry folks, but all the new developments in FG, over the past > > few years, have come at the cost of stability and robustness. > > Codswallop :) > > This particular bug is in a feature that was introduced in > post-plib, and is not a regression, as you seem to be implying. > > As I recall, the plib code didn't even attempt to make random > object placement consistent across runs and I spent quite some > time with help from a number of people in putting together > something that provided that consistency. > > I remember the 0.9.8 and 0.9.9 releases all having issues, just > as the 1.9.1b has and 2.0.0 releases will have. People have > worked very hard to track down difficult bugs such as the NaN > issue and to ensure consistency when enhancing FG (e.g. the sound > system).. > > CVS has possibly become a little less stable, but I can't say > that I've noticed, and my understanding is that the release team > are working from a GIT branch of known-stable code to ensure that > we've got a stable release. > > Sniping from the side-lines has absolutely no value unless you're > prepared to roll up your sleeves, which you've stated you aren't. > > -Stuart In the past I was able to track down and fix a couple of minor code bugs, and add a couple of new filter types, but I simply don't have the C++ and OOP skills to delve more deeply into the code; it's not a question of not being "prepared to roll up my sleeves" but rather that to do so would just leave me standing around with cold arms. LeeE -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] materials.xml request
Gene Buckle wrote: > Here's a wild idea - once an object has been placed, why not record it's > position in a configuration file? This _might_ work for 'normal' random objects since there are not too many objects, but will end up in a _very_ long list if you're trying to achieve the same results for a dense forest ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] materials.xml request
On Mon, 1 Feb 2010, Erik Hofman wrote: > Tim Moore wrote: >> Since the bug is in model choice (not position), affects less than a >> third of the object definitions in materials.xml, and is being reported >> very late in our release process, I'm inclined to fix this in a 2.0.1 >> maintenance release. > > Another way to fix it is to use a round-robin method instead of using > random for model selection. This would probably be an easy fix. > This method is also used for multiple scenery textures. > Here's a wild idea - once an object has been placed, why not record it's position in a configuration file? That would ensure that no matter what, objects would be consistant from run to run, but people could share the configurations among themselves so when flying multi-player the objects would be in the same place for everyone that used that object position configuration file... g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] materials.xml request
Erik Hofman wrote: > Erik Hofman wrote: > >> Another way to fix it is to use a round-robin method instead of using > >> random for model selection. This would probably be an easy fix. > >> This method is also used for multiple scenery textures. > > > > Alright, this is committed to CVS for now. It is tested and works > > reliably. After the release we could discuss if this is the right > > approach or using random would be better. > > Ok, this turn out not to be perfect; > When starting at a different airport and then switching to KSFO (and > probably when flying around for some time and returning to KSFO) you > might find a different building at places then before. But at least > that's consistent (also between sessions). Thanks for sorting this out. I think the solution I proposed should resolve the remaining issues, and using lat/lon to inform the seeding process should create more pseudo-randomnes. I'll look into this in more detail once I have a working development machine. -Stuart -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] materials.xml request
Erik Hofman wrote: >> Another way to fix it is to use a round-robin method instead of using >> random for model selection. This would probably be an easy fix. >> This method is also used for multiple scenery textures. > > Alright, this is committed to CVS for now. It is tested and works > reliably. After the release we could discuss if this is the right > approach or using random would be better. Ok, this turn out not to be perfect; When starting at a different airport and then switching to KSFO (and probably when flying around for some time and returning to KSFO) you might find a different building at places then before. But at least that's consistent (also between sessions). Erik -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] materials.xml request
Erik Hofman wrote: > Tim Moore wrote: >> Since the bug is in model choice (not position), affects less than a >> third of the object definitions in materials.xml, and is being reported >> very late in our release process, I'm inclined to fix this in a 2.0.1 >> maintenance release. > > Another way to fix it is to use a round-robin method instead of using > random for model selection. This would probably be an easy fix. > This method is also used for multiple scenery textures. Alright, this is committed to CVS for now. It is tested and works reliably. After the release we could discuss if this is the right approach or using random would be better. Erik -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] materials.xml request
Erik Hofman wrote: > Stuart Buchanan wrote: >> As I recall, the plib code didn't even attempt to make random object >> placement >> consistent across runs and I spent quite some time with help from a number >> of people in putting together something that provided that consistency. > > Actually FlightGear did this already for a very long time. I know > because I started the discussion about it back then. looking at the code: mt_init(&seed, unsigned(123)); Note that back then first I used a random seed of lat*36000+lon*100 (or vice versa) of the tile center as a seed, making each tile more random. Erik -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] materials.xml request
Tim Moore wrote: > Since the bug is in model choice (not position), affects less > than a third of the object definitions in materials.xml, and is > being reported very late in our release process, I'm inclined > to fix this in a 2.0.1 maintenance release. As I'm out of the loop concerning the release date, and any plan for a follow-up maintenance release I'm more than happy to leave this to your judgement. -Stuart -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] materials.xml request
Stuart Buchanan wrote: > As I recall, the plib code didn't even attempt to make random object placement > consistent across runs and I spent quite some time with help from a number > of people in putting together something that provided that consistency. Actually FlightGear did this already for a very long time. I know because I started the discussion about it back then. Erik -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] materials.xml request
Tim Moore wrote: > Since the bug is in model choice (not position), affects less than a > third of the object definitions in materials.xml, and is being reported > very late in our release process, I'm inclined to fix this in a 2.0.1 > maintenance release. Another way to fix it is to use a round-robin method instead of using random for model selection. This would probably be an easy fix. This method is also used for multiple scenery textures. Erik -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] materials.xml request
leee wrote: > On Sunday 31 Jan 2010, Erik Hofman wrote: > > Stuart Buchanan wrote: > > > It's been a long time since I (re-)wrote the random object code > > > for OSG, but my recollection is that we use the same random > > > number seed when generating random model placements, to ensure > > > that a building is in the same place on every computer. > > > > Looks like that part is gone, at least the part where every > > random object in the scenery was in the same place every time you > > start up FlightGear. This used to be working at some point (and > > could be used for landmark navigation). > > > > Erik > > It's a sad fact that much of which used to make FG extremely stable > and consistant has been sacrificed to implement new features. > > Sorry folks, but all the new developments in FG, over the past few > years, have come at the cost of stability and robustness. Codswallop :) This particular bug is in a feature that was introduced in post-plib, and is not a regression, as you seem to be implying. As I recall, the plib code didn't even attempt to make random object placement consistent across runs and I spent quite some time with help from a number of people in putting together something that provided that consistency. I remember the 0.9.8 and 0.9.9 releases all having issues, just as the 1.9.1b has and 2.0.0 releases will have. People have worked very hard to track down difficult bugs such as the NaN issue and to ensure consistency when enhancing FG (e.g. the sound system).. CVS has possibly become a little less stable, but I can't say that I've noticed, and my understanding is that the release team are working from a GIT branch of known-stable code to ensure that we've got a stable release. Sniping from the side-lines has absolutely no value unless you're prepared to roll up your sleeves, which you've stated you aren't. -Stuart -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] materials.xml request
On Mon, Feb 1, 2010 at 9:04 AM, Stuart Buchanan < stuart_d_bucha...@yahoo.co.uk> wrote: > Tim Moore wrote: > >On Sun, Jan 31, 2010 at 8:07 PM, Erik Hofman wrote: > >Stuart Buchanan wrote: > > It's been a long time since I (re-)wrote the random object code for > OSG, but my > > recollection is that we use the same random number seed when > generating > > random model placements, to ensure that a building is in the same > place on > > every computer. > >> > >>Looks like that part is gone, at least the part where every random > object in the scenery was in the same place every time you start up > FlightGear. This used to be working at some point (and could be used > for > landmark navigation). > >> > >> > >I'm a bit confused. Are random objects actually starting up at different > points in each run > > now? I haven't noticed that nor have I seen a report of that. All I've > seen in this thread is > > that the code that resets the random generator in each tile (well, > several times per tile) > > may be affecting the "random" distribution of some models. > > I managed to do a couple of test-flights to validate Erik's bug report > without crashing my GPU. > The problem appears to be limited to the case where there are multiple > object elements > defined under the node. In this case, the actual object placed at > a given location varies > from run to run. The effect can be quite subtle because the position of the > object (and any trees) stay > the same, and a lot of our object definitions only have a single > element so you often don't > see the bug for large objects. > > >From a code read I think the problem is that we don't actually define the > specific element > to use in obj.cxx, but it gets selected later in > SGMatModel::get_random_model(), which still uses > sg_random() rather than the mt_rand(&seed) code used elsewhere. This in > turn is called by > sgGetRandomModel(), which is called by SGLoadBTG(). > > I was wondering about that while looking at the code last night. > So, I think the fix is for SGLoadBTG() to pass the seed generated at > obj.cxx line 606 down through > sgGetRandomModel() and for get_random_model() to use a call to > mt_rand(&seed) rather than > sg_random() to determine the actual model to generate. > > The mt_rand code generates the same set of pseudo-random numbers across > runs (and I believe computers) > > Apologies again that I can't fix this myself right now, but hopefully that > should fix the problem in time for > the release. > Since the bug is in model choice (not position), affects less than a third of the object definitions in materials.xml, and is being reported very late in our release process, I'm inclined to fix this in a 2.0.1 maintenance release. Tim -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] materials.xml request
Stuart Buchanan wrote: > I managed to do a couple of test-flights to validate Erik's bug report > without crashing my GPU. > The problem appears to be limited to the case where there are multiple object > elements > defined under the node. In this case, the actual object placed at a > given location varies > from run to run. The effect can be quite subtle because the position of the > object (and any trees) stay > the same, and a lot of our object definitions only have a single > element so you often don't > see the bug for large objects. Indeed that was also my conclusion. Erik -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] materials.xml request
Tim Moore wrote: >On Sun, Jan 31, 2010 at 8:07 PM, Erik Hofman wrote: >Stuart Buchanan wrote: > It's been a long time since I (re-)wrote the random object code for OSG, > but my > recollection is that we use the same random number seed when generating > random model placements, to ensure that a building is in the same place on > every computer. >> >>Looks like that part is gone, at least the part where every random object in the scenery was in the same place every time you start up FlightGear. This used to be working at some point (and could be used for landmark navigation). >> >> >I'm a bit confused. Are random objects actually starting up at different >points in each run > now? I haven't noticed that nor have I seen a report of that. All I've seen > in this thread is > that the code that resets the random generator in each tile (well, several > times per tile) > may be affecting the "random" distribution of some models. I managed to do a couple of test-flights to validate Erik's bug report without crashing my GPU. The problem appears to be limited to the case where there are multiple object elements defined under the node. In this case, the actual object placed at a given location varies from run to run. The effect can be quite subtle because the position of the object (and any trees) stay the same, and a lot of our object definitions only have a single element so you often don't see the bug for large objects. >From a code read I think the problem is that we don't actually define the >specific element to use in obj.cxx, but it gets selected later in SGMatModel::get_random_model(), which still uses sg_random() rather than the mt_rand(&seed) code used elsewhere. This in turn is called by sgGetRandomModel(), which is called by SGLoadBTG(). So, I think the fix is for SGLoadBTG() to pass the seed generated at obj.cxx line 606 down through sgGetRandomModel() and for get_random_model() to use a call to mt_rand(&seed) rather than sg_random() to determine the actual model to generate. The mt_rand code generates the same set of pseudo-random numbers across runs (and I believe computers) Apologies again that I can't fix this myself right now, but hopefully that should fix the problem in time for the release. -Stuart -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [FlightGear-devel] materials.xml request
J. Holden wrote: >> I'm a bit confused. Are random objects actually starting up at different > points in each run now? I haven't noticed that nor have I seen a report of > that. All I've seen in this thread is that the code that resets the random > generator in each tile (well, several times per tile) may be affecting the > "random" distribution of some models. > > I have not seen anything proving this is broken (did a couple test flights), > can someone please independently verify that this code is indeed broken? Hm, I did e few tests myself yesterday. I'll try to do a few more to check. Erik -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [FlightGear-devel] materials.xml request
> I'm a bit confused. Are random objects actually starting up at different points in each run now? I haven't noticed that nor have I seen a report of that. All I've seen in this thread is that the code that resets the random generator in each tile (well, several times per tile) may be affecting the "random" distribution of some models. I have not seen anything proving this is broken (did a couple test flights), can someone please independently verify that this code is indeed broken? Cheers John -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] materials.xml request
On 31.1.2010 22:13, LeeE wrote > On Sunday 31 Jan 2010, Erik Hofman wrote: > >> > Stuart Buchanan wrote: >> >>> > > It's been a long time since I (re-)wrote the random object code >>> > > for OSG, but my recollection is that we use the same random >>> > > number seed when generating random model placements, to ensure >>> > > that a building is in the same place on every computer. >>> >> > >> > Looks like that part is gone, at least the part where every >> > random object in the scenery was in the same place every time you >> > start up FlightGear. This used to be working at some point (and >> > could be used for landmark navigation). >> > >> > Erik >> > > It's a sad fact that much of which used to make FG extremely stable > and consistant has been sacrificed to implement new features. > > Sorry folks, but all the new developments in FG, over the past few > years, have come at the cost of stability and robustness. What has > stopped me from contributing to FG has been a combination of > unaddressed show-stopping bugs, a reliance upon non-standard > dependencies, all topped off with an obsolete architecture. > > Having said that, I'm not trying to criticise anyone; I remember > Curt remarking on more than one occasion that trying to coordinate > FG development was like trying to heard cats, but FG long ago > became bigger than any of its contributors. It seems to me that > perhaps part of the the problem is that not all of the contributors > to FG realise that. > > LeeE > > > That is my impression too. ThorX -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] materials.xml request
On Sun, Jan 31, 2010 at 8:07 PM, Erik Hofman wrote: > Stuart Buchanan wrote: > > It's been a long time since I (re-)wrote the random object code for OSG, > but my > > recollection is that we use the same random number seed when generating > > random model placements, to ensure that a building is in the same place > on > > every computer. > > Looks like that part is gone, at least the part where every random > object in the scenery was in the same place every time you start up > FlightGear. This used to be working at some point (and could be used for > landmark navigation). > > I'm a bit confused. Are random objects actually starting up at different points in each run now? I haven't noticed that nor have I seen a report of that. All I've seen in this thread is that the code that resets the random generator in each tile (well, several times per tile) may be affecting the "random" distribution of some models. Tim > Erik > > > -- > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the > business > Choose flexible plans and management services without long-term contracts > Personal 24x7 support from experience hosting pros just a phone call away. > http://p.sf.net/sfu/theplanet-com > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] materials.xml request
Loosing this permanence of random object placement would be a bummer for anyone who is driving multiple displays from multiple computers. That's maybe a small segment of our user base, but it's these higher end "professional" users that often have budgets they are working with. Regards, Curt. On Sun, Jan 31, 2010 at 1:41 PM, Stuart Buchanan wrote: > Erik Hofman wrote: > > > Stuart Buchanan wrote: > > > It's been a long time since I (re-)wrote the random object code for > OSG, but > > my > > > recollection is that we use the same random number seed when generating > > > random model placements, to ensure that a building is in the same place > on > > > every computer. > > > > Looks like that part is gone, at least the part where every random > > object in the scenery was in the same place every time you start up > > FlightGear. This used to be working at some point (and could be used for > > landmark navigation). > > Hmmm, I've had a quick look at the code in question > (simgear/scene/tgdb/odj.cxx > computeRandomObjects), and it doesn't look like it has changed since I > wrote it, so > I'm surprised it no-longer works. > > Unfortunately I can't test this at present as my graphics card is kaput. > That isn't going > to be resolved for a couple of weeks, so if someone wants to take a look, > they are > welcome. > > Sorry I can't be of more help, or maintain my own code in a timely manner > at present. > > -Stuart > > > > > > > -- > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the > business > Choose flexible plans and management services without long-term contracts > Personal 24x7 support from experience hosting pros just a phone call away. > http://p.sf.net/sfu/theplanet-com > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Curtis Olson: http://baron.flightgear.org/~curt/ -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] materials.xml request
On Sunday 31 Jan 2010, Erik Hofman wrote: > Stuart Buchanan wrote: > > It's been a long time since I (re-)wrote the random object code > > for OSG, but my recollection is that we use the same random > > number seed when generating random model placements, to ensure > > that a building is in the same place on every computer. > > Looks like that part is gone, at least the part where every > random object in the scenery was in the same place every time you > start up FlightGear. This used to be working at some point (and > could be used for landmark navigation). > > Erik It's a sad fact that much of which used to make FG extremely stable and consistant has been sacrificed to implement new features. Sorry folks, but all the new developments in FG, over the past few years, have come at the cost of stability and robustness. What has stopped me from contributing to FG has been a combination of unaddressed show-stopping bugs, a reliance upon non-standard dependencies, all topped off with an obsolete architecture. Having said that, I'm not trying to criticise anyone; I remember Curt remarking on more than one occasion that trying to coordinate FG development was like trying to heard cats, but FG long ago became bigger than any of its contributors. It seems to me that perhaps part of the the problem is that not all of the contributors to FG realise that. LeeE -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] materials.xml request
Stuart Buchanan wrote: > Erik Hofman wrote: >> Looks like that part is gone, at least the part where every random >> object in the scenery was in the same place every time you start up >> FlightGear. This used to be working at some point (and could be used for >> landmark navigation). > > Hmmm, I've had a quick look at the code in question > (simgear/scene/tgdb/odj.cxx > computeRandomObjects), and it doesn't look like it has changed since I wrote > it, so > I'm surprised it no-longer works. > > Unfortunately I can't test this at present as my graphics card is kaput. That > isn't going > to be resolved for a couple of weeks, so if someone wants to take a look, > they are > welcome. > > Sorry I can't be of more help, or maintain my own code in a timely manner at > present. Oh, it's not a show stopper but it was a feature I found to be one of the nice things about FlightGear. Maybe I will take a look at it some time. Erik -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] materials.xml request
Erik Hofman wrote: > Stuart Buchanan wrote: > > It's been a long time since I (re-)wrote the random object code for OSG, > > but > my > > recollection is that we use the same random number seed when generating > > random model placements, to ensure that a building is in the same place on > > every computer. > > Looks like that part is gone, at least the part where every random > object in the scenery was in the same place every time you start up > FlightGear. This used to be working at some point (and could be used for > landmark navigation). Hmmm, I've had a quick look at the code in question (simgear/scene/tgdb/odj.cxx computeRandomObjects), and it doesn't look like it has changed since I wrote it, so I'm surprised it no-longer works. Unfortunately I can't test this at present as my graphics card is kaput. That isn't going to be resolved for a couple of weeks, so if someone wants to take a look, they are welcome. Sorry I can't be of more help, or maintain my own code in a timely manner at present. -Stuart -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] materials.xml request
Stuart Buchanan wrote: > It's been a long time since I (re-)wrote the random object code for OSG, but > my > recollection is that we use the same random number seed when generating > random model placements, to ensure that a building is in the same place on > every computer. Looks like that part is gone, at least the part where every random object in the scenery was in the same place every time you start up FlightGear. This used to be working at some point (and could be used for landmark navigation). Erik -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] materials.xml request
> It's been a long time since I (re-)wrote the random object code for OSG, but > my > recollection is that we use the same random number seed when generating random model placements, to ensure that a building is in the same place on > every computer. > I suspect that part of the problem with the water-tower may be an artifact of > the > random number generator, though having one every 300,000 m^2 was also a bit much! > However, I've never investigated sufficiently to determine if that > is the case. Stuart: What happened is that towns are usually defined as points, which get interpreted by the scenery-generation system as the landcover type "town". Back when the water tower was first implemented, towns were turned into squares about 1km on a side and there was one water tower per town. As myself and others have improved on the quality of the scenery, these "towns" went from small squares with one church, water tower, house, etc to much larger expanses with many churches, water towers, et cetera. I like those shared German and Dominicaian houses in the shared model directory for town autogen... perhaps those could be substituted in the water tower's wake? However, I don't have cvs privileges... has someone stepped up to the plate and fixed this yet? Cheers John -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] materials.xml request
I was wondering what those giant mushrooms were :P -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] materials.xml request
One airport in BC has a water tower directly at the end of the runway , (after Ifixed the scenery) ..and I discovered they are solid :) . Even one tower per town seems a bit much , I haven't seen anything quite like it in real life. Cheers -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] materials.xml request
J. Holden wrote: > I don't know if we've gone final with everything yet, but if we haven't, > would > it be possible for somebody here to: > * double-check to see if the "mushroom" water-towers still exist under the > town > definition in materials.xml; and, if so, > * remove them. > > As we'll have a lot more areas defined as "town" in the upcoming scenery > build, > and there are far too many water towers per square > land-area-measurement-category) in FG as it is, and it looks tacky. After the > release, I'll try and look at improving the randomly generated scenery. It's been a long time since I (re-)wrote the random object code for OSG, but my recollection is that we use the same random number seed when generating random model placements, to ensure that a building is in the same place on every computer. I suspect that part of the problem with the water-tower may be an artifact of the random number generator, though having one every 300,000 m^2 was also a bit much! However, I've never investigated sufficiently to determine if that is the case. -Stuart -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] materials.xml request
Martin Spott wrote: > Hi Erik, > > Erik Hofman wrote: > >> It would also be nice to have some more different small(ish) buildings. > > Feel invited to have a look at the "Models/Residential/" folder, there > you'll find the content of this chapter: > > http://scenemodels.flightgear.org/modelbrowser.php?shared=2 Nice, I've reorganized the town section a bit with this in mind. Thanks! Erik -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] materials.xml request
Hi Erik, Erik Hofman wrote: > It would also be nice to have some more different small(ish) buildings. Feel invited to have a look at the "Models/Residential/" folder, there you'll find the content of this chapter: http://scenemodels.flightgear.org/modelbrowser.php?shared=2 Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] materials.xml request
J. Holden wrote: > As we'll have a lot more areas defined as "town" in the upcoming scenery > build, and there are far too many water towers per square > land-area-measurement-category) in FG as it is, and it looks tacky. After the > release, I'll try and look at improving the randomly generated scenery. It would also be nice to have some more different small(ish) buildings. Erik -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] materials.xml request
On Tuesday 26 January 2010 04:09:15 J. Holden wrote: > I don't know if we've gone final with everything yet, but if we haven't, > would it be possible for somebody here to: * double-check to see if the > "mushroom" water-towers still exist under the town definition in > materials.xml; and, if so, * remove them. > As we'll have a lot more areas defined as "town" in the upcoming scenery > build, and there are far too many water towers per square > land-area-measurement-category) in FG as it is, and it looks tacky. Actually this is something I strongly agree with - I have never seen any part of the world so heavily populated with ugly water towers as every minor village appears to be in FG. They spoil the scenery so much that for years I've made sure the water tower model here is replaced by something more appropriate and less visually offensive (like a church or house). Cheers, AJ -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] materials.xml request
I don't know if we've gone final with everything yet, but if we haven't, would it be possible for somebody here to: * double-check to see if the "mushroom" water-towers still exist under the town definition in materials.xml; and, if so, * remove them. As we'll have a lot more areas defined as "town" in the upcoming scenery build, and there are far too many water towers per square land-area-measurement-category) in FG as it is, and it looks tacky. After the release, I'll try and look at improving the randomly generated scenery. Cheers John -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
