When rendering a semi-deep zoom image on the regular Mandelbrot set, the final image produced has large rectangles of solid color covering the minibrot. I assume this has something to do with petrabution?
The bug seems to vary in intensity...

The bug seems to vary wildly from render to render...

When changing parameters, the image only updates after you change it again, after which the image will show the image with the previous parameters.

For example, starting with a power 2 Mandelbrot, changing the power to 5 will not update the preview, and changing it to 10 will update the preview to the power 5 Mandelbrot. Changing the power to 15 will update it to a power 10 Mandelbrot.

A

In the formula editor, if I open up a Replace Box with Ctrl-H and try to paste into one of the lines inside the box with Ctrl-V, the replacement text goes into the formula at the cursor position instead of into the Replace Box.

This is not the behavior that I had expected

Request: Better control over periodicity checking.


Currently, periodicity checking is controlled by a limited set of options: "off, rough, normal, conservative". I don't know how it is implemented, but I am guessing some orbit distance threshold preset table or similarly.

I work with fractals that are very sensitive to the periodicity checking, yet turning it off altogether would real

Eval mode on v601 worked fine, but I just bought v605 and now there is no animation menu or timeline on v601 and v605. Anyone else have this issue? Any fix? MacOS 10.14.6

When I'm browsing formulas, it's very helpful that UF calculates and shows thumbnails of each possible formula.

There are also drop-down lists in many formulas, such as the built-in Function list (sin, sinh, asin, ...). It would be very helpful if UF could show calculate and show thumbnails of each choice.

Not easy to implement, but as long as I'm dreaming ...

The ResultIndex function of a GradientColoring formula returns a value for #index, an index into the gradient. The #index has useful values from 0 to 1. If #index is outside [0,1], 0 is used.

If Repeat Gradient is checked, positive values greater than one are reduced to [0,1]. For example, 3.7 becomes 0.7, which is in range. However, negative values of #index are still replaced by 0.

It

I recently noticed that the ampersand character & seems to be ignored in the caption of a parameter, although it shows up properly in the caption or text of a heading.

Try something like

heading
caption = "this & that"
endheading
float param p
caption = "this & that"
endparam
When the formula is invoked, the & shows up in the heading, but no

I've tried both with the client on my TR Pro and the server on the 10/20 core i7-6950x and the other way around; regardless of which direction it's going, only one core on the machine set up as the server is used. (tested that just in case it was deciding offload wasn't worthwhile). I checked affinity and it was set to all cores for the server process and the client was set to 20 cores on the

Do you think we should add a dark theme for Ultra Fractal's GUI? It would be less straining for our eyes. Thanks

When writing formulas, I frequently make errors that the compiler finds. The compiler then moves the insertion mark to the location of the first error that it finds. The insertion mark is somewhere on the current page, but it's not easy to see.

I'd like an option in Preferences to make the insertion mark more visible. Perhaps larger, or a different shape, or a different color.

A tiny thing, but...

In writing programs, what I really miss from my days writing in C, is ++, being able to write n++ instead of n = n + 1. Even better if it's BigArray[LongIndex]++.

I was hoping that switching the center parameter's keys to smooth interpolation would result in a smooth change of direction in a zoom animation. A gentle, natural-looking curve instead of an abrupt turn-on-a-dime. But the interpolation settings don’t seem to have any effect. It's always the same sharp turn halfway through.

Smooth interpolation:


Linear interpolation:

I am rendering some simple fractals, but it seems to take more time than it should. I find that the 4 Efficiency cores are running 100%, while the other 4 Performance cores are all idle. Interestingly, this doesn't happen when I am previewing the fractal. The rendering speed would be greatly increased if this can be fixed.
By the way, I am using a MacBook Air with an M1 chip.

Hello,

I was just playing with a fractal and noticed that there should be a very nice way of coloring my fractal if I juuuuust got the gradient offset and color density right. But I need to adjust them one by one, going back and forth. I think for these two it would make sense to have a 2D explorer - like we do for complex variables - where we can adjust color density on the x-axis and gradi

I see the only version of Ultra Fractal available for macOS is still an Intel build. Are there plans to do a build for the new Apple M1 processors? I imagine it would be a lot faster for those devices.

This is allowed in the default section of a ucl coloring formula, but not in a GradientColoring plug-in.

Apparently I have to make my own version of GenericGradientColoring from standard.ucl and put "render = false" in there.

HEIFs are about 1/3rd the file size of PNGs, which are the smallest lossless files Ultra Fractal can write.

I’m converting the PNGs to HEIFs with another app but it doesn’t batch-process very well. It’d be sweet to have lossless HEIF right from UF. Even better if the files are saved with the .heif extension not .heic because Final Cut Pro and other apps don’t recogni

In arbitrary-precision arithmetics, the sign of the result of trigonometric and exponential functions is sometimes wrong.

Here's an excerpt of a formula printing some debug results:

complex m1 = exp(flip(#pi))
print("exp(i * #pi)=",m1)
float sin1=sin(#pi)
float cos1=cos(#pi)
print("cos(#pi)=",cos1, ", sin(#pi)=", sin1)
When I run this without additional precision, I get the following res

Something curious is happening. Here's an exported image from UF. Looks right.


Here's what I get when rendered (normal anti-aliasing, forced linear drawing).


Noticeable differences, not subtle. Not solved by changing anti-aliasing parameters or precision. And if I render the same thing again, different results!



These are done with all 12 of my CPU's cores (6 real co