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.
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
caption = "this & that"
float param p
caption = "this & that"
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]++.
posted Feb 5 at 10:56 pm
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.
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.
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
posted May 2 '22 at 12:05 pm
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.
posted Jan 18 at 9:50 pm
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)
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
posted Nov 13 '22 at 6:22 pm
When rendering animations with motion blur, all is well for the first 90% of each frame. This is when UF is calculating the fractal and antialiasing. The four CPU cores are maxed out and the CPU is 0% idle, as shown below on Activity Monitor.
But then comes the final 10% of the frame, which is when motion blur is being calculated. UF suddenly gets a lot slower. The CPU is 70% idle.
posted Nov 10 '22 at 10:32 pm
I am going through the UltraFractal help
Combining fractals with Images.
And I get to this step:
"Locate the Color Trap plug-in parameter (currently set to Trap Shape Wrapper) and click the Browse button next to it. Navigate to the common.ulb file in the Public folder and select the Image Trap plug-in."
As soon as I click on Public->common.ulb
I get the follo
In a float param block, the compiler allows
default = 1/#magn
which can be useful, but doesn't allow
min = 1/#magn
which also can be useful.
Also the help entry "min setting" has a typo. The sentence "If this setting is not specified, there is no maximum value for the parameter." Obviously it should say minimum.
Here's a fractal with 100% of points Inside; no points reach the bailout criterion. The Statistics tab says that the Min and Max iterations are both zero. I would have expected that both Min and Max would be set to #maxiter.
This is either a bug or a feature.
Here's an example:
title="test" width=800 height=600 layers=1
credits="Jim Blue;10/5/2022" ant
Currently #numiter is readable only in the Final section of a ucl coloring formula. It is not even readable in the ResultIndex function of a ulb Coloring formula, where one might expect to be able to use it.
If #numiter were readable in any coloring formula, whether in a .ucl or. ulb file, some interesting coloring options would be available. For example, if coloring according to distance fro
posted Jul 4 '22 at 6:17 am
I just ran into this new problem. When I render to disk in high resolution, it tells me that I have to render in tiles because the image size would exceed 2 GB. This didn't happen before. Just to make sure, I tried to re-render an older image which previously worked, and UF is now also refusing to render it.
In one instance, the predicted file size was around 900 MB, the sum total