Pretty much, but I think it's just anything less-than-one becomes zero. I've just looked back over this code, and it's actually not as stupid as I expected it to be, but it's still inclined to discard points rather than keep them. The offending block is here:
for (int j = 1; j<scaled.size(); j++)
{
// and even then, only bother drawing if it's a move of over "x" steps
int diffx = int(p.x) - int(result.get(result.size()-1).x);
int diffy = int(p.y) - int(result.get(result.size()-1).y);
if (abs(diffx) > filterParam || abs(diffy) > filterParam)
{
//println("Adding point " + p + ", last: " + result.get(result.size()-1));
result.add(p);
}
}
( The code above comes out as junk, but it's pretty here: https://github.com/euphy/polargraphcontroller/blob/master/drawing.pde#L913-L925)
The above is essentially cycling through all the points in the line and measuring the distance from the current point to the next one, and only adding the point to the queue if the distance is greater than filterParam (which is equal to minimumVectorLength).
I think the problem here is that these calculations are all done using integer maths, so they naturally round down, and in these edge cases, round down to 0.
You can cut out this filter completely, and it might build points, but they still might not be expressible by the machine (because it's sub-step resolution), but worth a try. Change that block of code above to
for (int j = 1; j<scaled.size(); j++)
{
result.add(scaled.get(j));
}
(Or rather comment the old block out, and put the new block in - in case you want to go back.)
The internal resolution of the polargraph is 8x the external addressable resolution, so that might work actually - depends how the numbers get rounded when building the actual queue.
hey let us know!
sn
|
Author
"Shortest Vector setting" - zero isnt short enough for me
