Welcome to Fractal Forums

Shooting montecarlo rays is great because you get DoF, AA, soft shadows and fuzzy reflections all at the same time, but it takes too long and we spend most of that time trudging through the same empty space.

Over at shadertoy I was working on a script that used DE to anti-alias. Knighty pointed out that Hart had already done this 20 years ago :|
Knighty and IQ thought that my script could be extended to do DoF. They are both fairly bright :) guys but I didn't think it would work. Distance estimates become quite bad at large distances and banding occurs. IQ said maybe taking samples whenever you are within the CoC might work. So I tried it and was surprised by the results.
https://www.shadertoy.com/view/MsBGRh (https://www.shadertoy.com/view/MsBGRh) This is a webgl link so be forewarned.

http://youtu.be/Z5SOA2xSLnQ If you prefer a video.

Like montecarlo we are grabbing multiple samples but not by shooting multiple rays. Instead one ray adjusts its "sphere of influence" to encompass the Circle of Confusion (CoC).

The idea is quite simple (and knighty can correct me where I'm wrong). March until the distance estimate is smaller than the radius of the CoC and grab a sample. Calculate the normal by using the radius of the CoC and average the color samples at these points. So now we have a normal and color that are averages for this march step. Do the typical lighting calculations (including any shadows or reflections) and use the coverage of the CoC to calculate an alpha used to blend this sample with previous samples. Continue marching adding small random jitters (to remove banding). Do this until the alpha becomes too small, you go out of bounds or run out of march steps. Then mix in the background.

It is fast because knighty realized you can add a portion of the CoC radius to the DE with each step. This is huge when the aperture is large. You just need to backstep to the edge of the CoC before taking the normal or shooting a shadow ray etc.

The best use of this method is in the secondary marches. Soft shadows can take as few as a dozen steps and soft reflections as well, depending on how blurred it is. This is the opposite of montecarlo where it takes more samples for blurred regions to converge.

OK now that I've sold you on it I have to warn you it is just barely out of the "fun hack" stage. Hopefully there are many improvements to come.

Here are some more samples...
Soft Reflections: https://www.shadertoy.com/view/Xd2GR1 (https://www.shadertoy.com/view/Xd2GR1)
Hair-like features: https://www.shadertoy.com/view/Md2Gzh (https://www.shadertoy.com/view/Md2Gzh)

...and if someone has done this before let me know because you must have learned some more improvements by now!

Super cool, works surprisingly well  :beer:

Have been following the shadertoy activity but haven't had time to tinker much lately.

Thaks eiffie for starting this thread. I think it's a better place to discuss this new/old technique. New, because you'r the first AFAIK who did it  ;D. Old, because there were earlier attempts: David Makin's (http://www.fractalforums.com/images-showcase-%28rate-my-fractal%29/deep-of-field-test/msg15752/#msg15752) and Kali's (https://www.shadertoy.com/view/ldf3zM).

Trying bokeh. I've just used this:

scol+=33.*pow(max(0.0,dot(reflect(rd,N),L)),64.0)*vec3(.5,0.25,0.15);

for specular componenet...Doesn't look right. :/

One can also spot some other artifacts... Maybe combinig with multisampling (while reducing the apperture accordingly) would give better results (of both multisampling and this -cone tracing- method).

BTW! it should also work well with path tracing.  ::)

And with Iq's soft shadows.

Thanks for the links to the earlier attempts. I will check them out now.
If you do soft shadows with this method it can be faster because you get to add the CoC to the shadow's cone - but it does add some speckling.
Thanks for the highlight samples. I'm wondering if they can be shaped with an aperature DE. Any shape you want and then somehow test reflect(rd,N)*CoC against the 2d DE??? Lots of questions still which is fun.

I think the method could be called Sphere of Confusion marching/tracing although it does form a cone as you march. (a lumpy cone)

Updated (again):
I used the following code to produce shaped bokeh highlights. (thin crosses)

Its just a fist attempt but it worked OK. Needs some more clamping so they don't get too big.

omg guys!
please ... finish this script because I am sure it will revolutionize fractal raytracing! :D
Set sticky to encourage ya brains! :D cheers

lol darkbeam - working on that but it takes time. My bokeh highlight shapes above sadly only work on spheres :( oops sorry about that.

It is a nice technique for marching through hair as you can treat it like any other DE.
https://www.shadertoy.com/view/XsSGRD (https://www.shadertoy.com/view/XsSGRD) (webgl)

Well the votes are in! 55,351 for Lumpy Cone of Confusion, and 1 (Eiffie??) for Sphere Of Confusion. And by the way, Lumpy Cone of Confusion is nothing new, as I've lived in it all my life.
 Due to, what can be loosely called "my lack of ability", this will be my only input to this post. .

Seriously, SoC (Sphere Of Confusion) sounds great, keep up the good work!! :) :)

