Title: Inigo Quilez's brute force global illumination Post by: eiffie on November 15, 2012, 06:04:29 PM I put together Quilez's code from his article on brute force path tracing and put it in a Fragmentarium script.
I probably should have attached it here but you are only a couple clicks away :) I attached it in this thread... http://www.fractalforums.com/programming/global-illumination-(article)/ (http://www.fractalforums.com/programming/global-illumination-(article)/) It runs in continuous mode and may cause some issues on some cards - I only tested it on an Nvidia. Its a short and simple script so I hope others will feel free to improve it. (http://www.fractalforums.com/index.php?action=dlattach;topic=13587.0;attach=8162;image) Title: Re: Inigo Quilez's brute force global illumination Post by: cKleinhuis on November 15, 2012, 06:46:31 PM Love global illum so i love your pic :)
Title: Re: Inigo Quilez's brute force global illumination Post by: knighty on November 15, 2012, 08:22:47 PM Awesome!
Title: Re: Inigo Quilez's brute force global illumination Post by: cKleinhuis on November 15, 2012, 08:42:13 PM render time ?
:) Title: Re: Inigo Quilez's brute force global illumination Post by: knighty on November 15, 2012, 09:16:49 PM Something like 5 to 10mn on a crappy GF9400GT at 1024x1024 resolution and 100 steps (I used tile rendering). It should take seconds to render on a modern graphics card.
Title: Re: Inigo Quilez's brute force global illumination Post by: Syntopia on November 15, 2012, 09:25:48 PM Great stuff, Eiffie!
I'm playing around with a Path-tracer myself, and have been spending some time on stratification and importance sampling - it might be able to speed up the rendering a bit. I really love the soft lighting from global illumination. Title: Re: Inigo Quilez's brute force global illumination Post by: eiffie on November 16, 2012, 06:16:20 PM It turned out to be very easy to add transparency with only a few changes. At first it still had solid shadows for transparent objects so I changed the shadow ray march to refract as well and I got some nice little caustics. Way better than I expected! This is fun :)
http://youtu.be/ymc3arrjDNQ http://www.youtube.com/watch?v=ymc3arrjDNQ&feature=player_detailpage&list=UUg6IPCR4o4ITimzZG_8e_5Q Title: Re: Inigo Quilez's brute force global illumination Post by: subblue on November 16, 2012, 07:48:40 PM It turned out to be very easy to add transparency with only a few changes. At first it still had solid shadows for transparent objects so I changed the shadow ray march to refract as well and I got some nice little caustics. Way better than I expected! This is fun :) http://youtu.be/ymc3arrjDNQ This stuff is excellent! Very good results for such a small renderer really. I can only run it at 2x preview res on my iMac, but impressive even so :) Title: Re: Inigo Quilez's brute force global illumination Post by: M Benesi on November 17, 2012, 09:44:22 AM Something like 5 to 10mn on a crappy GF9400GT at 1024x1024 resolution and 100 steps (I used tile rendering). It should take seconds to render on a modern graphics card. I'm jealous! I've got an 8600m... mobile!!!Title: Re: Inigo Quilez's brute force global illumination Post by: cKleinhuis on November 17, 2012, 01:07:33 PM woot! i love caustics!!!!!!!
Title: Re: Inigo Quilez's brute force global illumination Post by: Softology on November 19, 2012, 11:52:12 PM Very nice.
I am trying to use the code as a GLSL shader outside Fragmentarium. The problem I am having is how to accumulate each "pass" into a smooth image? At the moment I get an output like the following that flickers around but never seems to smooth out into a final image... (http://farm9.staticflickr.com/8063/8201514204_d69cdc1f4c_o.png) Each pass I am averaging the returned color with the current pixel color. How does the continuous mode accumulate the previous pixel results? If I render a single pass it looks identical to the Fragmentarium results with one pass, so I am assuming it must be the way I am averaging the pass colors. Thanks, Jason. Title: Re: Inigo Quilez's brute force global illumination Post by: marius on November 20, 2012, 12:24:24 AM Each pass I am averaging the returned color with the current pixel color. How does the continuous mode accumulate the previous pixel results? Your approach assigns 50% weight to the most recently computed pixel. Hence that will dominate and your frame mimics a single shot. I figure you have to track the running total and divide by N to have the samples have equal weight? Title: Re: Inigo Quilez's brute force global illumination Post by: Softology on November 20, 2012, 01:04:31 AM I figure you have to track the running total and divide by N to have the samples have equal weight? Geez I feel stupid. So obvious. Thanks. Now I am starting to get the sort of results I expect. (http://farm9.staticflickr.com/8488/8201699598_85623ac2ce_o.png) Jason. Title: Re: Inigo Quilez's brute force global illumination Post by: cKleinhuis on November 20, 2012, 07:37:05 AM yay, this script runs nicely out of the box ;)
too bad it is relying on the DE formulas ;) ;) ;) dont really understand the concept-of-re-rendering the same buffer in fragmentarium, is it some kind of render-to texture feature and then re-use the output of a previous step !? and another thing i am interested in, HOW DO YOU DO RANDOM ?! by a simple map !? or using built in perlin noise ?! Title: Re: Inigo Quilez's brute force global illumination Post by: cbuchner1 on November 20, 2012, 11:58:53 AM Oh my god. You're really on to something. Caustics based on procedurally generrated fractals. W00t!
UPDATE: at work we're soon going to have a laptop with GT 680M graphics (1388 shader cores or so). The fastest nVidia tesla cards have 2688 cores, but they don't do graphics AFAIK. The GTS 250 that I am on now only has 128 of 'em. So keep those scripts coming. We need material for testing and benchmarking ;) BTW, would anyone know if SLI can accelerate OpenGL applications? Does it need specific SLI profiles for the application? Title: Re: Inigo Quilez's brute force global illumination Post by: eiffie on November 20, 2012, 04:42:35 PM First I'll answer a few questions:
Softology - You got it (thanks marius!) cKleinhuis - Yeah its like render to texture except its called a frame buffer (more generic term). Outside of Fragmentarium you could also run the script as multiple passes with alpha blending (disable the depth field) then no need to set up a buffer. You have to fake random numbers in glsl - basically fract(sin(lastRandom*ridiculouslyLargeNumber)). Now I have a question. Inigo skimmed over a few details so I had to guess the following: Code: vec3 cosineDirection(in vec3 nor) coneDirection should return a random direction within a cone. I faked this by using either a flat disk or hemisphere pushed in the direction of the normal but there must be a better way. If I get the polar coordinates and "jitter" them randomly will that be uniform?? Finally since you read this far you get a treat: Emissive Material! I have been using this for awhile and really like it. It allows you to fractally place lights all over the scene without added tons of lighting calculations. Its a fake but a nice one:) http://www.youtube.com/watch?feature=player_detailpage&v=gP6nqhBmF0k (http://www.youtube.com/watch?feature=player_detailpage&v=gP6nqhBmF0k) Title: Re: Inigo Quilez's brute force global illumination Post by: marius on November 20, 2012, 06:30:57 PM BTW, would anyone know if SLI can accelerate OpenGL applications? Does it need specific SLI profiles for the application? I finally assembled a machine with two 7970s at 1GHz. Took some liquid cooling to keep it from melting down :-\ SLI/crossfire has its issues as you might imagine. It tends to only kick in on full-screen and if the system thinks it has a profile for your application. At the moment I rename boxplorer.exe to SeriousSam.exe ;D But then it works for boxplorer, a SDL/opengl app. And scales near linearly, all gpus at 100%. You still have to adjust code for it: split workload in multiple parts etc. At the moment it still drops back to single gpu performance if I enable a post-render fake-DoF pass; need to look into that. Most of the fragments with decent DE run at 30 fps or more at 1080p, single precision that is. Title: Re: Inigo Quilez's brute force global illumination Post by: eiffie on November 20, 2012, 06:49:32 PM I get jealous of these awesome machines. I wrote the last script on my second machine with a motherboard GPU and 32 temporary registers. It worked but took 30 seconds per frame! :)
Title: Re: Inigo Quilez's brute force global illumination Post by: cbuchner1 on November 20, 2012, 07:24:49 PM 30 seconds per frame or not. You coded a Mandel-Lightbulb. :siren: :siren: :siren: *faints* Title: Re: Inigo Quilez's brute force global illumination Post by: knighty on November 20, 2012, 07:30:20 PM If I get the polar coordinates and "jitter" them randomly will that be uniform?? I can't answer your question but I think you may find these interresting and useful:http://www.cs.virginia.edu/~jdl/importance.doc http://madebyevan.com/webgl-path-tracing/ (and the code source: http://madebyevan.com/webgl-path-tracing/webgl-path-tracing.js ) Title: Re: Inigo Quilez's brute force global illumination Post by: Syntopia on November 20, 2012, 09:02:52 PM Quote cosineDirection I get. Just a random direction in the hemisphere with the pole "nor". coneDirection should return a random direction within a cone. I faked this by using either a flat disk or hemisphere pushed in the direction of the normal but there must be a better way. If I get the polar coordinates and "jitter" them randomly will that be uniform?? For a cone direction on a hemisphere, I use the following in Fragmentarium in sample e.g. a sun-like light source: Code: vec3 getSample(vec3 dir, float extent) {It is formular 34 in http://people.cs.kuleuven.be/~philip.dutre/GI/TotalCompendium.pdf, just adapted to a coordinate system aligned with the 'dir' direction. But you shouldn't use the above formula for glossy specular reflectance. I can see that IQ suggests it, but it is really a hack - you are effectively sampling using a box distribution function, whereas the phong reflection uses a cosine-power distribution. You need to sample the full hemisphere and weight the samples according to dot(reflectedVector, sampleDirection)^Power. Since this is slow, you will want to use importance sampling, and sample according to the cosinus-distribution. Notice, that you should not multiply by the samples by the dot-product-power term if you do this. Here is a cosine-power distribution sampling function: Code: vec3 getSampleBiased(vec3 dir, float power) { Btw, I think that IQ's cosineDirection means a direction chosen according to the power-1 cosinus distribution (because the diffuse light has a cos(normal, sampleDirection) weight), and not a random direction. The code above is part of the 'Theory/Convolution.frag' example in Fragmentarium. This fragment can be used to derive precalculated specular and diffuse light maps for IBL lightning. I plan to write a blog entry with more details of this soon. Title: Re: Inigo Quilez's brute force global illumination Post by: eiffie on November 20, 2012, 09:19:44 PM Ah thanks a bunch now I'm learning something!
Title: Re: Inigo Quilez's brute force global illumination Post by: eiffie on November 21, 2012, 06:01:44 PM OK now I have specular light working but just as a sanity check maybe someone can give feedback on this light model.
Using Snytopia's functions for getSample and getSampleBiased I am getting light from... For scattered light searchDirection=getSample(surfaceNormal,1.0)//this is the cosine weighted sample For direct lighting searchDirection=getSample(lightDirection,extent)//where extent is approx 0.001 for soft shadows from a sun-like source Specular lighting searchDirection=getSampleBiased(reflect(rayDirection,surfaceNormal),specularExponent)//checking for near perfect reflections searchDirection is then used for a shadow check This picture is a comparison of the cheap version of specular (left) and then the way Syntopia suggested. Thanks for the help on this guys. Now I'm going back to build a fast raymarcher with the same fake caustics in it:) Title: Re: Inigo Quilez's brute force global illumination Post by: Syntopia on November 21, 2012, 11:06:29 PM For scattered light searchDirection=getSample(surfaceNormal,1.0)//this is the cosine weighted sample For direct lighting searchDirection=getSample(lightDirection,extent)//where extent is approx 0.001 for soft shadows from a sun-like source Specular lighting searchDirection=getSampleBiased(reflect(rayDirection,surfaceNormal),specularExponent)//checking for near perfect reflections The directions are probably right, but ther are more to importance sampling than just biasing the samples towards the most important regions - you have to take the distribution your sampling with into account. So the samples must be weighted according to the reciprocal of their chance of being picked, I think. I still have some trouble with my code so I can't share it yet, Title: Re: Inigo Quilez's brute force global illumination Post by: eiffie on November 24, 2012, 06:10:55 PM I admit as soon as you do release your code I will steal most of it :) but I am having fun screwing around until then.
I actually thought it went the other way. If you just chose uniformly random rays you would have to weight them based on their likelyhood of actually arriving at the camera (remember we are doing this all backwards the rays really come uniformly from the lights and only a few hit the camera). But I admit my brain has reached its limit here. Title: Re: Inigo Quilez's brute force global illumination Post by: richardrosenman on November 24, 2012, 11:55:55 PM Amazing stuff here guys!
-Rich Title: Re: Inigo Quilez's brute force global illumination Post by: Syntopia on November 25, 2012, 08:13:12 PM I admit as soon as you do release your code I will steal most of it :) but I am having fun screwing around until then. I actually thought it went the other way. If you just chose uniformly random rays you would have to weight them based on their likelyhood of actually arriving at the camera (remember we are doing this all backwards the rays really come uniformly from the lights and only a few hit the camera). But I admit my brain has reached its limit here. I'm not an expert here, but as I see it, we have to integrate over all light directions (and paths) reaching the camera, e.g: We can do this by taking a finite number of uniform samples, and estimate an approximation of the integral as the average sample value times the volume we are integrating over: Now, this only holds if we are choosing samples uniformly. If we biased our samples to regions with high values, we would get too high a value for the integral. However, sometimes we know that the contributions follow a very narrow distribution (e.g. specular lights). Therefore we have to weight the samples according to the reciprocal distribution: In Fragmentarium, I multiply the weights to the color values before accumulating them, and keep track of the sum of the weights in the alpha channel. But there are some issues - in particular when the distribution goes towards zero, I get very high terms, and noise pixels. The formulas above were pasted from: http://en.wikipedia.org/wiki/Monte_Carlo_integration, where this more discussion. Title: Re: Inigo Quilez's brute force global illumination Post by: Syntopia on November 25, 2012, 10:53:32 PM After a bit of experimentation, I've found out that I shouldn't try to sum the of the weights in the alpha-channel - instead I should calculate the integral of the PDF (Probability Density Function), and normalize by that. It is explained here: http://www.rorydriscoll.com/2009/01/07/better-sampling/ He doesn't derive the normalization for the cosine-powered distribution, but if you do the integral, you end up with: I've checked it, and it works - it converges much faster when using the biased (importance sampled) form. Unfortunately the gain is largest for high powers, so not much is gained for the diffuse term. Title: Re: Inigo Quilez's brute force global illumination Post by: cKleinhuis on November 25, 2012, 10:59:38 PM i need to break in here:
people, why are you all relying on a random integral aproaching method ? as a starter, the directions from that a light source can actually come should be somehow fractally approximated, with the bonus of not having to search the whole semi-sphere obtaining more realistic results ;) ?? i mean, dudes we are in the fractalforums here, and i wonder why the solution for the beloved rendering equatuion that lies behind the global illumination renderings couldnt be modified similar to what i suggested before Title: Re: Inigo Quilez's brute force global illumination Post by: eiffie on November 27, 2012, 04:43:27 PM Since I know Syntopia will arrive at the best physical model given time I now feel free to just "wing it". I re-wrote the engine from scratch since I realized all the shadow checks were redundant. The code is much faster now and the results are better. It still takes time to converge but fast enough to create small videos...
http://youtu.be/iMBKRdGI6Q4 (http://youtu.be/iMBKRdGI6Q4) ...attached script is up to date as of: June 13, 2013 Title: Re: Inigo Quilez's brute force global illumination Post by: cbuchner1 on November 27, 2012, 08:06:25 PM Thanks Eiffie for sharing the code. Title: Re: Inigo Quilez's brute force global illumination Post by: Softology on November 27, 2012, 09:39:21 PM Thanks Eiffie for sharing the code. Yes, many thanks Eiffie! That is such a brilliant shader to experiment with and build on. :thanks1: Title: Re: Inigo Quilez's brute force global illumination Post by: Syntopia on November 27, 2012, 10:09:09 PM http://youtu.be/iMBKRdGI6Q4 (http://youtu.be/iMBKRdGI6Q4) Awesome stuff, Eiffie Title: Re: Inigo Quilez's brute force global illumination Post by: eiffie on November 29, 2012, 07:19:49 PM I made a few small corrections to the code in my last post since I had gloss working backwards. Also added the fresnel equations for refraction/reflection which sped up the convergence. I still need to fix the fog (no fog in reflections yet).
I put the code in the last post just to be confusing :hmh: Even fast enough now for some short 720p videos. http://www.youtube.com/watch?v=CuHn9HdQQHE&feature=player_profilepage Title: Re: Inigo Quilez's brute force global illumination Post by: eiffie on June 13, 2013, 06:16:20 PM Finally corrected a problem with the script that applied the diffuse color even to specular light. The updated script is on the previous page - named eiffieGI2.zip
(http://fc02.deviantart.net/fs70/i/2013/164/f/f/testgi4_by_allenflusa-d68v2rj.png) (http://fc09.deviantart.net/fs71/i/2013/164/c/1/testgi3_by_allenflusa-d68v2dq.png) Title: Re: Inigo Quilez's brute force global illumination Post by: vinz on June 13, 2013, 06:35:05 PM AWSOME :D!!!!!!!!!!! :thanks1: |