Another idea I have is to pass a transform function into repeat. e.g. in the bracelet example, repeat + rotate should be faster than the large union.

Justification

I was trying to model a bridge truss and it was slow unioning a number of strokes. Polyline was derived from IQ's polygon function, sans the signed internal function and added stroke size (d).

How to test

polyline {d:0.1, v:[[0,0],[1,0],[1,1],[0,0]]}  // right triangle

polyline {d:0.1, v:[[0,0],[1,0],[1,1],[0,0]]} >> extrude 0.2

Hey @Xiaoyuew check out this new shape primitive. It solves the performance problem of "large union", in the specific case of a set of stroke primitives.

Justification

I was trying to model a bridge truss and it was slow unioning a number of strokes. Polyline was derived from IQ's polygon function, sans the signed internal function and added stroke size (d).

How to test

polyline {d:0.1, v:[[0,0],[1,0],[1,1],[0,0]]}  // right triangle

polyline {d:0.1, v:[[0,0],[1,0],[1,1],[0,0]]} >> extrude 0.2

Justification

Run make test and make release build in macos environment for PR and master builds. See https://github.com/curv3d/curv/pull/125#issuecomment-832831058

How to test

• go to github Actions tab
• verify workflow logs

Justification

Run make test and make release build in macos environment for PR and master builds. See https://github.com/curv3d/curv/pull/125#issuecomment-832831058

How to test

• go to github Actions tab
• verify workflow logs

Thanks for isolating this 1 line change in a separate pull request. Processing this change was a big deal for me.

make test contains unit tests that ensure that the *.gpu files generated by the examples do not change. Because I don't want to break the GPU code generator by accident when I am refactoring code. But when there is a deliberate change (as in this pull request) then I need to regenerate all of the files in tests/gpu/*.gpu.

