Stipple Gen Mode

[techninja]

For official review: Next Beta1 build will include this awesome new mode.

@oskay Did you want anything else/something specific in this?

Currently includes:

• Web format image import
• Conversion to correct format
• Stipples from 50 to 20k
• Most images generate in less than a second, can be more accurate but take more time.
• Export as SVG file directly
• Save into shared SVG area
• Color/BW
• Overlap On/Off

[oskay]

This looks excellent. I'm not sure what the centroid subpixels option does.

[techninja]

Centroid subpixels sets the accuracy for approximate centering. The greatest thing about the interface is that you can mess with the sliders and see right away what something did, so It appears to be one of those super fine adjustment things. Also tends to make things about 10x slower when moved to the right without improving things much. The input resolution is fixed so it's up to us to find the best default and ranges.

Also quite subtly, the original image is visible at 20% opacity behind the stipples. Not sure if we need any extra ui for changing/toggling this, it just seemed like a good idea. Also, because we're handling image export fully, we can add levels/brightness control for users with imperfect images that need gamma/highlight adjustment.

[oskay]

We did that in stipplegen, but made it optional (see pictures here: http://wiki.evilmadscientist.com/StippleGen)
It's very important to be able to preview how the result will look-- whether that's will paintbrush sized blobs or tiny ink dots from a pen. Hiding the background image does give a better preview.

[techninja]

Progress report:
I said I'd get this done this week, and I'm trying to hold to that. Here's what I've encountered.

• Stock path tracing totally sucks when it comes to doing thousands of circles.
• Loading thousands of circles in from SVG is killer to Paper.js (slows everything down, blocks input when loading, etc).
  • I've made a brand new tracer that actually takes the SVG data directly and turns it into a set of x/y points and a radius & color, I then use this to render only whats needed, the bare minimum number of points to move to make a mark for very small circles (4 cardinal points).
  • I have to build this out to have higher resolution support, but for now I'm concentrating on lots of small points. This is about 100x faster and very user friendly.
• Attempted a full run high quality (10k stipples) of Adam Savage's face with the above improvements results in very fast recreation of points into directly ready "machine action" shapes, but now shows that path reordering is not quite fast enough to to be imperceptible with > 5k paths (Took about 10-15sec of locked up UI with >10k paths).
  • Instruction count ended up being around 90k, and sending took about 40 minutes, fairly unacceptable considering if you're drawing with a pen, it's going to be dried out by the time it starts.
  • Though the actual shape being drawn is a closed diamond, this is completely imperceptible from a circle with a 2mm pen (will experiment with 0.3mm pen).
  • You MUST draw with a slow speed. There are so many instructions right next to each other, this is basically a hard requirement. My test concludes that possible near maximum for lots of tiny stipples is 36% while up, 14% while down. In the future this may become automatic via dynamic speed based on distance with ramp up/down
  • Final drawing is a failure for unknown cause. Important dots are missing, either the machine skipped and drew them lower, or they didn't get sent. I left the room and didn't see.

Looks like my list remains clearly:

1. Streamline/comb instructions into cncserver so we can start sooner, or make sure that executing instructions is not interrupted by receiving instructions. This will effect all parts of RP and CNCServer and will reap incredible benefits everywhere if executed correctly.
2. Improve circle rendering resolution based on radius, and lower it for very very small circles to a triangle (I don't think we can rely on simply lowering and raising the pen to make a dot).
3. Make a full 20k stipple test, and test with brushes on large stipple color drawing.

I'm thinking I'm going to miss my deadline :P

[oskay]

Does the stipple mode already include a TSP solver? (I apologize if you said so and I missed it, or if it's handled elsewhere.)

When plotting unoptimized stipple output, the vast majority of the plotting time will usually be spent moving between points. To prevent that, it's helpful to spend a few seconds solving for a more efficient path. (It's not necessary to find an optimal path-- saving 90%, of the time, not 100% of the possible air time is the goal.)

It might be possible to streamline the crap out of the circles by adding some canned routines in cncserver: techninja/cncserver#66

[techninja]

I had already built in a reasonably efficient path sorting algo that simply picks the first shortest path from the top left position, which is really the only reason I went after this. It does work just fine, of all the issued, I'd have to say it's the least concern.

The canned routines are certainly interesting, and will reply more on that subject there. Saving only a set of points to send would certainly speed up data transfer! Though it might mean that reinking would only work between canned items :/

We'll see.

[techninja]

This project is up at https://github.com/techninja/robopaint-mode-stipple, would love to get it into RP Beta 3, but need some time to smooth out the issues and get the mac and windows binaries compiled.