Rendering 3D fractals without distance estimators

[Kali]

   Hi Kali
I'm completely new here and in the fractal world , This picture is really amazing , i wonder if it could be possible
to get the same result with mandelbulb 3d ...and if you would share this formula (or not  )...

20 years of 3d vfx but it's the first time i try the fractal tools . You can call me "junior" 

Tom

Thanks tomaya, the formula is the standard 2D Julia (z=z*z+c), but adding 3D rotations at each iteration. Tried to render this with distance estimation and I couldn't find a way to make it work, so was the first thing I wanted to try with Syntopia's bruteforce renderer. I don't know how Mandelbulb3D could handle it because it's a distance estimation renderer, so I don't want to bother anyone for a M3D implementation that it's most likely not going to work properly.
Anyway, thanks for your interest and welcome to the forum 

[Alef]

If someone are interested, here is Chaos Pro Helpfile, how it optimises noDE brute force method.
 
Quaternion Parameters
 
Here you can define all parameters which describe the 3D space to calculate:
You can exactly specify the 3D space to use. Additionally you can specify, how this 3D space gets scanned by ChaosPro: Simply scanning the whole 3D space would be possible, but awfully slow. So I had to apply some logic in order to reduce calculation times.

Lets describe the parameters:

Normal vector N and base vector V: These two 4D vectors describe a 3D space in normal form:
The 3D space consists of all 4D points P, which satisfy N·(P-V)=0

(where · means dot product: [a1,a2,a3,a4]·[b1,b2,b3,b4] = a1*b1+a2*b2+a3*b3+a4*b4 )

If you do not want to bother with mathematical meaning: Simply play around with the values: They affect the shape of the fractal.
The following parameters are somewhat difficult to explain: They are the result of a strange algorithm to scan the 3D space. The algorithm is "strange" because I had to speed up the calculation time.
Resolution: As the name implies, this specifies some kind of resolution: To be more exact: It specifies the resolution in z-direction as a multiply of the fractal width (so on resizing the fractal you wont have to change this value: It will be adjusted according to the size of the fractal). For each pixel in the window ChaosPro calculates the ray which starts at the observer, goes through this pixel and ends at the transformation plane.
This ray gets examined using the specified resolution. In short terms: Increasing this value enhances the image quality and slows down calculation speed: If there are too many "holes" in the fractal, or if the fractal looks more like a collection of points rather than a solid object, then it is a good idea to increase the resolution.
Start Scan:
This parameter speeds up the calculation:

Most of the time a Quaternion fractal is some smooth object. So if we want to examine a ray in order to find the border of a quaternion object and if we already know the distance of the neighbouring pixels, we can assume that the pixel in question nearly has the same distance.

So there is no need for ChaosPro to start searching at the beginning of the ray, i.e. at the observer. Instead, it can start at a distance near the neighbouring pixels. And that's what this parameter is ment for:

Assume the neighbouring pixels are at distance d and Start Scan has been set to 10 (parameter is specified in percent, thus this means 10%).
Then ChaosPro starts scanning at d-d*Start Scan/100, or in other words, ChaosPro goes back 10% (=Start Scan) of the distance and starts scanning from there.

This greatly speeds up calculation times: Just watch the fractal calculation: The very first line of a quaternion, where *no* information about the fractal is available, needs much longer than all the succeeding lines, where this neighbouring information is available.

But the drawback is: Sudden big jumps in a quaternion object won't be detected. So play around with this parameter, set it to 100 in order to "disable" the feature (this means: Go back 100%, i.e. to the observer, i.e. start from scratch...).

If you have a very strange object with many holes and cliffs and whatever, I would suggest to increase this parameter, although the calculation time then increases, too.

Precision: The resolution basically should be at least about 20 times the fractal width.
If the resolution is set to 2, then the fractal object would seem to have "steps" in it, which disappear when the resolution is increased. If you want to see what I mean, choose Precision=1 and resolution=2, then increase the resolution. Do you see the steps? And do you see how they disappear when you increase the resolution?
Explanation: ChaosPro must determine the distance between a quaternion pixel and the observer. Lets say that ChaosPro scans a ray of length 4 at 200 points. That means, each 0.02 (=4/200) unit a pixel gets tested whether it belongs to the quaternion or not. But now imagine a pixel is 1.009283 units away!
ChaosPro would test whether the pixel 1 unit away belongs to the quaternion:
Result: no
Now ChaosPro continues and tests the pixel 1.02.
Result: yes

And due to this effect steps appear in the fractal when the resolution is too low.
So basically we need to increase the resolution by some magnitude, but we do not want to increase the calculation times.
So a trick gets applied:
After having found a pixel ChaosPro uses a second pass to determine the exact distance of that pixel: In short terms: When ChaosPro finds a pixel in step i, it knows somewere between the previous step and the current step the object is hit. It then tests the middle of that distance, then knows whether the object is hit in the lower or upper half. It continues doing so for Precision times. In more technical terms: It uses a bisection algorithm of depth "Precision" to actually find out where the object is hit by the current ray.
Lets take the previous example:

