Welcome to Fractal Forums

What if I accidentally changed .FRACT files to always open in Notepad; Would that, in theory, have any effect on how they open in Mandelbulber?
The reason I ask is that, since I did change it, I'm having problems with Materials especially - as far as I can tell.
The way they are displayed on the main interface is quite strange sometimes, and, in one case I know of, they don't render like they used to.

Mostly the Materials I'm talking about, and other associated settings, were saved in versions 2.04 and 2.08. Using 2.10 now. I wouldn't think that likely to be the problem, but it is making it difficult to rework some older stuff I did.
Any thoughts?

Hmm.. Looks like materials from settings saved in 2.08 do display correctly, and one example I have might even render as expected (at large scale). The one I'd like to explore atm has a very different look to the original. :/
Oh, and.. There was a bunch of errors and blank material boxes from loading an Example one time. Can't figure out which one now tho.

Well.. In part, I can test the idea myself. Migrating Settings+Materials etc. to one of my Client machines, where file association has not been tampered with, set that as Server and see what happens...

I can confirm that the Materials are displaying wrongly (exactly as in the two examples above), without any change to file association.
So, given that is the case, it's something to do with incompatibilities between versions of Mandelbuber? Idk..
I would love to have a material like the coloured glass displayed, but it is actually the default (non-transparent) material.

Btw, first time I've seen Client apps crash. Both of them, as it happens. On one I can tell it was a Qt problem. Curiously, haven't had a crash using my normal arrangement in a good while. Used to happen with monotonous regularity.

When it comes to settings created in 2.08 materials seem to display correctly, but they don't necessarily render as originally.
The examples attached show, from left to right, the original saved image, what saved settings for it produce and what happens when I do the same thing in 2.10. Apart from slight adjustment to distance, 2 and 3 are the same.
The material, it seems, was created in 2.08.
I wonder if saving it again using 2.10 would make any difference... I have another example from 2.08 which does render properly, so I don't understand why this one doesn't.

I cannot guarantee that everything will have backward compatibility. Mandelbulber is still evolving a lot. I'm trying to keep compatibility, but something can be missing in conversion function. Can you attach old settings files which are wrongly opened in Mnadelbulber 2.10? I will try to look what could be wrong.

This is the only one, including variations, I'm having trouble with so far. Despite the Materials display issue in the examples from 2.04, I haven't found any problem with them rendering in 2.10. The first is a simple Mandelbulb, the second a triple Hybrid by the looks..
A triple Boolean made in 2.09 is working ok too.

For this example, directly above, it's not only colour distribution but also shape and size are slightly different when rendered in 2.10. I tested it using 2.08-3 and in that case it does render as originally. Settings are:

# Mandelbulber settings file
# version 2.08
# only modified parameters
[main_parameters]
ambient_occlusion_enabled true;
camera 1.202315039462315 -2.404630078924631 0.8015433596415438;
camera_rotation 26.56505117707794 -16.60154959902025 0;
camera_top -0.1277753129999879 0.2555506259999764 0.9583148474999099;
DE_factor 0.1;
flight_last_to_render 0;
formula_2 88;
formula_material_id 2;
hybrid_fractal_enable true;
image_height 2400;
image_width 2400;
julia_mode true;
keyframe_last_to_render 0;
mat1_is_defined true;
mat2_surface_color_palette fd6029 7b7402 fff59c f5bd22 633100 301b15 aa0000 f87c00 d4ffd4 f1e754;
raytraced_reflections true;
target -1.797684960537685 3.595369921075369 -1.198456640358457;
[fractal_1]
[fractal_2]
[fractal_3]
[fractal_4]
[fractal_5]
[fractal_6]
[fractal_7]
[fractal_8]
[fractal_9]


The example attached is one I'm particularly interested in exploring. It's the same thing only with Box folding. Haven't tested it in 2.08 yet, but rendering in 2.10 shows DE factor makes an enormous difference. I changed it to 0.1, which gives a better approximation in 2.10. It's quite a large size with DE of 0.01, so takes a good long while to render.

EDIT: I may be wrong but, it seemed to take much longer using 10 than it now does using 8.

To get proper shape in this case you need to change Rendering Engine / Distance estimation function to Delta DE Logarithmic . It will look as original with DE_factor = 0.5

About very old settings (from 2.04), incompatibility of materials is because in 2.04 there was no materials at all. The program tries to convert old settings (without materials) to create new materials which will look like in old settings. But it's not possible to get 100% compatibility, because material properties are rendered in a little different way.

Like this?

Yep. Is it better?

Thanks Budhhi, I don't know yet. I'll try it out asap and let you know.

 CCV, If you compile the program you can try these changes  if you are mixing a logtype formula with the Collatz.

fractal formulas.cpp    insert the following as the last line of the Collatz formula.

aux.r_dz *= 4.0;

fractal list.cpp

change linearDE function to logarithmicDEFunction so the code becomes:
   
fractalList->append(sFractalDescription(
   "Collatz", "collatz", collatz, analyticDEType, logarithmicDEFunction, cpixelDisabledByDefault, 10));

Then recompile

In my test the render time dropped from 2hrs 30min down to 14minutes

Regarding the difference between V2.08 and V2.10,

