Title: Another glitched render Post by: stardust4ever on October 24, 2017, 01:17:28 AM This image was meant to be an extension of Dragon Dagger https://stardust4ever.deviantart.com/art/Dragon-Daggar-4k-659443666 (https://stardust4ever.deviantart.com/art/Dragon-Daggar-4k-659443666), which itself was an extension of Fire Sword https://stardust4ever.deviantart.com/art/Fire-Sword-639840749 (https://stardust4ever.deviantart.com/art/Fire-Sword-639840749), an extension of "Dance of the Fire Dragon II" http://www.fractalforums.com/index.php?action=gallery;sa=view;id=19014 (http://www.fractalforums.com/index.php?action=gallery;sa=view;id=19014) which itself was a runner up in the fractal contest in 2016.
I tried to extend the pattern through another iteration but ran into troubles with wrong patterns in the glitch areas. I did another "32k" render (technially 30,720x17,280 pixels, 531Mp) and the results were less than satisfactory. (https://orig00.deviantart.net/d7ac/f/2017/296/4/7/dragon_claymore_glitched_by_stardust4ever-dbriunm.png) https://sta.sh/0pyuo5y6ilb (you may have to click the download link on the right side for the image to appear) Code: image.width=1920 Yes stupid me for doing a 531 Mpixel render at this depth (total render time was 20 hours) without doing a test preview first, but sometimes the glitches can be odd ducks. Tools used KF newton minibrot finder to locate the centroid and calculated the zoom depth halfway between the minibrot and the parent formation. Render at 50 million iterations and this is what I got. I seem to recall adjusting certain automatic settings like the number of reference orbits, etc (which do not save with the file) can "fix" these types of images but it's been a long time and I forgot what setting I used in the originals. Generally the deeper and more complex the formation, the more likely the orbits are to go FUBAR. I understand that Mandel Machine hasn't been updated in years, but advice to fix my render settings would be appreciated. Kalles Fraktaler is too slow at these extreme depths to be of use to me. Thanks... Title: Re: Another glitched render Post by: claude on October 24, 2017, 01:48:17 AM At first glance I saw the small glitches in the central figure and thought "not so bad, should just be adjusting Pauldelbrot threshold a bit to be less tolerant". Then I saw the outer region and the total mess there - ouch :(
I don't know if MM has an adjustment for the glitch threshold, but ~3e-3 is what KF uses in "low tolerance" mode (1e-7 otherwise). I can't run MM to test because I haven't figured out how to install a JVM within WINE on Linux :( Maybe there is an option to do with series skipping too? Here in KF the primary reference runs out after 31.5M iters, and series approximation only skips 6.5M iters, so there are a lot of per-pixel iterations hence slow :( (I set the zoom in KF to 1e576, I think that's the correct base10 conversion...) Title: Re: Another glitched render Post by: Dinkydau on October 24, 2017, 06:26:55 PM The first things I do when there are glitches are:
Set "OOM diff between terms" to 10 instead of 2 Disable "Use lower scale data types" Disable "Ignore delta0 if negligible" Those are settings that grealy improve speed in exchange for less reliability, which is great for exploring but bad for rendering. If even that isn't enough, you may need to reduce the number of terms. The default of 17 is usually reliable. If not you may need to go down to 9 or even 5. You can also set a limit to the number of skipped iterations, which may actually be the same effect as lowering the number of terms - I'm not sure. Another trick is to either center your shape perfectly or not. Glitches sometimes magically disappear. By the way, more terms and the dangerous superspeed settings do give good results sometimes so it may be worth trying them first before you start a render that takes a really long time. If you can get away with the default settings the render time is much lower. Title: Re: Another glitched render Post by: stardust4ever on October 25, 2017, 06:03:32 AM Thanks. I now remember setting the 17 to 9 or 5 in the past to help with glitching. Took twice as long but was worth it.
The centroid is dead center minibrot, truncated to however many digits the program saves at this depth. I used KF's newton minibrot finder so I don't waste countless hours flicking the scroll wheel anymore. Also the first ray was fine, calced a good 90+% of the image. The additional "guessed" rays are what went fubar. There's a glitched out parallel dimension of wrong fractal data underneath that first pass. Offsetting the image to place the centroid and initial ray into one of these voids might make an interesting but wrong fractal. One could zoom into an infinite elephant spiral, back out, and rerender witn "risky"settings to purposefully glitch the image. :p Title: Re: Another glitched render Post by: stardust4ever on November 03, 2017, 12:05:34 AM Well I set series approximation to "5" and rerendered, but it's taking 4+ days to compute. It was 99.2% this morning when I left for work, but it is apparently still processing the glitch holes. So far looking good, but I question whether it was worth burning my CPU for 4+ days. I don't really need to render everything to .5 Gigapixels... :tongue1: (https://orig00.deviantart.net/2e61/f/2017/306/6/7/no_glitches_screengrab_by_stardust4ever-dbsjdix.png) https://sta.sh/028qqtudpi6c I think I liked the original pattern better before I doubled it. I renamed it "Orion's Belt." (https://img00.deviantart.net/e4b1/i/2017/306/d/8/orion_s_belt_4k_by_stardust4ever-dawm5zm.png) Full view and 4k download link: https://stardust4ever.deviantart.com/art/Orion-s-Belt-4k-659443666 |