ChaosPro scans a ray of length 4 at 200 points.
That means, each 0.02 (=4/200) unit a pixel gets tested whether it belongs to the quaternion or not.
Assume Precision has been set to 8.
Assume there is a pixel 1.009283 units away.

ChaosPro would test whether the pixel which is 1 unit away belongs to the quaternion:
Result: no
Now ChaosPro continues and tests the pixel 1.02 (next step).
Result: yes
Now ChaosPro starts with the second pass:
Iter Min Max Middle Test at middle
1 1,000000 1,020000 1,010000 Y
2 1,000000 1,010000 1,005000 N
3 1,005000 1,010000 1,007500 N
4 1,007500 1,010000 1,008750 N
5 1,008750 1,010000 1,009375 Y
6 1,008750 1,009375 1,009063 N
7 1,009063 1,009375 1,009219 N
8 1,009219 1,009375 1,009297 Y
And after only 8 further iterations ChaosPro knows that the border of our quaternion is at about 1,009297, which is quite near at the real distance of 1.009283

Conclusion: Precision artificially increases the resolution. The scan resolution basically is Resolution * 2^Precision * Width_of_fractal
Setting precision to 0 disables the bisection algorithm.
Roughness - lets you specify an artificial roughness of the surface by modifying the angle in which the light falls onto the surface. If you set it to 0.1 then the surface seems to be a little bit rough. 0 turns roughness off, the pure fractal surface will appear without any special modification.
Gamma - the gamma value: If the object seems to be too dark, it's a good idea to adjust the gamma value and make it smaller.
Contrast - lets you adjust the contrast of the image

Inside
If checked ChaosPro will render the inside of a quaternion. This of course only works if the camera is "inside" the quaternion. The difference between the "inside" and "outside" view is when ChaosPro thinks it has found the border of the object:

Outside View: ChaosPro scans a ray starting from the camera position until it finds a point which is "inside".
Inside View: ChaosPro scans a ray starting from the camera position until it finds a point which is "outside".

The inside view might not work for all formulas: For example most distance estimation formulas only work for points outside an object. The standard ray scan algorithm should work in any case, as it only performs a stupid, slow, complete ray scan.

[richardrosenman]

This algorithm takes x and y coordinates as a complex number, squares it, does a 3D rotation and adds julia constants.

Too bad the lighting doesn't work well with tiled large renders, but it's an awesome tool for exploring new formulas and ideas...

Thanks Mikael, good job!!

Hi Kali;

I just came across this image and it's stunning! I downloaded Fragmentarium and was wondering if you could outline the steps involved to get what you created? It's a good way for me to learn this way.

Thanks,
-Rich

[Kali]

Hi Rich, here is the .frag file, just play with the sliders

If you are a programmer I can detail you later what the code does...

thanks for your interest!

Hi Kali;

I just came across this image and it's stunning! I downloaded Fragmentarium and was wondering if you could outline the steps involved to get what you created? It's a good way for me to learn this way.

Thanks,
-Rich

[richardrosenman]

Hi Kali;

Thank you so much!

I tried to run it just now but it reported a bunch of errors:

Could not find: Z
Could not find: FloorHeight
Could not find: FloorNormal
Could not find: FocalPlane
Could not find: Fog
Could not find: FudgeFactor
Could not find: Gamma
Could not find: GaussianWeight
Could not find: Glow
Could not find: GlowMax
Could not find: GradientBackground
Could not find: HardShadow
Could not find: Iterations
Could not find: Julia
Could not find: JuliaC
Could not find: MaxRaySteps
Could not find: NormalBackStep
Could not find: OrbitStrength
Could not find: Power
Could not find: R
Could not find: Reflection
Could not find: RotAngle
Could not find: RotVector
Could not find: Saturation
Could not find: ShadowSoft
Could not find: Specular
Could not find: SpecularExp
Could not find: SpecularMax
Could not find: SpotLight
Could not find: SpotLightDir
Could not find: Target
Could not find: ToneMapping
Could not find: Up
Could not find: X
Could not find: Y

Do I need to set something up beforehand?

Also, if I try to move or spin the view it crashes...

I am using Fragmentarium v0.9.12

Perhaps some interpretations were changed in this latest version?

Rich

[Kali]

Mmmm, sorry, I don't know, it should work... 

Hi Kali;

Thank you so much!

I tried to run it just now but it reported a bunch of errors:

[Syntopia]

Hi richardrosenman,

The warnings are not important - these are just parameter settings which are ignored.

If Fragmentarium crashes the reason is nearly always that the GPU times out - if a single frame takes more than 2 seconds to render this will happen (on Windows). There are ways around this:
http://blog.hvidtfeldts.net/index.php/2011/12/fragmentarium-faq/

But the simplest test is the set the Preview slider to 4x - this will speed up rendering by a factor of 16 (do this before loading the fragment). If Fragmentarium still crashes, it is because of another bug, and I need to hear more details about OS and GPU.

