Welcome to Fractal Forums

I am worry that there is a problem with the random aux. lights in the win-version.

I've tested the "tglad - scale 2 - cloured lights" file:

Linux (Ubuntu, Virtual Box): No Problems

WinXP (32bit), 2GB Ram, Athlon64-X2  4200+: When I set the number of aux. lights to 5 or more the same testfile renders a total different result: the Mandelbox gets totaly white.

Only when i set aux.lights to 0 - 4 (and the 4 predefined lights are enabled) the mandelbox looks ok.
If I disable the predefined lights and/or increase the number of aux.lights, the result is the same, a white Mandelbox.

(Sorry for english)

---------------
HEITER WEITER,

SaM

I also have this problem, running Win7x64 - either that, or I'm not doing something right??  Hopefully the User guide can get updated so we have a little more idea of how the new parameters are supposed to function...

Here are the 2 pics. Absolut same parameters from "tglad - scale 2 - coloured lights" (only set the aux-lights to 6):

Linux:

(http://no2israel.de/linux_tglad2_6_aux.jpg)


Same parameters, winXP32bit:

(http://no2israel.de/winxp_tglad2_6_aux.jpg)


I've found something in the program-output what can be acountable for the problem (?). The coordinates for light-positions are not the same :

Here are the output from linux:

3: Number of lights = 6
Light no. 0: x=-4,612079, y=-1,626779, z=-0,812399, distance=0,000319
Light no. 1: x=0,890161, y=-3,584340, z=-6,059460, distance=0,017740
Light no. 2: x=-0,845340, y=-2,386559, z=3,520200, distance=0,000000
Light no. 3: x=2,136060, y=2,688840, z=4,807801, distance=0,008595
Light no. 4: x=-5,934660, y=3,267241, z=1,146240, distance=0,000000
Light no. 5: x=6,120000, y=2,231221, z=-4,945079, distance=0,039788


And here the output for winXP:

3: Number of lights = 6
Light no. 0: x=-59,445180, y=-58,968600, z=-59,065440, distance=30,266583
Light no. 1: x=-58,992480, y=-58,617480, z=-58,405560, distance=29,989387
Light no. 2: x=-58,805640, y=-58,585500, z=-59,187060, distance=30,095997
Light no. 3: x=-58,782360, y=-58,588380, z=-58,567680, distance=29,974514
Light no. 4: x=-58,212360, y=-58,533060, z=-59,025120, distance=29,943263
Light no. 5: x=-58,301460, y=-58,424340, z=-59,739900, distance=30,076629


Completly different.

Yup, that's exactly what I get also.

Maybe I did something wrong with the source code or the source code published doesn't correspond to the latest linux version. The only modification I did was replacing exp10(x) function with pow(10,x). I'll try to see where is the problem. Perhaps the pseudo random function is different in win32.

Thank you for bug report. I will check it tomorrow

I checked this on my Windows also and I confirmed that there is probrem with random number generator. In my program I used rand() function from stdlib.h. There is difference in implementation of this function between Windows and Linux. In Linux rand() generates values up to 2147483647 but in Windows only up to 32767 (Windows still has some 16-bit parts :D ). There are two ways to solve this

1. in stdlib.h there is definition:
Please try to change this to 2147483647.

2. In common_math.cpp there is definition of function Random(int max)
It could be changed to:

Knighty, if you can please check this. If it will works I will correct this in program and send you updated source with other fixes (I solved problem with loading settings files created in older versions of Mandelbulber).

I will, ASAP :)

Thanks guys - I'd really like to try out the new lighting parameters!

Maybe too late to change it now, given that it would affect some current parameter files, but I'd recommend implimenting your own random() using a version of the "Mersenne Twister" instead of using rand() because rand() is statistically not very random :)
When I changed my old (very old) IFS code (included in a private version of MMFrac) switching to the Mersenne Twister instead of the other randoms I tried made the chaos game method siginificantly better i.e. much more even rendering than any other random method (when the probabilities where set at the correct values for even rendering).

I second the advice. Randomness should not be left to chance. :)

Stdlib's rand() is very bad, random() is newer and often better, but the quality of its implementation is platform dependent (i.e. no guarantee that it is actually better than rand()). The Mersenne Twister algorithm has a very good reputation for simulations. It is efficient and delivers good randomness even if you need large quantities of random bits.

For a multi-platform application, implementing your own custom random number generator has the additional benefit that it produces consistent results across all different machines (well, with a bit of care).