Welcome to Fractal Forums

Mandelbulber 1.061 - for Linux x86, Linux x64, Win32, Win64 and MacOS

Open source program (GNU GPL) for rendering photo-realistic 3D fractals

Free download: http://sourceforge.net/projects/mandelbulber/
Website: http://sites.google.com/site/mandelbulber/
User manual: http://sites.google.com/site/mandelbulber/user-manual
Tutorial for creating animations: http://sites.google.com/site/mandelbulber/getting-started

New features in version 1.061:
- 64-bit version for Windows Vista and Windows 7. Possible to render images in unlimited resolution (e.g. 16000x16000 on 4GB RAM in -lowmem mode)
notes: 64-bit version is based on experimental GTK+ libraries. There is also visible some speed difference between 32 and 64 bit versions. Sometimes it works slower when there is used pow() function in fractal formula (some bug in IEEE floating point implementation). However it is possible to install both (32 and 64 bit) versions on the same system. Program tested on Vista 64-bit.
- fixed bug: program didn't work properly in -lowmem mode
- fixed bug: program crashed during displaying previews in Load Settings window
- fixed bug: eliminated many uninitialized variables (now the program should be more stable)

SVN repository: http://mandelbulber.googlecode.com/svn/trunk/
This repository is available from Google Code: http://code.google.com/p/mandelbulber/

My gallery with images created using Mandelbulber: http://krzysztofmarczak.deviantart.com/gallery/

Has anybody tested it? Any positive or negative feedback is mostly appreciated. I'm curious how this 64-bit version is working in your computers.

I don't know if this is specific to 1.061, but it doesn't appear to be saving keyframes properly. if I set a few keyframes, close the program, and reopen, the keyframes revert to the default fractal.

normally it shouldn't. but it reverts the ftractal type, the colors and the environmental paths to default. the easiest way to avoid: just open one of your keyframes regularily as parameter (in folder "keyframes". normally nr. 0000 makes most sense). then the animation should behave as expected.

There must be something wrong. I will check it.

if this is really a bug, it's an older one. i've been animating for three months now and it has allways been like that. on prog start all not animatable parameters are resetted to default including the "frames per key" and start and end frame - when you load a parameter the settings of this parameter are used for animation.
especially the file paths, the frames per key and the start and end frame i need to do so, as i store various different setups in different keyframe parameters (incl. the place to store the images). eg the preview settings in keyframe0000.fract and the 480p settings in keyframe0001.fract and so on. imho you could keep this "bug" :ok:

taurus

This is more general purpose feedback (I don't have 64-bit version of Windows) but here are my thoughts and suggestions:

- I think there should be a button to reset all vectors in the IFS tab, it's annoying to select each number and type 0 every time.
- Will the user manual eventually have a more thorough explanation of how the IFS works in Mandelbulber? I still don't quite get what's going on and usually I just type random numbers until something interesting comes up.
- Random palette generator in shaders tab only produces saturated colours. It would be nice to get more faded, greyish colours sometimes.
- An idea: presets for the shaders tab that make the fractal surface look like it's made of e.g. metal, or plastic, or varnished wood and maybe more.
- Long term thing: ability to customize all fractals in as much detail as the Mandelbox?

edit: some way of dealing with floating point rounding errors in variables would be nice, it's annoying seeing 0.1999999999999999999998 instead of 0.2 or whatever. Just rounding to one less digit than what's kept in memory might do the job, but I'm not a programmer so there's probably a better solution.

I have tested it and averything works all right on Linux and Windows (XP and Vista 64-bit). I think you are doing something wrong when you setup the animation. Please read following page: https://sites.google.com/site/mandelbulber/getting-started#TOC-Initial-setup
If you do everything exactly like it is described and this still not work please don't hesitate to ask again.

Running on a Win7 64 w/12GB RAM, I ran mandelbulber -lowmem to be able to make really large images

After ~25 hours rendering a 36000x27000 image, Mandelbulber crashed on completion.

"
Average N = 134,030943, Average DE steps = 8723,505382, Failed DE = 288696711%
Done 100,000%, to go = 0h0m0s, elapsed = 24h48m53s, iters/s = 210429661
Rendering Screen Space Ambient Occlusion. Done 100%
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
"


Here follows the last entries in the log:
"
89473947: Image redrawn in window
89473948: Image refreshed, value = 41,129
89630640: Thread finished, value = 10
89632935: Thread finished, value = 0
89634416: Thread finished, value = 4
89638338: Thread finished, value = 5
89638840: Thread finished, value = 6
89642955: Thread finished, value = 8
89644311: Thread finished, value = 1
89644938: Thread finished, value = 9
89647185: Thread finished, value = 2
89649152: Thread finished, value = 7
89653175: Thread finished, value = 11
89653175: Thread finish confirmed, value = 0
89653176: Thread finish confirmed, value = 1
89653177: Thread finish confirmed, value = 2
89656557: Thread finished, value = 3
89656559: Thread finish confirmed, value = 3
89656560: Thread finish confirmed, value = 4
89656560: Thread finish confirmed, value = 5
89656561: Thread finish confirmed, value = 6
89656562: Thread finish confirmed, value = 7
89656562: Thread finish confirmed, value = 8
89656563: Thread finish confirmed, value = 9
89656564: Thread finish confirmed, value = 10
89656564: Thread finish confirmed, value = 11
90744696: SSAO rendered
90744700: Image compiled
90745157: Lights rendered
90929370: Image converted to 8-bit
90950615: Preview created
90950724: Histograms refreshed
90950731: Image redrawn in window
90950863: Image rendered
"

So, looks like it ran out of memory despite -lowmem, but on completion rather than on start.

And yes, this is 1.061, and no, no image was recovered :-/

And I was rendering in keyframe mode, (having found an image I liked in a series, I deleted the original and turned on render from keyframes to rebuild it in 36000x27000))

