YAMS

[David Makin]

@Makin:

Thank you for correction, also 5 ln's wont speed it up  

I came around the unsteadyness by steering the Z position to a point where frac(smoothIt) becomes 0.5  :

Is there maybe a trick to get a gradient from one iterated position, so we dont need to calculate 4 positions. That would be cool.

The DE part is nearly the same as you posted, i also observed that in higher order bulbs you can use a slightly bigger step width.

The extra logs are just to make it more accurate (Actually using that method for bicomplex fractals then they're essential).

If you actualy check the number of steps taken along the ray then doing 4(analytic) or 8(delta) extra iterations to get the gradient is pretty minimal

Just to re-iterate that using the adaption of the analytical equation using the difference in magnitudes that I posted earlier is considerably faster than the smooth iteration method - typical accurate render of a full view of the degree 8 "-sine" Mandelbulb @640*480 on my 3GHz P4HT (distance threshold 1e-3 max.iter 400):

Analytical DE: 39 secs
Smooth Iter delta DE: 1 min 5 secs
Magnitude delta DE: 42 secs

The Smooth Iter and Magnitude renders were virtually identical.
In case it helps divide the times by 3 to give correct speeds on a 2GHz core2Duo

Edit: Just to add that Smooth Iter delta DE without using the run-time calculated divergence took 50 secs.

[Jesse]

The extra logs are just to make it more accurate (Actually using that method for bicomplex fractals then they're essential).

If you actualy check the number of steps taken along the ray then doing 4(analytic) or 8(delta) extra iterations to get the gradient is pretty minimal

Yes, the values are now really smooth, but with some extra time consumption. And the method to stear to a frac part solves problems with the inaccuracy, so i am not sure if i have to use it. The smoothed values in the variable power function were really smooth, so i don't see a need here.

But what i dont understand:
I make in each step of the ray the 4 iterations to calculate a 3D gradient!
This takes much time and it sounds like you dont do this for each step? 

It is clear that the extra time, once the set is found, is not that much important.

Thanks

[David Makin]

I think I may have been confused by your term "gradient" - I assumed you meant the 4 points used to get the surface normall, but I guess not

I basically iterate at step and at step+delta (assuming step is not "inside") and then calculate the smooth iteration value for these using:

smooth = iter + (log(0.5*log(bailout))-log(0.5*log(m)))/log(divergence)

in each case where m is the square of the final magnitude and divergence is either fixed or calculated.

Then I use:

Distance Estimate (DE) = 0.4/(1.0 + abs(smooth1-smooth0)/delta)

That's the value I check against the solid threshold, but is scaled to give a step distance if solid is not found:

step = DE*0.6/accuracy

Where accuracy is a user parameter - 1 for speed, 2 or more for accuracy (2 is normally sufficient but sometimes I use up to 4).

So while stepping I only calculate 2 iterations per step, if solid is hit then I find the boundary more accurately using a binary search and then finally iterate at the adjacent points on adjacent rays at the found distance and found distance + delta to get the DE for those - I assume all the DE values are correct so this gives me 5 surface points to average the normals from 4 triangles.
Note that I actually use the adjacent rays at 0.5 pixel offsets on the viewing plane rather than whole pixel by default, though the offset used is actually a user parameter.

[Jesse]

Ah, that is exactly what i wanted to know, sorry for the confusion and many THANKS! 

So there must be a factor 2 in speed increasing left, at least 

Then i go back programming...