Hmmm, when using the same settings file they should be the same unless I have forgotten about something  ( or broken something.)

Regarding a change in size or shape  to happen, this is mainly caused by a change in formula code or DE calculation (and it would affect color to some degree).

Unfortunately I do not currently have time to check V2.08 code against V2.10 code to find any change, but maybe later.

@mclarekin, you lost me at "compile". ???  :dink:

@Buddhi, yes! Much better. Many thanks. :)
It's not an exact match, I can spot the difference at full scale, but damned close.
Besides, rendering, with these settings, takes about 4 minutes - as opposed to an estimated 4 hours in 10, and 1 hour + in 8 with the settings I was using.

@mclarekin,
I notice you mention Collatz in particular.
Well.. This includes Collatz and was created in 2.08 and seems to render perfectly well in 2.10:

1) quote]estimated 4 hours in 10, and 1 hour + in 8 with[/quote]

That sounds scary, as V2.08 and V2.10 should be about the same.

 When reading the estimated time you sometimes need to wait a few minutes to let the estimating work, i.e. The estimated time may initially be 4hrs then after a few minutes  it will drop to maybe 2hrs and then it will continue to drop at normal time.

That is the general situation, but I have also noticed some situations where the estimated time increases until the progress bar has gone half way then it begins to fall normally.

2) Knowing which DE to use with which formula can be difficult. This is a list of the current analytical logarithmic DE formulas. If you use any of these with collatz then you will be best to first try  DelatDE Logarithmic.

BTW. Collatz is one of the most difficult formulas in MandelbulberV2 for getting good DE.

            case benesi:
            case benesiPineTree:
            case benesiT1PineTree:
            case benesiPwr2Mandelbulb:
            case bristorbrot:
            case bristorbrot4d:
            case buffalo:
            case eiffieMsltoe:
            case mandelbulbPower2:
            case hypercomplex:
            case iqBulb:
            case mandelbulb:
            case mandelbulb2:
            case mandelbulb3:
            case mandelbulb4:
            case mandelbulbBermarte:
            case mandelbulbKali:
            case mandelbulbKaliMulti:
            case mandelbulbMulti:
            case mandelbulbMulti2:
            case mandelbulbVaryPowerV1:
            case msltoeSym2Mod:
            case msltoeSym3Mod:
            case msltoeSym3Mod2:
            case msltoeSym3Mod3:
            case msltoeSym4Mod:
            case msltoeToroidal:
            case msltoeToroidalMulti:
            case quaternion:
            case transfQuaternionFold:
            case quaternion3d:
            case xenodreambuie:

Thanks for the list. There's a few in there I regularly use, some with Collatz some not so much.

As for "estimated time", yes it does drop back after some minutes but still takes longer than the lower estimate. I say 4 hours, because I did wait. I've done stuff taking 1 day +, if I think it worthwhile, with a combined CPU time of about 8 GHz. Is that scary too?

BTW

Your latest settings file,  automatically use deltaDE log because of the type of formulas you have in the other slots. And is probably the optimum DE for that combination. If you open the statistics, you will see a percentage of wrong distance estimations of 2. This is generally not good and  the areas of bad DE can be seen in the rendered image. If you turn off the color palette for Material 3, the image will turn grey and it is easier to see where the bad DE is disintegrating the fractal image.

I have not explored the Collatz formula very much, but I know it is difficult to find settings with good DE. But it does make some cool nteresting hybrids.  I will zip up the settings files that I have and post them here.

I will have to check out the render time thing to see if I can reproduce it.


Attached are some setting files using collatz, they hopefully all still work and should have average or better DE quality.

BTW I also sometimes get different coloring when I load a file from V2.08 or V2.09, sometimes I can track it down to being caused by some code change, but other times  i have not been able to find what caused it

I learned later, no matter what the combo, that using DE settings such as 0.01 did cause some fractures in the resulting image. Hence, started using the Optimisation buttons (usually High quality) which did produce better results than manually setting DE.

Still weird, imo,, that I ran into trouble with just the one so far.

Bhuddhi's suggestion, while not perfect, is most helpful. I could experiment with DE settings in 10 to see what happens, or just use 8 to get what I want.

Oh, sorry mclarekin. Thank you for the Collatz examples you posted. I'll check em out as I might be able, to see what I can learn.
Thanks for explaining a few things about Collatz in general too. I tend to use it rather a lot, it seems, it does make for some interesting results.
I actually did a lot of exploring in a Boolean IQbulb, Collatz, Buffalo combo. Seemed to work ok, except for very long rendering times which I attributed to the extraordinary amount of detail in some resulting images.

I might need to check back and reread some of your posts now and then too. Cheers.

@Bhuddhi, thanks for the Distance estimation function to Delta DE Logarithmic tip. It works quite well with DE_factor = 0.5, but, in the case of the box folding example I posted, is a perfect match with DE factor set to 0.1.

Just saying.

Collatz, it happens, is my favourite formula to use - in combination with others. Not sure if it's Collatz only but, the latest version of Mandebulber is setting  Delta DE Logarithmic as default and impossible to change.
Anyway, I didn't notice any problem any time except for the example I posted earlier.

Regarding "estimated time":
I've seen it increase, stall or decrease at any stage of render.
Seems to me, it has to do with level of detail being processed at the time.