forked from bartvdbraak/blender
016e75ad64
Two fixes here (only the second one is strictly needed to fix the issue, but both make the system better). First is introduction of a random generator array for use with threaded systems where each thread needs to access its own number generator. The random texture now uses this so it should not be influenced by other random generator reseedings of the main random generator like it did before. Second, I reshuffled the texture code to resample the upper bits of the random number first. According to Numerical Recipes, this is where the most variance can be found, so by sampling those we avoid correlation issues. Also, multiplying here is not ideal because if a pair of bits are zero, then the whole result will also be zero. Overall this is much more random (tm) than before, however result will also be brighter, since we now have less black spots. Tweaking the brightness/contrast should somewhat fix that, generally having the same result as before is not possible anyway if we are to really fix this. Also, seems like exposing procedural depth might be nice here since it influences the precision of the texture lookup. |
||
|---|---|---|
| .. | ||
| blender.map | ||
| buildinfo.c | ||
| CMakeLists.txt | ||
| creator_launch_win.c | ||
| creator.c | ||
| osx_locals.map | ||