Curv: A language for making art using mathematics | Hacker News Reader

Curv: A language for making art using mathematics

github.com

152 pointsbibyte28 comments

I've been meaning to spend some time learn Processing[1] for ages, and would be interested to know how this compares.

Processing builds upon a full curly braces programming language (usually Java or JavaScript depending on which version you use) so once you are done prototyping it's pretty straightforward to integrate it elsewhere.

This is a neat idea, but if I'm being honest I find the graphics shown in the readme pretty ugly and evokes memories of bad computer graphics from the '90s / early 2000s textbooks

I find the lack of anti-aliasing disturbing.

oh and without access to the source it's utterly impossible for you to fix this... hey wait a minute.

Bad computer graphics from the '90s / early 2000s textbooks is an aesthetic all its own

It certainly is, I just happen to not like it, so I gave honest feedback.

Interesting. Seems a lot like https://libfive.com/studio/, which lets you implement the shapes in Guile Scheme.

That is amazing. Do you have more samples somewhere? Would be nice to see a "gallery" filled with these art work!

Seeing the word “gallery” reminded me of another piece of software to make graphics that I tried very many years ago. POV-Ray!

http://www.povray.org/

They have a hall of fame http://hof.povray.org/

And they even have a “dial-up version” (low bandwidth) of their hall of fame and I think it’s just super cute that they have retained the name “dial-up version” for that. http://hof.povray.org/index-lb.html

Also worth checking out is old versions of their website archived by The Internet Archive. 20 years ago: https://web.archive.org/web/19990210111443/http://www.povray... Click “gallery” (they were using frames so I can’t link it directly with the navigation intact).

>An AMD GPU, using the AMDGPU-PRO (closed source) driver, which is only officially supported on Ubuntu LTS, Red Hat EL (not Fedora), and SUSE. Unfortunately, the open source AMD driver (based on Mesa) is too buggy to work with Curv right now. Your choice of Linux distro is very restricted with AMD.

This is interesting, I use AMDGPU, when I tried PRO I got no greater performance in benchmarks. I'm using one of the unstable ppas (oibaf) and haven't had stability problems. I guess this sort of software perhaps pushes the envelope and reveals instabilities.

Will have to give it a try.

Installed and ran fine, appears to perform fine using some basic examples. Obligatory fractals - https://ibb.co/f40sFdx.

sudo apt install cmake git-core libboost-all-dev libdouble-conversion-dev libopenexr-dev libtbb-dev libglm-dev gedit checkinstall && sudo apt-get install libxcursor-dev libxinerama-dev libxrandr-dev libglu1-mesa-dev libgles2-mesa-dev libgl1-mesa-dev libxi-dev && git clone --recursive https://github.com/doug-moen/curv; cd curv; make; sudo checkinstall -D; sudo dpkg -i ./curv.deb

Then used this from the examples:

  make_shape {

      dist : everything.dist,

      colour (x,y,_,_) :

          let z = [x,y];

              color = [0,0,0];

              done = false;

          in do

              for (i in 0 ..< 100) (

                  if (!done) (

                      z := csqr(z) + [x,y];

                      if (dot(z,z) > 4)

                          let cr = (i-1)-log(log(dot(z,z))/log 2)/log 2;

                          in (

                              color := [0.95+.012*cr, 1, .2+.4*(1+sin(.3*cr))];

                              done := true;

                          )

                  )

              );

          in sRGB.HSV color,

      bbox : [[-2.5,-2,-2],[1.5,2,2]],

      is_2d : true, 

  }

Off topic, but for some reason this made me think of a vegetable that I just had for lunch: https://en.wikipedia.org/wiki/Romanesco_broccoli Art by nature with mathematical precision.

I'd really like to see a bunch of images / live 3d models generated with it before investing time to even try it.

Website: http://www.curv3d.org/

When contemplating beautiful mathematical inspired digital artistry, it is hard to ignore Jos Leys's exciting pages [0].

[0] http://www.josleys.com

These are beautiful. With which language/tools are these images/movies made?

Jos Leys mentions UltraFractal [0], what appears to be a project by an indy programmer, Frederik Slijkerman.

[0] https://www.ultrafractal.com

To the people who have experience with it, can it be used for solid modelling ? Since it supports export to popular format, it would be nice to use it for solid modelling also.

"... supports full colour, animation and 3D printing.

My experience with F-Rep based modeling systems is that once you've used a few transformations, the distance field becomes highly non-cartesian and operations do not have the expected effect. For example, "offset" generally only has the desired effect on a primitive shape. Until someone cracks the problem of "renormalizing" signed distance fields, I fear all such systems will just be toys.

Antimony [1] and its related project AO [2], as well as ImplicitCAD [3], are CAD-oriented F-Rep systems (that suffer from the problem I mention).

[1] https://www.mattkeeter.com/projects/antimony/3/

[2] https://www.mattkeeter.com/projects/ao/

[3] http://www.implicitcad.org

F-Rep: https://en.wikipedia.org/wiki/Function_representation

> For example, "offset" generally only has the desired effect on a primitive shape.

It might not have the expected effect but surely it has a well-defined effect?

I've tried to get my head round distance functions whilst tinkering with raymarching shaders and the guru's over on Shadertoy and pouet.net seem to have a fairly solid understanding of which transforms behave nicely and which don't. They bandy around terms like lipschitz continuity which leads me to believe they've got a deeper grasp of this stuff than I have ;-)

I guess I'm saying that I have a hunch there is a fairly clear distinction between "things that keep the functions well behaved" and "things that don't"

(slightly tangential) Have you checked out what Rimvydas Krasauskas has been working on?

https://klevas.mif.vu.lt/~rimask/old/pdf/unifying_theory.pdf

I don't think the problem of "renormalizing" signed distance fields can be cracked, at least not in a generic way that's fast enough for realtime rendering. I would agree this strongly limits the possibilities for making simple modeling tools based on SDFs, because whenever you use interesting transformations, you also need to be hacking away at the correctness of the field. Because of this, it's hard to make simplified tools for modeling and rendering interesting things using SDFs: you can't abstract away the fact that you're effectively writing a distance estimator function, and you'll always want to be able to dig down to the lowest programming level in order to make things work. This is a problem for popularization, but it doesn't prevent the technique from being useful in some domains and applications.

It seems to be similar to Context Free Art [1]

[1]: https://www.contextfreeart.org/

> dynamically typed, pure functional programming language

Why dynamically typed!!!

It's for math. You'll mostly be using it to store numbers. It also runs in the GPU. What do you want types for?

Sounds very cool. On Mac though you should probably migrate to Metal instead of OpenGL at some point.

Reply on news.ycombinator.com