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
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
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 relea
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.
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
> reliab
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 w
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 F
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
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
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 roun
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
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
> > recollectio
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
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
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
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
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 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 sam
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,
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
> >
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 pa
> 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
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
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
--
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'
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/modelb
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,
Ma
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
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
29 matches
Mail list logo
