Changed a few things in sphere, cylinder and functions.

[pierrebai]

Added new Paths implementations. Made the one in function.go pluggable at run-time.

[fogleman]

Very cool!

My intention with the API was to do it as described here:

https://github.com/fogleman/ln#custom-texturing

That is, creating a "subclass" that overrides Paths() instead of passing in a Paths() implementation. You can also see OutlineSphere as an example of that.

I am interested in integrating your work but would like to head that direction. Do you think you can refactor your pull request with that in mind? Also, thanks for renaming my bad ones like Paths2(), Paths3() :smile:

[fogleman]

Part of the thinking behind doing it that way was so the subclass could include other configuration / parameters. For example a GridFunction type could include parameters for the grid size.

[pierrebai]

Hi,

TBH, this code is actually a backport of my Python port of ln. I did that because I initially didn't have go installed and wanted to try to port it to see how it would go. Turns out Python is much slower than compiled go, so what gain I have not compiling is lost at runtime.

Anyway, that's why I had this pluggable-function approach, since it is easy and natural in Python. Other changes I did were in line with your recent changes: refactor out cairo for another lib. (I had used vmimg.)

As such, my pull rquest was already a refactor of a backport from Python, so feel free to simply rewrite my changes as you see fit. I don't think I'll be very active anyway.

[pierrebai]

BTW, FWIW, my port to Python revealed two potential issues with the code that I didn't backport:

1. in csg.go, you can have an infinite recursion in Intersect() for boolean shapes. I replaced the recursive calls with a loop in Python to at least not blow the stack. (Maybe go optimize tail calls?)
2. There are a few places where you end-up dividing by zero. Seems in go it just produces NaN, but in Python it threw exceptions, so I had to add checks in a few places and produce NaN by hand. I don't know if it was intentional to leave those divide-by-zero in there.

[fogleman]

Cool, thanks for the info!

[pierrebai]

I have done some refactorization: created multiple function sub-classes and put back the random vector stuff.