Tim Moore wrote:
On Sun, Jan 31, 2010 at 8:07 PM, Erik Hofman e...@ehofman.com 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
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
path elements
defined under the object node. In this case, the actual object placed at a
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 e...@ehofman.com wrote:
Stuart Buchanan wrote:
It's been a long time since I (re-)wrote the random object code for
OSG, but my
recollection
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
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
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.
As I'm out of the loop concerning the
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
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
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.
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
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 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
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
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
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
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
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 8:07 PM, Erik Hofman e...@ehofman.com 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
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
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)
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, *
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
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 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:
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
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
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
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 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
30 matches
Mail list logo
