Title: Mandelbulber 0.94 Post by: Buddhi on October 16, 2010, 07:38:21 PM Mandelbulber 0.94 - for Linux x86, Linux x64 and also for Win32
Open source program (GNU GPL) for rendering photo-realistic 3D fractals Free download: http://sourceforge.net/projects/mandelbulber/ New features in version 0.94: - Added lowMem mode. When active, the program uses about 3 times less memory. Possible to render much larger images on 32-bit systems (8000x8000 on WinXp 32-bit, 15000x15000 on Linux64-bit with 4GB RAM). To activate it please start the program with -lowmem parameter. - Added Timeline window with keyframes thumbnails - Buttons "Record keyframe", "Next keyframe", "Previous keyframe" and edit field "Key no." moved into Timeline window - Added "Delete keyframe" function - Added "Insert keyframe" function - Keyframe can be selected and loaded (double click) from Timeline window - "Next keyframe" and "Previous keyframe" buttons also starts rendering. - Progressive rendering now is disabled in noGUI mode - Fixed bug: program crashed during stereo rendering in noGUI mode - Fixed bug: SSAO sometimes generates artifacts during progressive rendering - Fixed bug: images was dark in noGUI mode (colour palette was black) - Fixed bug: visible auxiliary lights in very high image resolution was rendered with visible square artifacts - Fixed bug: scale of visible auxiliary lights was not correct (size of lights wasn't proportional to square of distance) - Fixed bug: Program crashed when start_frame in keyframe mode was greater than zero - Fixed memory leaks and uninitialized variables - Source code: many changes in program structure. Now there is possible to simultaneous render two different fractals. Before first run please use install script 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/ Title: Re: Mandelbulber 0.94 Post by: fronclynne on October 17, 2010, 04:05:35 PM It compiles quite well, actually, on FreeBSD 8.1 amd64 here:
though I haven't really flogged yet. Thanks. (you probably have to use gmake, though) Title: Re: Mandelbulber 0.94 3d navigator bug Post by: jwm-art on October 17, 2010, 07:17:51 PM There's a bug with the 3d navigator when the step size value has been increased by the user.
The best way to witness the problem is to init the 3d navigator and then change the (default) step size from 0.5 to 1.5. Now alternate between pressing the move-camera-left button and the move-camera-right direction button for several iterations and watch the viewport x, y, and z values accumulate. Gentoo ~amd64, gcc 4.4.4, gtk2.20.1 btw, this bug was present in 0.93. cheers, James. Title: Re: Mandelbulber 0.94 Post by: Buddhi on October 17, 2010, 07:36:32 PM Hi
In default camera moving mode, movement distance equals to estimated_distance_to_the_fractal * step_for_camera_moving. After pressing "Init 3D navigator" button distance is 25. When you set step size to 1,5 and move camera right then camera will move by 25*1,5 distance. After movement distance to fractal is 40 and when you move camera again in left direction it will move by distance 40*1,5. camera will not return to the same position. It works in that way, because when you move camera closer to fractal, then movement step will be shorter. It automatically adapt precision of movement to distance from fractal. If you want to control movement distance by yourself, please switch on "Absolute distance mode". Now movement distance is fixed and defined in "Absolute movement distance". I hope this explanation helps you. Title: Re: Mandelbulber 0.94 Post by: jwm-art on October 17, 2010, 08:14:25 PM Oh :embarrass:
Title: Re: Mandelbulber 0.94 Post by: Russ McClay on October 18, 2010, 07:01:15 AM I know you're working hard on the latest version, but just wanted to report that the new Timeline UI in 0.94 is great. Recording, deleting and animating keyframes works fine under Windows 32-bit (XP and 7).
But, clicking on the Record key-frame button next to Render from key-frames on the Animation page, will still crash the program. Which is not a problem since I can use the Timeline. Thank you so much for Mandlebulber and your efforts to make this available! Russ Title: Re: Mandelbulber 0.94 Post by: kon16ov on October 18, 2010, 07:10:42 PM Howdy!
I've been kicking the tires, a bit, and wish that the internet hadn't gone AWOL at the CLEC, otherwise I could have gotten it up a little sooner... anyway, I've written down some observations. All were in lowmem mode. I *love* lowmem mode. I really like the progress in this app -- you're doing an excellent job. In this light, I'd like to give you some detailed items I ran into. Animation tab: clicked “record flight” then clicked “record keyframe” error: “(mandelbulber:7874): Gtk-CRITICAL **: gtk_entry_get_text: assertion `GTK_IS_ENTRY (entry)' failed ” Giant explosion #1: Timeline: clicked “record keyframe” while initial rendering produced segfault [2] 2nd attempt to replicate the bug, loaded timeline and clicked “record keyframe” recorded keyframe successfully. Keyframe image obscured by horizontal scroll bar and button sizes are very large, unlike the first time I tried. I loaded it, then clicked on “record keyframe” from animation tab; added successfully and an image was displayed for keyframe 1. The image was what keyframe 0 should have been, but keyframe 0 was blank. Likewise, adding keyframe 3 from animation tab added successfully, but, again, displayed what should have been keyframe 2. Recorded keyframe from timeline, then, which added successfully, but displayed keyframe 3 rather than 4. I then alt-tabbed over to write down my observations and it crashed: Rendering Screen Space Ambient Occlusion. Done 100% Code: *** glibc detected *** mandelbulber: corrupted double-linked list: 0x0a133488 *** Initial startup, Animation tab: nothing rendered yet; clicked “Record Keyframe” (mandelbulber:8474): Gtk-CRITICAL **: gtk_entry_get_text: assertion `GTK_IS_ENTRY (entry)' failed Segmentation fault In loading app back up, started rendering a polynom^2 and loaded Timeline. The buttons were all shaped properly and the keyframe display was correct. It was loading previous keyframes from before the crash. They were now displaying the correct image corresponding with the keyframes and deleted “old” keyframes properly. When recording new keyframe 0, it added properly and displayed what should be there. Clicked on render window to zoom in, then clicked on Timeline->record new while rendering was still completing. Took a couple of seconds longer than the first time (presumably because it had to render the tiny version), and added correctly with proper corresponding image. Clicked to zoom in, again, and allowed image to render completely. Modified the palette, though it did not show up as updated in render window, but when recording keyframe from Timeline, it updated the palette. After 5 total keyframes were recorded, went to Animation tab and selected “render from keyframes.” It went right to it, starting with a Trigonometric, not Polynomial Power 2 as set in the keyframes. Trig was selected in the main window after keyframe 1 was recorded, but subsequent zooms still kept to the Polynom^2, as originally selected. The palette was the one set in keyframe 5, as of first frame. If you want a screenshot of the behavior, I dropped it on my server. Here's the link: http://www.pmwdesigns.net/mandelbrot/screenshot.jpeg (http://www.pmwdesigns.net/mandelbrot/screenshot.jpeg) Hope this helps. I'll hopefully get more chance to run it through some paces later this week. Again, great program and keep up the good work! Phil Title: Re: Mandelbulber 0.94 Post by: Buddhi on October 18, 2010, 10:05:39 PM Thank you for detailed tests. Lowmem mode and Timeline window are completely things and there is a lot of bugs to fix. Every detailed information about errors is very helpful for me.
But please know that lowmem mode is only dedicated for rendering huge images prepared before in normal mode. It disables some memory structures inside program and disables postprocesing. In lowmem mode should work only rendering. Some bugs which I have to fix: - program crashes when "Record keyframe" button is pressed during Timeline initialization - program crashes when timeline window is closed and "Record keframe" button form Animation tab is clicked It is not bug but behavior of the program: - there can be only one color palette for whole animation. It is only possible to animate palette offset. To get proper color palette for rendered animation and also proper some other things, first you have to define all global options for animation (color palette, file paths, fractal formula type - all things which can't be animated) and save it to some settings file. Then prepare some keyframes. When you want to render the animation, first load this settings file and then press render animation. Generally program animates all floating point parameters. Nothing more. All not floating-point parameters are taken from actual setup (e.g. loaded before from settings file) and will be the same for whole animation. Title: Re: Mandelbulber 0.94 - happy quit patch Post by: jwm-art on October 19, 2010, 11:05:27 AM Hiya,
Here's a quick patch to stop the sigsegv on quit during a render. cheers, james. Title: Re: Mandelbulber 0.94 Post by: jwm-art on October 19, 2010, 12:25:23 PM Here is a better patch than the previous patch. This also fixes the problem with the progress bar (I believe).
Buddhi, if you look in the patch, you'll see I've removed a few unnecessary signal handlers for destroy event - this is because the GTK documentation says[1] destroy event is rare and usually it needs to be enabled on a window. In the previous patch, there was both delete_event and my new callback StopRenderingAndQuit. In this patch StopRenderingAndQuit is a replacement for delete_event as well as being used where gtk_main_quit was previously used as a callback (hope that makes sense). Actually, that return statement is the real reason why things like this were happening: Code: (mandelbulber:8769): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in cast to `GtkProgressBar' Before my patches, delete_event was returning FALSE - this told GTK to propagate the event to other widgets. So when the window was closed, GTK propagated the delete_event to the progress bar - but the progress bar did not exist anymore because it had already been automatically deleted it by the destruction of the window. Please note: use the patch named the mandelbulber0.94-quit_fix_a.patch.txt - the other misses a return statement. [1] http://library.gnome.org/devel/gtk/2.21/GtkWidget.html#GtkWidget-destroy-event Title: Re: Mandelbulber 0.94 Post by: kon16ov on October 20, 2010, 01:36:03 PM Buddhi -- thanks for the clarification on some of those things.
I figured the lowmem was for big renders. For those who don't know how much of a difference it makes: a 4096x3172 render of just the base image in "normal" mode allocates 618MB RAM. (Painful on a system with 512MB RAM... :) ) In lowmem, it allocates 173MB. Now, THAT's cool. I figured that about the palette, as well, and while I think it would be just slick to morph from palette to palette within an animation, I also know that such a thing would be a titanic pain in the butt to code. I was more concerned with the lack of updating the palette while I was trying to find that "sweet spot." I'm thinking that it was more to do with my timing than the program -- when an image is rendering, at what point does it trigger an update? Is it when it's calculating the ambient occlusion or should I just hold off until it finishes rendering just to be on the safe side? (I kind of know the answer to this...but my patience -- or lack thereof -- gets me in trouble...) I understand how the anims work, settings wise, but was just wondering about storing the fractal type in the settings, since my big confusion there was saving the keyframes for a Polynomial Power 2 and after closing the program and coming back to it, loading the keyframes it showed the PP2, but rendered the Trignometric. It's at this point that I wish my C++ wasn't so blinkin' rusty so I could help out with this stuff instead of just asking weird questions. Thanks again for a great program and all the work that's being put into it! If I used it like it was supposed to be used, right now, it does pretty much everything I need, it's just a matter of fine tuning which it sounds like you're working on, anyway. Also, James, thanks for the patches -- good stuff! Phil Title: Re: Mandelbulber 0.94 Post by: windwakr on October 23, 2010, 10:37:24 PM Hi, awesome program.
One question, how can I zoom out? All three mouse buttons seem to zoom in. Title: Re: Mandelbulber 0.94 Post by: kon16ov on October 23, 2010, 11:48:52 PM Howdy,
On the "View" panel, the "backward" button should back you up. This is also true within the 3D Navigator. So, there's no way, yet, that I can discern to back up using the mouse, but through the panel you should be good to go. And, yeah, it's a nifty program. I dig it a lot. Phil Title: Re: Mandelbulber 0.94 Post by: windwakr on October 24, 2010, 12:59:26 AM So, there's no way to zoom out with the mouse? That's weird. You would think that if you can zoom in with it, you'd be able to zoom out with it.
Title: Re: Mandelbulber 0.94 Post by: kon16ov on October 24, 2010, 02:15:39 AM Yeah, the controls probably weren't the foremost concern, at the time, if he was coding like I would code. It's getting there, though. For now, use the View->backward control. Control or shift don't do anything, either, and Alt is just good for moving the window around. Absolute Distance mode is probably wise to use, there, too, as otherwise the backing up will take...a while to get a decent distance back. I may be speaking out of turn, but I would think that the controls will get some tweaking love pretty soon.
Title: Re: Mandelbulber 0.94 Post by: Buddhi on October 24, 2010, 09:36:01 AM Here is a better patch than the previous patch. This also fixes the problem with the progress bar (I believe). I have locked at this patch. I will implement it. Thanks when an image is rendering, at what point does it trigger an update? Is it when it's calculating the ambient occlusion or should I just hold off until it finishes rendering just to be on the safe side? (I kind of know the answer to this...but my patience -- or lack thereof -- gets me in trouble...) Update of image is triggered by some smart timer. Trigger period equals time needed to update image multiplied by 50. It means that refreshing of image takes less than 2% of CPU time. When Screen Space Ambient Occlusion is activated, then time needed to refresh the image is longer and also refresh period is longer. I understand how the anims work, settings wise, but was just wondering about storing the fractal type in the settings, since my big confusion there was saving the keyframes for a Polynomial Power 2 and after closing the program and coming back to it, loading the keyframes it showed the PP2, but rendered the Trignometric. Fractal type, colors palette, texture file paths, etc.. after pressing Render animation are the same as was set in user interface before starting of rendering. Those settings are not got from keyframes. As I write before, please always prepare some settings file with all global settings for animation and load it before starting rendering. In timeline window there are visible different types of formulas, because each keyframe file is loaded as independent settings. But during rendering animation the program can't morph fractal type and this parameter program takes from actual settings visible in GUI. One question, how can I zoom out? All three mouse buttons seem to zoom in. Now there are only two ways to zoom out. 1. Use undo button to come back to older view 2. Type higher value in "Closeup (zoom)" edit field 3. Use Backward button. This button works only when before was used Forward button I will try to do zoom out by right mouse button in next version of Mandelbulber. |