Re: [Flightgear-devel] materials.xml request

[Stuart B. <stu...@ya...>]

Tim Moore wrote:
>On Sun, Jan 31, 2010 at 8:07 PM, Erik Hofman <er...@eh...> 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().

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