Works well in Fragmentarium...

Nice work eiffie,       Fake Monte? what's next Full Monty?   :rotfl:

Thanks for putting that script together. I hadn't ported it to Fragmentarium yet. Can you post the script here as well? I could post the copy you sent me but I don't want to release your added code without asking.

One great use for this is as a preview of the focalDepth and aperature. I hate shooting 2000 rays and then saying "wish I had focused a little closer".

Please!  :D


Thank you! What are RT and UP?

"Sphere of confusion" ? LOL! seems a good name. Partly because it is a little bit confusing.  ;D.

RT and UP are the vectors UU and VV that produce the ray direction (the directions at right angles to the ray direction). I just use descriptive names "right" and "up". But sadly unless the surface is spherical you get distorted shapes. You have to have a way of determining the center of the highlight. Can't think of one right now.

ok here it is, I modified it a little to get progressive rendering to work and to make it fit into the Fragmentarium scheme of things but this is basicly cut and paste from the shadertoy script...

144.7 fps :D works on my box

the guts are in SoC-DE-Raytracer.frag leaving the DE for user  fractal mods.

EDIT: not as hard as I thought, the SoC-DE-Raytracer.frag (attached) is a plugin replacement for DE-Raytracer.frag, works with Mandelbulb and KaliBox as expected :D

EDIT2: the good script is on page 2

Thanks again eiffie! an awsome contrib, the Sphere of Confusion ;D an interesting place.

I've just been playing with SoC v2 (from shadertoy) the one with knightys fuzzy shadows, and pushing it a bit to see how to get fine details,
if you give me a map, SoC vars -> Fragmentarium Raytracer sliders, I'd be more than happy to put the SoC-Raytracer.frag together,
better than the earlier cut'n'paste job. I need a map because I'm just guessing with some help from the comments in the code :embarrass:

I've hacked in BaseColor and a few other things but crashed a couple of times pushing the wrong button too hard,
lol, I feel like the sorcerer's aprentice trying not to let the magic escape, good fun and learning more about DE in GLSL

