The RNG should be re-seeded for every generated random number anyway, because in general you cannot rely on a fixed order of calls. This seed is a combination (using a "double seed") of an element ID (so you get different numbers for each work item) and a user-defined constant.
However, the current method should work nicely for almost all cases. It just uses a rather large (2^16) array of precalculated, constant random numbers, so there is no risk of changing the result by switching threads between the seeding and generation (race condition). IIRC Jahka uses the same technique for particle randomization. On Thu, Nov 11, 2010 at 3:04 PM, Kent Mein <[email protected]> wrote: > > On Nov 11, 2010, at 3:19 AM, Lukas Toenne wrote: > >> Revision: 32998 >> >> http://projects.blender.org/plugins/scmsvn/viewcvs.php?view=rev&root=bf-blender&revision=32998 >> Author: lukastoenne >> Date: 2010-11-11 10:19:06 +0100 (Thu, 11 Nov 2010) >> >> Log Message: >> ----------- >> Replaced the use of BLI random functions in the "Random" node by a >> straightforward pseudo-random number generation based on randomized arrays. >> This is a thread-safe implementation (the arrays are constant), the >> disadvantage is that the static arrays (one for ints, one for floats) are >> rather large (65536 entries) and still have a much shorter period than >> "real" RNGs. An alternative would be using a separate RNG for each thread, >> but that requires passing thread info to kernel functions. >> > > Wouldn't having different RNG's per thread be bad for animation? > You would get different results depending on the order of your "parts" > rendered. > > Kent > > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