Cheers, Mikael.

[richardrosenman]

Hi Mikael;

Thank you for your reply. I have to say I haven't been so impressed with fractal imagery as I have been with the results of Fragmentarium for a long time. I am used to doing brute force monte carlo global illumination sampling for my 3D rendering and love this tactile look when applied to fractals. Congratulations on what appears (at the surface) to be a fantastic piece of software.

I'll look into your suggestions tonight when I'm home from work.

In the meantime, and I did do a search already, do you have recommendations for high performance video cards that would make Fragmentarium fly? I read you use Nvidia (I do too) but I know they come in many flavors, boasting different amounts of ram and processing cores. If there's a list or guideline for getting one that will be optimal for Fragmentarium, I'd love to know. I would consider a gpu card update well worth the output from Fragmentarium.

Any info appreciated!

Cheers,
Rich

[richardrosenman]

Mmmm, sorry, I don't know, it should work... 

Hmmm... it seems I am missing "Brute-Raytracer.frag" Should this file be included with the latest Fragmentarium build or is this a custom, 3rd party file?

-Rich

[Syntopia]

Hmmm... it seems I am missing "Brute-Raytracer.frag" Should this file be included with the latest Fragmentarium build or is this a custom, 3rd party file?

-Rich

Hi Richard,

As of now, the brute-force raytracer is only available in the GitHub repository - if I remember correctly I haven't changed any binary files, so you can just download the required fragments from: https://github.com/Syntopia/Fragmentarium/tree/master/Fragmentarium-Source/Examples/Include

It will be part of the next Fragmentarium release.

In the meantime, and I did do a search already, do you have recommendations for high performance video cards that would make Fragmentarium fly? I read you use Nvidia (I do too) but I know they come in many flavors, boasting different amounts of ram and processing cores. If there's a list or guideline for getting one that will be optimal for Fragmentarium, I'd love to know. I would consider a gpu card update well worth the output from Fragmentarium.

The most important thing for GLSL pixel shaders is the raw GFLOPS rating - memory and ram bandwidth is not important.
If you divide the GFLOPS rating with the retail price, you have a nice measure of how to get most value for your bucks.

A list such as:
http://en.wikipedia.org/wiki/GeForce_600_Series

is useful. Better deals can probably be found be buying a 500 series GPU.

Also notice that newer AMD GPU's seems to do very good for general purposes computations (probably better than Nvidia), but I am still reluctant to buy them - mostly because of previous experiences and the lack of CUDA support.

[richardrosenman]

Mmmm, sorry, I don't know, it should work... 

Kali; Do you have control over lights with your brute-raytracer? I figured out how to get your sample to work but lights, specularity, etc, are non-functional. Is it the same for you?

-Rich

[Kali]

Kali; Do you have control over lights with your brute-raytracer? I figured out how to get your sample to work but lights, specularity, etc, are non-functional. Is it the same for you?

-Rich

uncheck "showdepth" option

[richardrosenman]

Is anyone else having this issue? Any examples ("26 - 3D fractals without a DE.frag", "rotjuliatestff.frag") using the Brute-raytracer method compile with a black (un-illuminated) shape. Adjusting light direction, intensity, specularity, etc, all result in no change. Like they do not work. The only light feature that works is camlight & camlightmin which for some reason, is set by default to 0. Increasing the camlight will show the fractal, but of course, with no specularity or directional lighting.

Kali's gorgeous image appears to have directional light (not just relying on the camlight) and increased specularity. So my question is: does anyone else have control over those features? Is it just me? Because I could swear virtually none of the standard lighting features mentioned above work with the brute-raytracer. And of course, I therefore can't produce anything near Kali's stunning images.

Any info would be appreciated.

-Rich

[knighty]

Wow! excellent shader syntopia. I never expected it would work so well. Thank you!

@richardrosenman & syntopia: I have the same issue. I'm also using v0.9.12 precompiled version. It looks like the host programm doesn't send the correct value of "pixelSize" when calling DepthBufferShader's vertex shader or just does not initialize it. To (partially) solve this issue, just comment the line:

Code:

viewCoord.x*= pixelSize.y/pixelSize.x;

in DepthBufferShader.frag then save it.
I'm not sure if the normals will be correct this way. they should be if the aspect ratio of the rendering window is 1. (is pixelSize actually the viewport size in pixels?)

Also, it's easier to begin with a value of 1 for ToneMapping in post tab.

[Syntopia]

You are completely right, Knighty - there was a bug with the pixelSize, which I corrected in the Git repository, and then forgot all about. The newest version of my script relied on this bug to be fixed. Kali probably used the first version (or compiled the code from repository).

I uploaded a raw build here, which should work:
http://hvidtfeldts.net/Fragmentarium-Windows-Build-10-11-2012.zip

Btw, pixelSize (as used here) is (1.0/viewport_width_in_pixels,1.0/viewport_height_in_pixels), i.e. the size of a pixel in a 'unit' coordinate system.