Would be great if you could look into this - I really want a few wall-size images :-)

Thank you about this feedback. It looks like image was rendered properly but crashed during saving of image. What image format did you used. Was it JPG? I have to find where is the limitation. From my calculation total image size in memory was about 12GB, and raw image data (for final 8-bit image) was about 2.9 GB of memory.

i'm not sure wether we talk about the same thing, but i agree: everything works allright!

The image format I used was PNG 16bit + alpha

Thanks :-)

I've found the problem, I wasn't saving my settings before creating the first keyframe, I just assumed it would save everything in there.

Is this something that can be changed? It feels like the intuitive behavior would be to "just work". Is there a reason you can't save a full set of settings with each keyframe?

I have made a lot of difficult tests on my computers. Difficult, because I have tested rendering of 32000x27000 image (12GB) on my computer with 4GB of RAM. I haven't found any limitations on my computer. But all of tests I have made under Linux, because it have more efficient virtual memory management (Windows worked horribly slow). On Windows Mandelbulber uses almost the same libraries like on Linux, so there should be no difference in behavior. I have two ideas what could happen:
1) Saving in PNG 16bit + alpha format needs a lot of additional memory, because it is untypical image format. In your case it consumed additional 6,5 GB of system memory. As you wrote you have installed 12GB of memory. Image data has taken 11,4 GB + 6,45 GB for PNG = 17,85 GB. It is possible that you have too small maximum size of pagefile on your system, and that's why there was memory allocation error. Did you have some reason to use this image format with alpha channel? Other formats doesn't need additional memory. Furthermore, PNG16+Alpha sometimes works not so well with some special effects. This should be used only when you want to exchange image background using some other program.
2) Windows version of libpng could has some unidentified limitations, which I can't test now because of not enough amount of memory in my computer. Many 64-bit libraries for Windows are still in experimental phase.

It's like creating of project. If you want to create many animations, you have to have some possibility to store all keyframes, image frames, backgrounds in separate folders for each project. That's why you have to save parameters of animation in settings file. This settings file is your base project file. If you are loading keyframe, the program takes only from this parameters which can be animated (all floating point type parameters). On page: http://sites.google.com/site/mandelbulber/getting-started#TOC-Initial-setup , there is a list of all animated and non-animated parameters. I decided to make this in that way because of many reasons. For example, imagine what happen if you want to change, for instance, image resolution or background texture. If all parameters will be saved/loaded from keyframes, you have to change the same settings in each key-frame separately. Next thing is that the program wouldn't know what to do with parameters which can't be animated.
You wrote that "Is there a reason you can't save a full set of settings with each keyframe?". All parameters are saved in keyframe files. You can load it as a settings file.

That explanation makes sense, thanks