(my fuzzy shadows by the way) :)
I made a version that doesn't use 3d.frag. This technique still amazes me! Sometimes you just stumble onto things. It would benefit from a few AA samples just to minimize the speckling but for videos speckling is good.
These samples are copied directly from the Fragmentarium window with no reduction in size.
(http://fc09.deviantart.net/fs71/f/2013/319/9/f/soc_puppets_by_allenflusa-d6ubkwb.jpg)

The two attached files are:
SoC.frag - the rendering engine, you include it instead of DE-Raytracer.frag
testSoC.frag - shows how to properly implement the DE function. You now have to accumulate colors when the boolean bColoring is set to true.

You add your color to the vec4 mcol. (mcol.a is for reflectivity)

(updated the files as of 19 Nov 13)

sweet! I didn't think you would take long or let someone else do that.
it really has a look about it, I'm glad you put the engine together, I always end up with extra nuts and bolts  :dink: did I make a mess of it or what?
pardon me  :o I was refering to the file that has "//V2 added some of knighty's improvements" in it,
haven't looked at these yet but it will be another tool in the arsenal, as soon as I get over IQs clouds, literally and metaphorically.
that's some real nice spaghetti you've got there.

aside: I tried the formula for depth occlusion, the one from marius similar to the GL manual, that you so kindly pointed out, but it is still off,
around the middle of the screen it's perfect but swing off to l/r/t/b and the depth values move away. I think it's something about polar coords, pixelscale, and the way things are calculated through a thin lens, it's so close, somewhere in there is the magic number that'll make it play nice between GL and Fragm.

tnx again  :D

LOL! I'm stealing some credit! ;)
Seriousely, all the hard work was made by eiffie. I've just made some suggestions.
Thank you both eiffie and 3dickulus for providing the fragmentarium scripts. :thanks1:

Time for other remarks and suggestions:
- The way rCoC is currently computed is a little bit wrong. it doesn't give a focal plane but rather a focal sphere. If rd is the ray direction for the current pixel and rd0 is the camera direction (that is the ray direction at the center of the screen) one have to multiply t by 1./dot(rd,rd0) in order to get the right result.
- Another source of inaccuracies: The intersection of the traced cone with the screen is elliptical in general (it's circular only at the center).
- Adding rCoC (or a fraction of it) to the DE was suggested while considering a signed distance function. The trouble with (all?) fractals DE is that the DE is not well defined or not defined at all.
- This method works best with perfect or at least well behaved DEs. Otherwise artifacts can show up.
- I think that physically "nearly accurate" lighting is really needed.
- The central problematic of this method is IMHO the filtering (Of the DE, the coloring, the normals...etc). In the other hand it can itself be used as a filtering technique for multisample renderings (even path tracing ?) and would then give almost noise free pictures.
- More to come   :D.

3dickulus your script was a great motivator for me, not that it was a mess but it didn't make sense to me combined with the 3d.frag (which is montecarlo). I still have to add some kind of multisampling if people want to make stills with it. Feel free to continue building on top of it!!! Thanks again.

Knighty you made a lot of good points but I have trouble with the first one. A camera doesn't have a focal plane (does it??). The lens focuses to a distance - it is just more noticeable in my scripts because I use a wide FOV. If I back the camera up and use a smaller FOV I believe it would be "picture perfect". Am I wrong??? probably.
#2 seems similar to me but I may be missing something. For the "holiday tree" bulbs I had to back the camera up to make the bulbs more spherical.
https://www.shadertoy.com/view/ldS3zW (https://www.shadertoy.com/view/ldS3zW)
#3 I would agree with you but the results I'm seeing say it works anyways. A big improvement here was backing the sampling point up to the actual DE. I rarely see it break through the surface unless the DE is total crap (which some of mine are). The amazing box is a point cloud and it works well with no fudging.
#4 agreed
#5 waiting for Syntopia to get on board with this - lol
#6 yes - my way was just what seemed fastest since it can happen every march step. I have been thinking about it too - at least using the middle sample but also not aligning the color sampling thru x,y and z but perhaps UU,VV (right and up directions of the ray march). But for now I like the speed of it.

One improvement I can see is needed from my pics above is to reduce the specularity in the high DoF regions. They look wet and since bokeh highlights didn't work maybe just get rid of them. :(

Let me clarify why I use 0.25*rCoC for the DE add on, 1.0*rCoC for the distance check where you use 0.5, 2.0.
Even though I called it rCoC I am thinking of it as the diameter (Aperture is a diameter) so my numbers are just half yours. You get the same thing either way by adjusting the aperture (which I just now learned how to spell :) ).  My choice of rCoC was poor but now it is GOSPEL! ...and I just realized that wasn't clear at all.

 :o

Very very amazing job :beer: :beer: :beer:

Oh I'm following this stuff by eiffie on shadertoy but I missed this thread!
Amazing work eiffie! and thanks for the fragmentarium script, gonna try it now!

Btw, that attempt knighty linked (you had to enable the DOF #define to actually see it), well was just a trick that works somehow fine with volumetric rendering, and it can be seen better here:

https://www.shadertoy.com/view/XssGDn (mouse Y axis to change focus)

But it's nothing like this!

The DE-DOF looks exciting - I'll give it a try.

I think the good question is whether you can do better  with a screen-space method. For instance, here I written the depth to one of the color channels, and then when I draw the buffer in a second pass, I look at a grid of neighboring points (14x14 points), calculate their size based on the  distance from the focal plane, and blend them to the current pixel (unless they are behind the current pixel, in which case they are discarded). This requires two shader passes, but is fast. I think you should be able to get similar effects to the very nice M3D DOF, where I believe all depths are stored, and then the pixels are drawn in sorted order and with a size based on the distance to the focal plane.

DOF:

(http://blog.hvidtfeldts.net/media/dof.jpg)


NO DOF:

(http://blog.hvidtfeldts.net/media/nodof.jpg)



Camera's have focal planes, not focal spheres. Try this "thin lens" model app:
http://www.panohelp.com/thinlensformula.html

I've updated the Soc.frag and TestSoc.frag files a bit. There are times when no normal can be calculated so I just cheat and use -raydirection.
Kali - I saw that DOF and you were ahead of me on realizing you have to march thru objects to get it.
Syntopia - Glad your looking at it. You are right that post processed DoF is fast and looks good but this has added benefits AA & soft shadows/reflections/refractions. (I haven't implemented proper reflections and refractions but it should be possible.) Post process DoF has some drawbacks. Reflections/Refractions are never correctly handled and real DoF sees around the corners of objects. This is my problem with IQ's soft shadows as well, the penumbra doesn't cut in behind the object. They still look good though so I get your point why the extra work when this method isn't realistic either. (I'm sampling a cone with spheres!) I am mainly excited about the AA and soft reflections but hey I'll take the DoF too!
Thanks for the lens link but they confuse it by talking about focal distance too! -lol spheres are planes (locally) :)

Here are some WEBGL examples with added lights (regular and distance estimated)
https://www.shadertoy.com/view/4s23zW (https://www.shadertoy.com/view/4s23zW)
https://www.shadertoy.com/view/lsjGzW (https://www.shadertoy.com/view/lsjGzW)

Hey Syntopia, awesome dof! I'm also glad you are joining. and thank you for the link about thin lens model. That is indeed what I was refering to.
As eiffie said, his method supports soft shadows and reflection (and probably refraction) which makes it extremely powerful. Anti aliasing also comes in naturally. it's an approximation and there are many kind of artifacts that shows up for moderate to high aperture but what amazes me are its robustness and that the noise due to the jittering disepears rapidly by lowring the fudge factor. I believe that using it with a path tracer would help reducing (dramatically?) the noise. (Ok! one would use a "roulette russe" method based on the opacity of the samples to choose the path but even then there should be noise reduction).

Here is my tweaks to eiffie's shader (https://www.shadertoy.com/view/Md23z1). The approache is slightly different: at each step we sample the surface that intersects the current SoC. The opacity depends on the sample's surface covering the cone and its orientation. The marching step is also different.

More great stuff Knighty! I like your using dot(N,-rd) for the mix so rays that graze the surface (taking more march steps) don't contribute more than the head-on colliders. I will mark mine up for your contributions, soon it will be more than mine!

I have played with the DE methods, and yes, the DOF is very nice - even for relatively large apertures.

Eiffie, if you want a focal plane solution, like in Knightys shader, you can pass the (uppercase) 'Dir' variable (which is the same for all pixels) from the vertex shader in a varying variable, and calculate the rCoC as:
   

Thanks Syntopia that is an easy fix! Will do.

This is not about SoC but A good related reading: http://www.mpi-inf.mpg.de/~mwand/papers/gi03.pdf
 :D

Thanks for the link Knighty.
I thought this script by TekF was interesting to see the different way he handled the alpha. It was missing the jittered step so it bands but still looks ok.
https://www.shadertoy.com/view/4dBGzw (https://www.shadertoy.com/view/4dBGzw)

Your way of using the surface normal to reduce the alpha works great but I also like how not using it fills in the background in so few marching steps.

Looks nice. I can't say I understand it but it looks nicer if one removes the "modulate by the length of the step" instruction. :D

The surface normal is necessary to make it look OK. That's because the samples are discs. If you set fudgeFactor2=.25, the jittering (which costs cycles) can be removed depending on the aperture. The number of samples per ray is indeed a problem, especially with shadows... The less samples taken the faster. The other problem with "my" approache is that it doesn't handle correctly thin/small objects/features because of the assuption of flat samples.

Your DoF algorithm is actually an integration algorithm. Maybe using higher order integration methods would give smoother results.

Now, THE question That I'm wondering about: how to filter geometry+material if such thing is possible? My wild gess is it would be a kind of BSDF. If this is the case how could it be simplified in order to make it practical? This question is already adressed and partially answered in Cyrill Crassin's thesis (GigaVoxel (http://gigavoxels.imag.fr/)). Is it possible to go further?

I thought I'd join in the fun. :)
I'm using this technique for rendering grass blades. It's done entirely in Shadertoy.
https://www.youtube.com/v/jXvpjnNSnKY?fs=1&hl=en_US&hd=1

This technique is a strikingly robust, and produces really nice alias free grass. Amazingly I'm getting away with only using 15 loops and it still manages to create a great grass illusion. Marvelous!
Thanks all.
Shadertoy version:-
https://www.shadertoy.com/view/Xsf3zX (https://www.shadertoy.com/view/Xsf3zX)

Glad you've joined Dave. If you experiment with using this to paint polygons let us know how it goes!

Thanks!
Yeah, it'll get no spiky silhouette as it will only look like bump mapping of course - but, it doesn't look like a standard texture either so I think it'll make a great grassy illusion. It may be even faster if I use a Voronoi texture, although that will be a lot of look-ups.

Here I've use the distance squared and collected just the normals. A surprisingly good fog can be made by simply adjusting the alpha.

Shadertoy:-
https://www.shadertoy.com/view/Md23Wz

Video without the fog:-
http://www.youtube.com/v/2eSb8zB4dBo?fs=1&hl=en_US&hd=1

I like the distance squared look even if it isn't "correct". It works well with clouds too.

I found the focus change too linear without the square.

aaah, too bad. My shiny new nVidia GTX 780Ti barfs on this shadertoy script (running it in Firefox 25.0.1). window stays black, Firefox stops responding. Putting the card back to mine litecoins so it can pay for itself. ;-)

UPDATE: worked in Chrome. Ran smooth in Full HD full screen (gently pats his GTX 780Ti)

UPDTE2: I've opted into the Firefox beta channel, maybe that's why all the debug information was enabled?

Christian

The recent Firefox updates appear to have ALL the debug information turned on and barfs at most of shadertoy, well it does here.
Try Chrome!  :)

running FF 25.0 on linux here with no problems on shadertoy, nice work btw  :beer:

I've not idea why Firefox is so slow on PC now, Inigo at Shadertoy told me about the debug stuff, it's not a Beta thing.

Great work Dave! :worm:

I think I would call the distance squared blur "atmospheric blur". The result of rays minutely reflecting and refracting off particles and droplets in the air. It gives a hint of great distance where the linear DoF calculated from a focal point and aperture can give the hint that the object is tiny (compared to the camera's aperture). I will have to include both in my script now.

I am using it as more of an atmospheric thing though (probably a mistake, being Mars, but hey). For landscapes you need a very high depth of field, adjusting the aperture to be very small to get everything in focus.

To have such a small area in focus doesn't seem right, mostly because it makes everything look small like viewed through a macro lens.

This effect has been all the rage lately, as you see from these perfect examples of the toy like 'Tilt Focus' here:-
https://www.google.com/search?q=tilt+focus&espv=210&es_sm=122&source=lnms&tbm=isch&sa=X&ei=_oesUpbeIKvH7Aa9lQE&ved=0CAkQ_AUoAQ&biw=1920&bih=954 (https://www.google.com/search?q=tilt+focus&espv=210&es_sm=122&source=lnms&tbm=isch&sa=X&ei=_oesUpbeIKvH7Aa9lQE&ved=0CAkQ_AUoAQ&biw=1920&bih=954)

(http://jeffpicard.com/blog/wp-content/uploads/2009/02/tut_ps-tilt-shift-photography.jpg)

(http://www.photostockplus.com/community/wp-content/uploads/tilt.jpg)
.

I agree, it's ok if you're going for the "lego land" look
the atmosphere on Mars is motly CO2 ? a heavy gas with a different refractive index than what we're used to looking through. I'm sure that when we get humans up there we'll know for sure but until then I think it's ok to allow for some creative artistic interpretation.

Hey those pics are cute. Definitely nice to have the option to do it both ways. It would be hard to mimic the distance squared blur with Monte Carlo rays so another plus for SoC.

Whether work "SoC" with 2Dtexture?