I think I should add that licence to my boxplorer shaders (just in case they burn someone's graphics card
). Thanks for the link.
btw, love the coloring in your shader. Been iterating and struggling to get something as nice with the pkleinians.
I'll tinker around some more with them, the pkleinian-menger w/ reflections should be nice. I really should unify the common code out of the shaders..
Glad you like it. it's also possible to color by integer iteration number used with a variant that cheks when the iterated point becomes invariant. The later gives each level of spheres a different color.
I have some questions about the tracing code in your shader; min_dist cannot be (say 1e-5) small w/o affecting the reflections badly. Hard to crank up the detail that way
It would be nice to have some screen resolution adaptive level of detail (min_dist morph?). Played a bit with that in some shaders w/ boxplorer2 but no panacea.
Can you enlighten me on the ULP logic in your marche() function?
Well, that tracing code is still experimental (maybe forever
).
Indeed, it is written in order to have a resolution dependent rendering. The rendered surface is actually at some distance from the fractal. That distance depends linearly (using min_dist) on the distance from the eye. min_dist should be function of the resolution and the FOV. Something like this:
sqrt(2)*tan(0.5/180*pi*fov)/xres;
I left the pixel "size" (min_dist) as parameter because this information should be given by the main program as uniform. One have also to take into account the raystep multiplier. I found that a value of around 1e-3 - 5e-4 gives good results(for a 800x600 resolution, at 1600x1200 it should be 5e-4 - 2.5e-4). a value of 1e-5 seem to be too small. I'll try to see if reflection artifacts can be reduced. My first gess is that the normals need to be more precise (needs more bits). EDIT: the banding comes from the abs() used in d_PZshape() function... You can remove it but this will give different shapes when par[9].y is around 1.0.
If I remember well, the ULP is the smallest positive floating point number e such that: (1+e)-1!=0. It's just a hint about the maximum detail attainable. The way it is used in the shader is not exact. I assumed that the evaluated point is at a distance around 1.0 from the origin.
There are two numbers that should in fact be parameters (BTW, I second visual's suggestion
):
8192.0 * ULP -> precision at the surface. this is the epsilon used to stop raymarching. The bigger, the faster. Smaller values give more accurate renderings.
256.0 * ULP -> This is the minimal precision for normal vectors.