a lil' problem with my DE formula in fragmentarium

[ker2x]

is my formula wrong ?
Why does it look all messy ?

Code:

#include "DE-Raytracer.frag"


float DE(vec3 pos) {
	return (length(pos)-1.0)+sin(pos.x*pos.y*pos.z*100.0)/10.0;
}

PS : sorry it's not really fractal (yet!)

[Jesse]

If you want it 100% correct, the distance must be non-directional.
This is often not possible or to much work, so you need to decrease the raystep multiplier.  Fragmentarium has such a limiter somewhere. 

You can predict more or less how much you have to decrease this limiter on such easy formulas, the higher those "hills" made with those offsets are, the more you have to decrease the limiter.

Maybe i make a little graph if i have time, but it is not hard to understand, like a heightmap flying over and the distance is calculated towards the ground direction and a hill in front of you is nearer, but not considered in the calculation!

[Syntopia]

(Oh, Jesse just posted while I was typing  )

A DE function must return the distance to the closest point on the fractal surface (or a lower bound for the distance). So not all functions can be used as DE's. In particular, the slope of the DE must never be more than 1. Otherwise the ray marcher will overstep and end up inside the object. In mathematical terms this means the DE-function must be Lipschitz continuous (with a Lipschitz constant of one) and zero at the object boundary.

Sometimes you can get reasonable results by dividing the DE with a fixed number (the Fudge Factor in Fragmentarium).
And sometimes you can get rid of some noise by oversampling (rendering in hires and downsizing).

Here is what I got after trying your formula and fiddling with the parameters:

[ker2x]

yay \o/



Thank you for your help.
I don't really understand yet, but i'm working on it. 

I'm learning GLSL (with the help of a book and http://www.iquilezles.org/www/index.htm ) and found that fragmentarium is really helpfull to learn by trial and error 

[Jesse]

(Oh, Jesse just posted while I was typing  )

Yeah, i am sorry for my crappy explanation!

Lipschitz continuous, have to remember this  


ps: great work on your program, Syntopia.  Just wondering if it would be a good idea for speed purpose, if doing only some raysteps in each thread and giving finished rays new ones.  Or does this automatically happen if you run on more pixels than GPU threads are available?
So no threads have to wait...
(Hope this sounds not to silly, i am a GPU newbie)

[ker2x]

Ho, btw, i'm using Fragmentarium on a low-end AMD Fusion EeePC and it works flawlessly (it's slower than my GTX470 of course, but it works!)

[Syntopia]

ps: great work on your program, Syntopia.  Just wondering if it would be a good idea for speed purpose, if doing only some raysteps in each thread and giving finished rays new ones.  Or does this automatically happen if you run on more pixels than GPU threads are available?
So no threads have to wait...
(Hope this sounds not to silly, i am a GPU newbie)

I'm not sure exactly what you ask, but for a GPU, using one thread per pixel is probably quite optimal. Many threads are a good thing on a GPU - in fact the numbers of threads should be much higher than the number of physical execution cores (which already is in the hundreds for a modern graphics card). This is due to the latency of many operations on the GPU - while waiting for an operation to finish, the GPU can switch to another thread on the multiprocessor and continue (there is no cost for switching between threads on the same MP). That there will be threads waiting to be scheduled, shouldn't make a difference - the total amount of work there needs to be done is the same no matter how you divide it.

Having said that, using one thread per pixel is also by far the easiest when using GLSL. There is no way to synchronize between threads in GLSL.

The only problem with this approach is, that the drawing of a frame must finish in less than two seconds. Otherwise Windows kill the display driver and restores it (you can get around this by rendering in tiles, though).

[Jesse]

I'm not sure exactly what you ask, but for a GPU, using one thread per pixel is probably quite optimal. Many threads are a good thing on a GPU - in fact the numbers of threads should be much higher than the number of physical execution cores (which already is in the hundreds for a modern graphics card). This is due to the latency of many operations on the GPU - while waiting for an operation to finish, the GPU can switch to another thread on the multiprocessor and continue (there is no cost for switching between threads on the same MP). That there will be threads waiting to be scheduled, shouldn't make a difference - the total amount of work there needs to be done is the same no matter how you divide it.

Having said that, using one thread per pixel is also by far the easiest when using GLSL. There is no way to synchronize between threads in GLSL.

The only problem with this approach is, that the drawing of a frame must finish in less than two seconds. Otherwise Windows kill the display driver and restores it (you can get around this by rendering in tiles, though).

Thanks, you got it even my question was wrong... i meant not threads but cores, so rendering more pixels (generating each a thread?) would lead to full usage of all available cores until all threads are finished.

Ok, no disadvantage here.
You only have more control over the GPU when doing less steps, or as you did with tiling.

This question is of course more of a technical interest, the speed is not really bad    

[ker2x]

i'm having fun  

[Syntopia]

Ho, btw, i'm using Fragmentarium on a low-end AMD Fusion EeePC and it works flawlessly (it's slower than my GTX470 of course, but it works!)

Really? I would have thought these were too weak? I still haven't figured out what this AMD Fusion APU thing is, though.

[ker2x]

Ho, btw, i'm using Fragmentarium on a low-end AMD Fusion EeePC and it works flawlessly (it's slower than my GTX470 of course, but it works!)

Really? I would have thought these were too weak? I still haven't figured out what this AMD Fusion APU thing is, though.

The Historical 3D Fractal Mandelbulb, is running at 1.3FPS in continuous render mode.
The AMD Fusion is a graphic chipset embedded on the CPU (with shared memory and so on).

Here is the output of GPU-Z on my system : http://www.techpowerup.com/gpuz/5e8e4/


(and 18FPS on my linux laptop with a GTX460M  )

[DarkBeam]

Okay a question.
Explain me a way to render a fractal only writing the formula and estimating the distance (without having to calc derivs, too hard and long for me ) pwease

[David Makin]

<snip>

Otherwise Windows kill the display driver and restores it (you can get around this by rendering in tiles, though).

Surely there's some way to change that behaviour anyway

[ker2x]

<snip>

Otherwise Windows kill the display driver and restores it (you can get around this by rendering in tiles, though).

Surely there's some way to change that behaviour anyway

You can hack the registry to change this timeout. it's explained in the Fragmentarium FAQ, and i explained the same process some times ago because there is the same problem with OpenCL.
There is also the same problem on linux, unfortunally.