yes, I also found out that nurbs is not too happy with many points
converging in [0, 0] but with [0.0001, 0.0001] there is no problem. Are
you suggesting replacing all the math with jit.expr objects ? I did not
realize that would be faster than JS Math objects, but I will try!
Check out the performance difference between jsglsurface-example.pat
(uses jit.expr to evaluate surface) and jsglsurface2-example.pat
(uses JS to evaluate surface). You'll notice something like a 20-40x
performance difference in your surface calulation by useing jit.expr.
However if there aren't too many control points to calulate, then
it's not likely to result in overall performance benefits.
Also worth noting, certain types of calculation (like using adjacent
input or output cells to calculate the expression) are either a
nuisance (for adjacent input cells) or not possible (for adjacent
output cells). For adjacent input cells you *can* use one of the
spatial objects like jit.rota(in, @offset_x -1) in your
expression to grab a neighboring cell along the x axis for instance.
Haven't had time to examine your nurbs closing problem, but let us
know if you still are unable to track it down and I can try to figure
out a solution. The nurbs object closes connections about each axis
(connect top to bottom or left to right) and hence is good for closed
connections like a cylinder or torus, but doesn't close connections
*along* any given side of your mesh, so it can't smoothly make
spheres for instance.
besides 'many points in 0,0' thing, i've noticed that there are some
surfaces that 'bend' or 'sunk' from the top of your shape towards the
bottom, the crossection of the top looks like more like M than like Π ,
like when top vertex goes from top to bottom... or maybe this was intended?