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 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 <path> elements
> defined under the <object> 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 <path>
> 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 <path> 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
