Top-level project for the graph extraction

a language for making art using mathematics

Tensors and Dynamic neural networks in Python with strong GPU acceleration

I18n quotation marks for Sass

pull request commentcurv3d/curv

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.

comment created time in a day

push eventcurv3d/curv

commit sha dacb5a5d609f9214703af6e2f0947d4cdf37c3db

ideas:language:next: user defined data types

push time in a day

push eventcurv3d/curv

commit sha 885bf81fefa1934051f748b53995e55f57b0909c

Add 2D polyline

commit sha 7bcb1ae525759230f2e1a4ccab27bc6956a477ca

Merge pull request #127 from zeeyang/2d-polyline Add 2D polyline

push time in a day

PR merged curv3d/curv

## 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
```

pr closed time in a day

pull request commentcurv3d/curv

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.

comment created time in a day

PR opened curv3d/curv

## 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
```

pr created time in 2 days

push eventcurv3d/curv

commit sha b2f417966c6b13b9c838c19d7864590b6929faeb

ideas:language:next: data abstraction

push time in 2 days

push eventcurv3d/curv

commit sha de2c3c53e0316d8b9a1895111fea02cf82a3c1d4

ideas: next gen language

push time in 2 days

push eventcurv3d/curv

commit sha 3ac261e2e8fd7c4c38f56dfba5bb835f1b092f4e

Add github action for macos build

commit sha ac861e67b0032392cfc542a53cc4bf5ea07ad806

Merge pull request #126 from zeeyang/macos-build Add github action for macos build

push time in 3 days

PR merged curv3d/curv

## 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

pr closed time in 3 days

PR opened curv3d/curv

## 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

pr created time in 3 days

pull request commentcurv3d/curv

Continue march backward when inside shape

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

comment created time in 3 days

pull request commentcurv3d/curv

Continue march backward when inside shape

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

comment created time in 3 days

pull request commentcurv3d/curv

Continue march backward when inside shape

Oops sorry about the tests.

comment created time in 3 days

push eventcurv3d/curv

commit sha 8fc802195bcf6fd52e4f8fadfb543d167615ea0e

ideas:language: metaprogramming

push time in 4 days

pull request commentcurv3d/curv

Continue march backward when inside shape

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

comment created time in 4 days

push eventcurv3d/curv

commit sha 75e2154812c02b06d0df84e7d7d396a9d2dda9c3

tests: update .gpu result files for pull #125

push time in 4 days

pull request commentcurv3d/curv

Continue march backward when inside shape

👍

comment created time in 4 days

push eventcurv3d/curv

commit sha 013a30f5155e0ff27a0a8f2dd9d1fc180a4e46bb

examples: fix kaboom distance field (see pull #125)

push time in 4 days

pull request commentcurv3d/curv

Continue march backward when inside shape

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

comment created time in 4 days

push eventcurv3d/curv

commit sha 79c497a0d4f4317257909139589201f518e3dabd

Continue march backward when inside shape

commit sha 68ae3c8ec9b13dabd5aa984678687508c82b9e11

Fix raymarching to work if initial ray origin is inside shape

commit sha 04935027541761715b610d6b18c0b5436446a549

Merge pull request #125 from zeeyang/ray-march-inside Continue march backward when inside shape

push time in 4 days

PR merged curv3d/curv

## 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:

pr closed time in 4 days

pull request commentcurv3d/curv

Continue march backward when inside shape

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.

comment created time in 4 days

pull request commentcurv3d/curv

Continue march backward when inside shape

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
```

comment created time in 4 days

pull request commentcurv3d/curv

Continue march backward when inside shape

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:

comment created time in 5 days

pull request commentcurv3d/curv

Continue march backward when inside shape

Oh no it doesn't look good with kaboom.

Before:

After:

comment created time in 5 days

PR closed curv3d/curv

## 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
```

pr closed time in 5 days

pull request commentcurv3d/curv

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

comment created time in 5 days

PR opened curv3d/curv

## 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:

pr created time in 5 days

pull request commentcurv3d/curv

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.

comment created time in 7 days