Welcome to Fractal Forums

I'm learning raytracing now, to render high quality mandelbulb.
i grabbed and studied some code and (bi-directional) path tracing, as well as photon mapping, is  surprisingly easy to understand with conventional shape like sphere and plane.

However... what about a mandelbulb ?
A "realistic" mandelbulb doesn't have "normal" and should absorb all light it receive, isn't it ?
I understand that we can fake/estimate the "normal" of a "point" of a mandelbulb (and it doesn't have this problem)

I don't want to render a "shiny" mandelbulb, but something that look much more "mat" like this one :
(http://www.skytopia.com/project/fractal/new/q85/fossil-valley-small.jpg)

Considering the very complex shape of a mandelbulb, photon mapping doesn't look like a good idea to me.
Do you think it's sane to try to implement path tracing ( http://en.wikipedia.org/wiki/Path_tracing ) to render a mandelbulb ? or should i forget about it ?
(i'll use openCL, of course, to speed up the rendering)

Thank you.

You can calculate the normal (it's not really fake, you just estimate it) depending on the surrounding area. I use this in my own openCL renderer of which you have the code (in my own topic) I used http://blog.hvidtfeldts.net/index.php/2011/08/distance-estimated-3d-fractals-ii-lighting-and-coloring/ to do this, even though you could do it with a z-buffer as well.

I'd just recommend using the common shading algorithms like Lambertian and Blinn-phong. It gives nice results and it's pretty simple and fast. If you got everything working you could try using different shading algorithms as well, there are a couple interesting not frequently used algorithms out there which might be worth looking at (Cook-Torrance, Oren–Nayar, etc)

Personally I'm not familiar with photon mapping and path tracing, but from what I read on wikipedia is that you need the information of the entire 3d world (which you don't have when rendering fractals with a distance estimation algorithm) and it is very, very slow.

I did quite a bit of lightning last year, so I know how it works. You won't get such a smooth surface as on that picture, since single precision is too limited.

i'm not sure that you really really need the information of the entire 3d world.
Instead of path tracing, well, it must be "path marching" ?
(And yes, that require probably billions of path...).

Perhaps photon mapping could work after all...
i'll try quick and dirty implementation this weekend (3 days, yay !), as well a the solution you proposed. :)

as it happens, the very first perspective 3d mandelbulb render had full global illumination, rendered with unbiased path tracing and metropolis sampling on top: http://www.fractalforums.com/3d-fractal-generation/true-3d-mandlebrot-type-fractal/15/

that was back in 2007, and yes, it was outrageously slow! i still want to re-do it with indigo renderer, using the gpu for doing the intersection computations; it's written up on our whiteboard here  ;D

This is surely possible on GPU, even on CPU you can do that with not that slow formulas.
The basic concept is not very complicated and 'pathtracing' is just used for the common calculation from camera to bulb, you just have to extend it for general traces.
It might be a factor of 100 slower or even more, depends very much on lighting and render method, but if you got say 5 seconds per frame on GPU, then 10 minutes for a superb image is very acceptable  :)
And anti aliasing is already included, so you dont need to downscale the image afterwards...

thank you very much !
that help me a lot... and confuse me :)

At first, i tought about a mandelbulb within and empty sphere and an omni directional light.
Hum... that's the worst possible case ! (as any ray will participate to the rendering, isn't it ?).

Now i think about a single infinite plane, a mandelbulb floating above it, and an uni directional light (a sky).
I think about starting with only greylevel, no color.

Now.
We know exactly where ie the camera and we know where is the light and can quickly find if, given a single point :
- there is a direct path to the camera
- there is a direct path to the light source

