Logo by dainbramage - Contribute your own Logo!

END OF AN ERA, FRACTALFORUMS.COM IS CONTINUED ON FRACTALFORUMS.ORG

it was a great time but no longer maintainable by c.Kleinhuis contact him for any data retrieval,
thanks and see you perhaps in 10 years again

this forum will stay online for reference
News: Did you know ? you can use LaTex inside Postings on fractalforums.com!
 
*
Welcome, Guest. Please login or register. October 26, 2020, 05:43:19 PM


Login with username, password and session length


The All New FractalForums is now in Public Beta Testing! Visit FractalForums.org and check it out!


Pages: [1] 2 3   Go Down
  Print  
Share this topic on DiggShare this topic on FacebookShare this topic on GoogleShare this topic on RedditShare this topic on StumbleUponShare this topic on Twitter
Author Topic: (bi directional) path tracing a mandelbulb  (Read 6761 times)
0 Members and 1 Guest are viewing this topic.
ker2x
Fractal Molossus
**
Posts: 795


WWW
« on: August 12, 2011, 01:10:21 PM »

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 :


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.
Logged

often times... there are other approaches which are kinda crappy until you put them in the context of parallel machines
(en) http://www.blog-gpgpu.com/ , (fr) http://www.keru.org/ ,
Sysadmin & DBA @ http://www.over-blog.com/
A Noniem
Alien
***
Posts: 38


« Reply #1 on: August 12, 2011, 01:34:17 PM »

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.
« Last Edit: August 12, 2011, 01:36:13 PM by A Noniem » Logged
ker2x
Fractal Molossus
**
Posts: 795


WWW
« Reply #2 on: August 12, 2011, 01:44:37 PM »

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. smiley
Logged

often times... there are other approaches which are kinda crappy until you put them in the context of parallel machines
(en) http://www.blog-gpgpu.com/ , (fr) http://www.keru.org/ ,
Sysadmin & DBA @ http://www.over-blog.com/
lycium
Fractal Supremo
*****
Posts: 1158



WWW
« Reply #3 on: August 12, 2011, 02:09:22 PM »

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 ?

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  grin
Logged

Jesse
Download Section
Fractal Schemer
*
Posts: 1013


« Reply #4 on: August 12, 2011, 03:32:20 PM »

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  smiley
And anti aliasing is already included, so you dont need to downscale the image afterwards...
« Last Edit: August 12, 2011, 04:00:10 PM by Jesse » Logged
ker2x
Fractal Molossus
**
Posts: 795


WWW
« Reply #5 on: August 12, 2011, 03:54:50 PM »

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

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 ?
Logged

often times... there are other approaches which are kinda crappy until you put them in the context of parallel machines
(en) http://www.blog-gpgpu.com/ , (fr) http://www.keru.org/ ,
Sysadmin & DBA @ http://www.over-blog.com/
ker2x
Fractal Molossus
**
Posts: 795


WWW
« Reply #6 on: August 12, 2011, 04:46:47 PM »

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).
« Last Edit: August 12, 2011, 04:52:09 PM by ker2x » Logged

often times... there are other approaches which are kinda crappy until you put them in the context of parallel machines
(en) http://www.blog-gpgpu.com/ , (fr) http://www.keru.org/ ,
Sysadmin & DBA @ http://www.over-blog.com/
A Noniem
Alien
***
Posts: 38


« Reply #7 on: August 12, 2011, 06:01:07 PM »

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  grin
Logged
ker2x
Fractal Molossus
**
Posts: 795


WWW
« Reply #8 on: August 12, 2011, 06:02:57 PM »

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  grin

modern GPU have double precision, you know ?  wink
Logged

often times... there are other approaches which are kinda crappy until you put them in the context of parallel machines
(en) http://www.blog-gpgpu.com/ , (fr) http://www.keru.org/ ,
Sysadmin & DBA @ http://www.over-blog.com/
A Noniem
Alien
***
Posts: 38


« Reply #9 on: August 12, 2011, 06:10:16 PM »

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  grin

modern GPU have double precision, you know ?  wink

Not mine. I know recent Nvidia cards have it, but there only a couple of Ati cards that have it.
Logged
Jesse
Download Section
Fractal Schemer
*
Posts: 1013


« Reply #10 on: August 12, 2011, 06:25:10 PM »

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).

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.
 
Logged
lycium
Fractal Supremo
*****
Posts: 1158



WWW
« Reply #11 on: August 12, 2011, 07:41:36 PM »

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 tongue stuck out 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.
Logged

Syntopia
Fractal Molossus
**
Posts: 681



syntopiadk
WWW
« Reply #12 on: August 12, 2011, 07:45:15 PM »

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).

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.

Quote
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.

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.
Logged
lycium
Fractal Supremo
*****
Posts: 1158



WWW
« Reply #13 on: August 12, 2011, 07:50:22 PM »

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.
Logged

ker2x
Fractal Molossus
**
Posts: 795


WWW
« Reply #14 on: August 12, 2011, 08:07:28 PM »

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  grin

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).

Logged

often times... there are other approaches which are kinda crappy until you put them in the context of parallel machines
(en) http://www.blog-gpgpu.com/ , (fr) http://www.keru.org/ ,
Sysadmin & DBA @ http://www.over-blog.com/
Pages: [1] 2 3   Go Down
  Print  
 
Jump to:  

Related Topics
Subject Started by Replies Views Last post
.net based fractal rendering/ray tracing Mandelbulb Renderings JColyer 3 1351 Last post December 10, 2009, 03:50:37 PM
by twinbee
Mandelbulb ray tracing plugin for Photoshop, AfterEffects and QuartzComposer Mandelbulb Implementation « 1 2 3 » subblue 43 15257 Last post March 01, 2010, 04:17:03 PM
by KRAFTWERK
old school ray tracing Images Showcase (Rate My Fractal) taurus 0 882 Last post June 23, 2012, 11:57:37 AM
by taurus
Real-time path tracing engine Non-Fractal related Chit-Chat Kali 6 1032 Last post April 10, 2013, 01:53:50 PM
by kram1032
Mandelbulb directional distance Programming TruthSerum 3 1057 Last post July 07, 2014, 12:24:30 AM
by David Makin

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines

Valid XHTML 1.0! Valid CSS! Dilber MC Theme by HarzeM
Page created in 0.211 seconds with 27 queries. (Pretty URLs adds 0.011s, 2q)