Ideally, I would create a github action to run 'make test' after every change to libcurv/* or curv/*. Then we would have received automatic notification of the test faiure after you created the pull request. But I haven't got around to learning how github actions work. There is a github action for rebuilding Curv on windows, but it wasn't my contribution.

Oops sorry about the tests.

'make test' now passes all tests again. I think we are done.

👍

Thanks @zeeyang for this subtle but important improvement to the sphere tracer.

Justification

See previous comment on rendering artifacts in helix distance function: https://github.com/curv3d/curv/pull/124#issuecomment-830681165.

Here is a video I found by Martijn Steinrucken which explains the 2 scenarios where sphere tracer goes 1) inside shape 2) behind shape. https://www.youtube.com/watch?v=Vmb7VGBVZJA&t=505s

This PR fixes scenario 1 where tracer is inside shape. The fix is to keep the tracer loop going so it can take negative steps back and get closer to the isosurface.

Fix for scenario 2 is to reduce trace increments (>> lipschitz x).

How to test

Here is a quick test on the helix repeat branch, but you can try any shape with render artifacts.

parametric
    w :: slider[0, 20] = 10;
    dy :: slider[-20, 20] = 10;
    step :: slider[0, 20] = 5;
in
box [3,w,3]
    >> move [0,dy,0]
    >> repeat_helix{reps:10, step:step} 
    >> lipschitz 1

Before: After:

I found one other issue with the new sphere tracer.

With the old algorithm, if you zoom into a solid object, so that the camera is inside the object, then previously you would see a wall of colour, whatever the interior colour of the object is. With the new algorithm, the object simply disappears and you now see solid white. I like the new behaviour less than the old behaviour.

Why? If d is negative in the first iteration, the loop exits with the foreground colour, using the old algorithm, but with the new algorithm, t is always negative, thus precis is always negative, thus abs(d)<precis is always false, thus the loop keeps going until it hits ray_max_iter.

If I change line 197 of frag.cc to:

       "        if (abs(d) < abs(precis)) {\n"

then this problem goes away.

If you want to know why kaboom breaks, you should look at kaboom's distance field using the distance field visualizer (show_dist). Kaboom has a bad distance field that only "by accident" worked with the old sphere tracer. Cranking the Lipschitz up to 10 seems to fix kaboom's distance field, and now it works equally well with the old and new sphere-tracing algorithms.

I have appended a modified version of kaboom that shows a 2D slice of it in the XY plane, run through the distance field visualizer. You can play with the Lipschitz slider to change between a useable distance field and a very broken distance field. The colours red, yellow and purple appear where the distance field is broken.

parametric
    Amplitude :: slider[0, 20] = 0;
    Lipschitz :: slider[1,12] = 3;
in
let
    displace [ifield, amp, off] shape = make_shape {
        ... shape;
        dist p : shape.dist p - (ifield p + off) * amp;
    };

    //hash = lib.noise.rand1x1;
    hash n = frac(sin(n)*43758.5453);
    noise xyz =
        let p = floor xyz;
            f = frac xyz;
            f2 = f*f*(3-2*f);
            n = p@X + p@Y*57 + 113*p@Z;
        in
        lerp[lerp[lerp[hash(n+  0), hash(n+  1), f@X],
                  lerp[hash(n+ 57), hash(n+ 58), f@X],
                  f@Y],
             lerp[lerp[hash(n+113), hash(n+114), f@X],
                  lerp[hash(n+170), hash(n+171), f@X],
                  f@Y],
             f@Z];

    rot v =
        [ dot[v, [0.0, 0.8, 0.6]],
          dot[v, [-0.80, 0.36, -0.48]],
          dot[v, [-0.60, -0.48, 0.64]] ];

    i_fractal [x,y,z,_] =
        do
            local p = rot[x,y,z];
            local f = 0;
            f := f + 0.5000*noise(p); p := p*2.32;
            f := f + 0.2500*noise(p); p := p*3.03;
            f := f + 0.0625*noise(p);
        in f/0.9375;

    fire i =
        let yellow = [1.7, 1.3, 1.0];
            orange = [1.0, 0.6, 0.0];
            red = [1.0, 0.0, 0.0];
            darkgray = [0.2, 0.2, 0.2];
            gray = [0.4, 0.4, 0.4];
        in
        if (i < .25)
            lerp[gray, darkgray, i*4]
        else if (i < .5)
            lerp[darkgray, red, i*4-1]
        else if (i < .75)
            lerp[red, orange, i*4-2]
        else
            lerp[orange, yellow, i*4-3];

in
sphere 12
  >> displace[i_fractal, Amplitude, -.2]
  >> lipschitz Lipschitz
  >> colour [i_fractal, fire]
  >> slice_xy
  >> show_dist

Improvement with sinc.

let
    sinc x = if (x == 0) 1 else sin x / x;
in
make_shape {
  dist[x,y,z,t] = abs(z - sinc(mag[x,y])*10) - 1;
  is_3d = true;
}
>> lipschitz 3
>> into intersection [box[40,40,40]]

Before:

After:

Oh no it doesn't look good with kaboom.

Before:

After:

Justification

repeat_helix was listed in the repetition future work section. It's useful for making staircases, chained links, etc. Also remapped repeat_radial as repeat_helix with step size of 0.

How to test

parametric
    w :: slider[0, 20] = 15;
    dy :: slider[-20, 20] = 6;
    step :: slider[0, 40] = 5;
in
box [5,w,1]
    >> move [0,dy,0]
    >> repeat_helix{reps:12, step:step} 
    >> lipschitz 10

Cleaned up and closing this for now until I can find a better sdf for helix repeat.

Justification

See previous comment on rendering artifacts in helix distance function: https://github.com/curv3d/curv/pull/124#issuecomment-830681165.

Here is a video I found by Martijn Steinrucken which explains the 2 scenarios where sphere tracer goes 1) inside shape 2) behind shape. https://www.youtube.com/watch?v=Vmb7VGBVZJA&t=505s

This PR fixes scenario 1 where tracer is inside shape. The fix is to keep the tracer loop going so it can take negative steps back and get closer to the isosurface.

Fix for scenario 2 is to reduce trace increments (>> lipschitz x).

How to test

Here is a quick test on the helix repeat branch, but you can try any shape with render artifacts.

parametric
    w :: slider[0, 20] = 10;
    dy :: slider[-20, 20] = 10;
    step :: slider[0, 20] = 5;
in
box [3,w,3]
    >> move [0,dy,0]
    >> repeat_helix{reps:10, step:step} 
    >> lipschitz 1

Before: After:

Are the gaps caused by undefined areas in the distance function?

Here's a quote from docs/Theory.rst:

According to John C. Hart, author of the original academic papers on SDFs, the only restriction is that an SDF cannot overestimate the distance from each point to the closest boundary. In math terms, an SDF must be Lipschitz Continuous, with a Lipschitz constant of 1. It's a continuous function which is limited in how fast it can change. For every pair of points in an SDF, the absolute value of the slope of the line connecting the points is not greater than 1.

The gaps are caused by a bad distance function that overestimates the distance from a point to the surface of the shape. When the distance is overestimated, the Sphere Tracing algorithm used for graphical rendering will skip past the surface of the shape, and a hole appears in the shape.

lipschitz 10 divides the output of the distance function by 10, which might fix the rendering problem, at least in this case, but also slows down sphere tracing by a factor of 10.