If there is no direct path between the point and the light source, the point will be black and its brightness will be (eventually) determined by bouncing ray.
If there is a direct path between the point and the light source (which can be easily determined by raymarching in the inverse direction of the unidirectional light. if it doesn't hit the mandelbulb after marching up to a radius of 2 from the center of the mandelbulb, then it goes up to the sky)) the brightness of this point will be at least the brightness given by the light source (according to the normal of this point).

Then, from this point, we bounce more or less randomly (well, in a hemisphere according to the normal) and do the same test again until maxBounce.

Do that make sense ?

Mmm wait, something is wrong.
if there is no "specular" (and i don't want any). does the brightness varie according to the direction of the ray against the normal ?

edit : thank you wikipedia : An illuminated ideal diffuse reflecting surface will have equal luminance from all directions in the hemisphere surrounding the surface (Lambertian reflectance).

The method I described is the same as used in games and other realtime stuff and it's very fast (and you can still make really nice images with it) If you want to go for speed (which is the primary reason people program for the gpu nowadays) that would the way to go. If you want perfect pictures the other methods described in this topic are better (personally I only had experience with the realtime shading algorithms) If you really want the perfect images you should stick on the cpu in my opinion because it just has a lot less limitations (single precision is a bitch) and it's a lot easier to debug. One of the reasons I'm writing in openCL is because I want more interaction than current programs, which you throw away if you implement complicated lightning and stuff. Just my opinion ofcourse, if you make the same decisions as me you'll probably end up with the same program  ;D

modern GPU have double precision, you know ?  :dink:

Not mine. I know recent Nvidia cards have it, but there only a couple of Ati cards that have it.

Yes, monte carlo methods calculates then a random vector from the normal to the hemisphere and traces this ray until an object is found, then this is done again from this normal (and the lightamount, init with 1, is multiplied by the color of the object) until a lightsource or the light from the hemisphere is found.
You can guess that a lightsource with an huge bigger lightamount than the hemisphere background will give some bright random spots in the image when the lightwas was accidently hit, so a huge amount of rays would be needed to smooth that out.
Bidirectional pathtracing is in this case much faster, or metropolis light transport, where generally the traces with big lightamounts are calculated more often.  Also a variation calculation of a pixel while calculating rays, can be used to investigate how many rays you need for this pixel to get a desired noise amount.

The GPU thing:  OpenCL can be used also for double precision if the card does not supports it, this should be still faster than a common c compiler, for what i read.
 

Even if you're using single precision, writing code for a GPU just as you would for a CPU is a bad idea. The architecture is different, and heavy branching alone can effectively turn your 800mhz GPU into a weak 800mhz CPU with just a few threads. If you don't know why, then you don't understand GPU architecture, and I'd suggest taking a look at how they work before claiming 100x etc :P There's definitely massive potential with GPU for compute-limited workloads (fractals are pretty ideal since they use very little memory), but realising this potential in practice requires quite some care.

As a point of comparison, in Indigo Renderer the GPU can be used to accelerate such ray tracing queries, but sometimes it's not much faster than using just the CPU (which has huge caches and excellent branching "agility"). We went with a simple implementation first since it needed to work with both CUDA and OpenCL, however now we can go back and better adapt our algorithms to better exploit the new system.

Diffuse light intensity depends on the angle between the surface normal and the light source - it is normally set proportional to cos(angle). It is not dependent on the viewer position (like specular), though.

Notice that the definition of luminance divides the light power with cos(angle) - making diffuse light constant in luminance.


Double precision support is optional in OpenCL 1.1 (chapter 9.3 in the spec). I'm guessing it is only implemented on architectures with decent hardware support.

Hmm I don't think the definitions you've given are correct, Syntopia.

In global illumination, the (surface) rendering equation describes light transport (in a vacuum). Roughly speaking it's L_out = L_emit + integral over all angles { R(L_in) cos(theta) }, and in this setting a diffuse BRDF R is just a constant k / pi, with k in [0, 1).

Luminance is a completely different quantity, which is perceptual in nature rather than a basic physical quantity.

The most commons performance pitfall i know about (for nvidia hardware, but it probably appliy to ATI too, with different numbers ) :
- Non coalesced acces to the global memory (800 cycles !), this is absolutly insane. So insane that performance metrics are mostly based on this problem (well, in fact it is "memory bandwith usage" but it is totally related to the memory latency).

- conditional branching : All "warps" (in the single works group ? i'm not sure) execute the same code at once. If your code path diverge too much then you may have most (or All-1) warps waiting for others warps stuck in a very long loop. (which is common with fractals with very high iteration count).

- Read-after-write register latency (~25 cycles). On the CPU you're used to store some intermediate result in a variable if you are going to use this intermediate result a few times. This is not always a good idea on the gpu. Sometimes bruteforce works better  ;D

A NVidia GPU with 512 threads can do up to 512 Floating point Addition and Multiplication per cycle in the best scenario (FMAD) . So even a 25 cycles latency can be considered as "high" (and 800 cycles is pure insanity).

I'm not talking any global illumination here, but just about the Lambertian reflection that ker2x mentioned (http://en.wikipedia.org/wiki/Lambertian_reflectance). As in Phong shading (http://en.wikipedia.org/wiki/Phong_reflection_model), the diffuse component depends on the angle: "The reflection is calculated by taking the dot product of the surface's normal vector, \mathbf{N}, and a normalized light-direction vector, \mathbf{L}, pointing from the surface to the light source".


Yes, that was my point: By the definition (http://en.wikipedia.org/wiki/Luminance) the luminance is proportional to the luminous power divided by cos(angle). Hence the two terms cancel, and diffuse reflection becomes isotropic, right?

Ha.. if my 2 references about fractals and raytracing disagree, i'm in big trouble  :embarrass:

Please check the thread topic...

Yes, and from that article you will see, as ker2x said, that it is constant, no cosines.

The cosine comes from the rendering equation, which is what you are approximating when you do some kind of lighting; all rendering algorithms can be considered in the common framework of the rendering equation, which fully expresses all possible light interactions (under the assumptions of classical optics, no quantum phenomena).

The Phong reflection model they are discussing assumes purely directional lights, and it doesn't take global illumination into account. For a single directional light source, without considering indirect illumination, the rendering equation reduces what you see there.

But we ARE discussing global illumination, and in this context that simple shading model doesn't apply.

Nope, you're confusing a few things here:

1. The diffuse BRDF is isotropic, because it is a constant and doesn't have a cosine term.
2. By the definition of luminance, which you linked, it is a perceptual measure, i.e. it has to do with the human visual system, not physics.

"Luminance is a photometric measure" -> "Photometry is the science of the measurement of light, in terms of its perceived brightness to the human eye.[1] It is distinct from radiometry, which is the science of measurement of radiant energy (including light) in terms of absolute power; rather, in photometry, the radiant power at each wavelength is weighted by a luminosity function (a.k.a. visual sensitivity function) that models human brightness sensitivity."

The perception of light is a separate issue to doing the physical computations.

Wow, this discussion is getting heated :-)


As I read ker2x, he talked about tracing a path from the camera to the fractal surface hit point, and from the fractal surface hit point to a point light source. This is simple ray tracing, with no global illumination. If he wants to estimate the diffuse reflection from the point light, he must multiply the light intensity by the cos(angle)-factor between the surface normal and point light direction (as the only formula from the link states). The same goes if he samples multiple lights from the hemisphere - the normal angle / light direction must be taken into account (otherwise you could rotate the hemisphere without changing lighting!)

I'm not questioning your expertise on raytracing - personaly I know nothing about global illumination - but I really think a simple shading model like Blinn-Phong will be the best first step for ker2x :-)

Have a nice evening!

Ha ! i understand now :)

That is indeed what i described in one of my post (yes, i reinvented raytracing :p ), but not what i was willing to do.
Sorry about the confusion and the discussion it created. (i'm confused myself between all the differents technics)

what i want to do is described here : http://en.wikipedia.org/wiki/Path_tracing and here http://en.wikipedia.org/wiki/Metropolis_light_transport which is the technic used by lycium, explained here : http://www.fractalforums.com/3d-fractal-generation/true-3d-mandlebrot-type-fractal/15/

Sorry again. (in some way, you're both correct)

Well, not need to apologize :-) Nothing wrong with your questions - we just misunderstood each other.

Btw, you said you did manage to get an OpenCL prototype running. Out of curiosity, how fast it is to render a frame?

No no, not at all.
i wrote that with opencl http://www.fractalforums.com/programming/the-simpliest-naive-bruteforce-code-for-mandelbulb/15/ (the the result at the bottom of the page) but it's just an impletementation the dumbest possible raymarching  technic.

Since I have an openCL renderer (well it's more as you said a prototype) as well I can answer your question as well. Rendering a mandelbox (using single precision) takes about 2-3 seconds at 1280x1024 on an ati 4350.

Have you also tried running the OpenCL code on the CPU using Intel's OpenCL SDK?

And is your ATI card capable of running double precision in OpenCL? (emulated or otherwise)

Interestingly, AMD's CPU OpenCL implementation seems to be faster than Intel's.

I have an amd proc and the amd sdk has support for cpu, so why use intel's sdk  :dink:. Rendering on the cpu is ~4 times slower (athlon 64 x2 @2.2ghz). I hope to use the gpu and cpu simultaneously someday to speed up rendering even further. My setup isn't that fast and new. I wasn't really into computers yet when I bought this thing  ;D

And no my card doesn not support doulbe precision. It was €25,-, supports only openCL 1.0 (the radeon hd 4xxx series was never designed with openCL in mind), so I'm lucky to even run openCL  :embarrass: I've done a bit of research on which cards support double precision. Almost all recent nvidia cards support it, ati is a different story however. The top models of the 4xxx and 5xxx series support double precision, 4xxx only supports openCL 1.0 and lacks some useful extensions, leaving you only with the 5xxx series for the serious stuff. I don't know what AMD did for the 6xxx series, but somehow only the 6950 and 6970 support double precision. The cheapest openCL 1.1/double precision ati gpu costs €100,- (radeon hd 5830) It's a huge surprise for me the cheapest double precision capable 6xxx card is the 6950 which costs a whopping €190,-.

If you want to see which ati cards support double precision go to
http://developer.amd.com/sdks/AMDAPPSDK/assets/AMD_APP_SDK_Getting_Started_Guide_v2.5.pdf
and skip to supported devices

I'm not sure whether it is emulated or native, I think that in the 4xxx series it is emulated, but I'm not sure. I read somewhere that nVidia used to do this as well.

Not sure if you referring to me, but i agree with you that the way of coding is very important, same with CPU but with GPU it is more critical what you can see on the amount of different memory types in OpenCL... so make the memory usage as local as possible (as all the code).
But i had just a quick look at OpenCL, did not used it at all.

Btw, would never claim a 100x speed increment for GPU, just a ~100x slower rendering on monte carlo compared with phong lighting.
(if you mixed this up, but doesnt matter at all)

Oh, I did indeed misread that  :-X Thanks / sorry!

Please also excuse my reflexive distrust of such numbers as GPU speedups, too. On a related note, an excellent tongue-in-cheek guide to making GPU performance claims: http://www.walkingrandomly.com/?p=3736

Hmm, would be cool to know if double precision is supported anyways or only with a decent card.
I thought OpenCL (1.1) would use the CPU, maybe SSE2, if the GPU doesnt supports it... somebody who knows the answer?

Geeks3D GPU Caps Viewer (http://www.ozone3d.net/gpu_caps_viewer/) allows you to view OpenCL information (OpenCL / More OpenCL Information...).
In order to support double precision the CL_DEVICE_EXTENSION 'cl_khr_fp64' must be present. Otherwise code will refuse to run.

For my Geforce 8800 GTX (with drivers dating from 1-7-2011) there is no double precision support :-(
My Intel OpenCL implementation does support it though (no big surprise here).

I don't think there will automatically fallback to CPU, if the GPU does not support doubles - however an application could check the available OpenCL implementation on a system, and choose one with double support.

Notice that GPU Caps Viewer also comes with a 4D Quaternion Julia demo in OpenCL which is useful for speed comparisons!

Update: I tried changing some OpenCL code to double precision, and my Nvidia driver does not seems to check the extension - it just fails compilation. The Nvidia the compiler complained with: 'warning: Double is not supported. Demoting to float' suggestion that doubles would be converted to floats. However, the compiler failed anyway with a message: 'Instruction 'cvt' requires SM 1.3 or higher, or map_f64_tof32 directive'

Thank you very much, Syntopia!

I just realized that OpenCL is a standard and there are several different implementations of it like you told.
So i guess the Intel implementation is only using the CPU whereas the Nvidia is only using GPU.

I will test the GPU caps viewer tomorrow, i had also a 8800 onboard and replaced it with a 9500 GT recently because i had some memory problems and wanted to test if that would help.  I don't think that the 9500 has double precision support, had choosen it more for low power consumption to fit in my system.

Double precision on NVIDIA require ">1.3 Compute capabilitiy".
The G8* serie (eg : 8800) support only up to 1.1
1.3 begin with GT20051.3) & GF100(2.0).

I high recommand buying a GTX460 or "better".
Beware of the meaning of "better" :
- the 460 (i have a 460M on my laptop) is much much better than the 465.
- the 470 (which i have on my desktop) is more powerfull than the 460 in "raw power" but it's a GF100 chipset (same as the GTX 480) with "2.0 Compute capability". while the GTX460 (less raw power) support "2.1 Compute capability".


The 8800GTX (i had this one before it die) is the oldest card supporting CUDA/OpenCL.

You may want to take a look at http://en.wikipedia.org/wiki/CUDA to learn more about Compute Capability, Card name, Chipset Version :)

 

Yes, I was thinking of getting something like a GeForce GTX 560 Ti. Unfortunately, that means I probably have to update my PSU.

One annoying thing is that these Fermi-based cards (the 400 and 500 series) were designed to run double precision at half the speed of single precision. But the consumer-grade GeForce cards are crippled to run double precision at a quarter of the true speed (resulting in 1/8 of single precision). Only the expensive Tesla cards run double precision without artificial restrictions :-(

Yup, i upgraded my PSU when upgrading from 8800GTX (i wasn't sure it was needed, but it was an old one, so it can't hurt).
If you have an old motherboard (like mine) with PCI-Express 1.0 instead of 2.0, it will works, but you won't have the full bandwidth. (it still works perfectly without troubles)

My 9500 GT does only knows CUDA, no OpenCL at all.  (OnBoard is a 8200, not a 8800 of course. Mixed it up.)
So i installed the 'AMD-APP-SDK-v2.5-Windows-32' package: 'ATI Stream SDK to enable OpenCL on both AMD/ATI GPUs and CPUs'
and the GPU Caps Viewer Quaternion demo run on CPU at 6 FPS (AMD Athlon(tm) II X4 620 Processor).
What is it on a GPU?


Does Fragmentarium already support OpenCL (single precision) in the current 0.8 version or do you just testing it currently?

The cool thing is of course the online compiling, and Delphi7 or higher can also get use of OpenCL... might be a good start for someone who wants to go with double precision (OpenCL, not Delphi).

On my system it is 5 FPS on the CPU, and 35 on the GPU (I wrote a blog post with some more details about CPU/GPU speeds some month ago:
http://blog.hvidtfeldts.net/index.php/2011/02/gpu-versus-cpu-for-pixel-graphics/)


Fragmentarium is GLSL only at the moment, and I don't think I'll change in the near future. But I'll probably experiment a bit with OpenCL.

Btw, I noticed that the CUDA Mandelbrot SDK example contains functions for doing emulated doubles using floats - on my machine this was only ~10x slower, which is not bad for an emulated library.