Major fill problems for intricate drawings with high quality settings (for pen) #109
Comments
|
Any idea what the root cause is? These lines are pretty distinctive; It should be possible to catch/identify/trap them with some method. |
Completely fixes the long lines problem depicted on #109, though the fill issue remains
|
All of the terrible lines shown on the top example appear to be caused by an improperly calculated overshoot with certain compound paths. In the above commit I've completely removed the end path overshoot (as every quick fix I put in its place made things worse). What probably needs to be put in place is some kind of line continuation falsifier that gauges the general direction we were going before we picked up and then to move in that direction times the overshoot multiplier. Yes, I could have sworn that's what I had intended to do, but the code sure didn't look at it. This path code again is some of the oldest in the codebase, and ripest for a rewrite. |
|
I've had the same issue with both paint mode and pen mode with SVG exported from Processing (one big path data block, strokes only, no fill). There's also a few times the brush will go down, up, then down again before starting paths, making lines from the paint area to the start of paths. Pics attached show both. I note in my SVG that the data has decimals out to 5-6 digits... Could there be floating point calculation issues with certain paths?
|
|
Troublesome! I doubt there's too much issue with rounding. My feeling is that it has something direct to do with tracing or path occlusion detection... or something. My path running algorithm is really quite naive and some part of subpath selection may be to blame. Try breaking apart any compound paths, and pin down what different precision settings effect it. Also if you enable the experimental manual mode (Settings->Advanced->Modes->Manual Paint), you can turn off "Check Stroke Visibility" and this will follow the path "exactly" without avoiding overlaps. If all this fails to help, post the simplest offending SVG code in this issue and we might just get this one squashed. Also if any of the above seems to help a bit, document it and post here as well, might better help point to where the real problem lies. |
|
@gwygonik Can you post an example that we can test? |
|
I had tried several different settings last night, but didn't run it in manual mode with the "check stroke visibility" turned off until today. Success! There seems to be another issue with running several back-to-back in manual mode, but I'm trying to reproduce and note the steps I'm taking; I'll post that elsewhere :-) |
|
Here's an SVG from Processing, the one from the first pictures. You'll have to copy/paste to a new file and save it; I can't attach a non-bitmap image. I imported the SVG into RoboPaint and scaled to fit, then scaled down a bit, then centered before I printed. |
|
For this particular drawing-- just lines --it might be better to paint it from Inkscape. A couple of questions occur to me: |
|
Labeling this issue priority-high. |
|
I'll give the Inkscape route a whirl, too. And sorry -- I had manually placed a rectangle around the SVG to give it a border. Some were painted at the same time, some were two-step paintings: paint SVG, paint a box. No relation to #21. |
|
Augh, OK.. found the culprit.. Same problem as earlier, ish. The path visibility check combined with the path end delta stroke overshoot _combined_ with the sub-paths = crazy long path overshoots to bad locations. Also it seems some part of the path visibility check is giving bad results, will be looking into it. For now I may just rip out the overshoot code until something better comes along. It really works well 90% of the time, a bit sad it keeps failing so hard on edge-cases. |
|
I really like the path end overshoot; compared to the choppiness of Inkscape path ends, it's awesome. Perhaps clamping the overshoot at a maximum distance and a maximum angle away? In other words, if the overshoot is > 1% of stroke and > 15-degrees from vector, stay going the old vector and move 1%. |
|
I had actually attempted that with the first version of the commit at 28a19b07b referenced above, but I kept seeing the stray paths continue show up. I really just wanted to get rid of all that and feel better about probably the worst bug in RoboPaint be slain, but you're right, the overshoot really is helpful. How about this, I'm going to attempt to refactor it in a way that preserves its abilities, but completely changes the way in which it works to avoid this exact problem. This might even be a good step forward toward better brush simulation and sharp angle management. |
|
@gwygonik With regards to the "choppiness," are you referring to the lack of lead-in when re-inking ( evil-mad/wcb-ink#13 ) or is this a separate problem? I was not aware of any issues at the path ends themselves. |
|
@oskay Sounds about right -- unlike RoboPaint, Inkscape has small gaps between stop and start points when reloading paint in the middle of a path. Actual ends of paths are okay. |
|
@gwygonik Thanks! We'll see what we can do about that one. ;) |
|
The workflow for issues if it wasn't clear, is that I close by commit (to match it to the issue), then you should come back and retest when the December release comes out (in the next few days). Re-open if the bug returns and mark down any new port of the issue, or be kind and leave a note that you've found it now fixed :) |
|
Just to give an update: We'll be taking @makersylvia, the bot and RoboPaint off to RobotsConf in Florida this weekend to do a keynote, and I hope to have the release out before I have to pack, but this release is carrying a LOT with it right now: CNC Server experimental command buffering, NW upgrade past 3 major versions, complete restructure of node-serialport code for windows.. It's crazy. I'm currently working out some very odd drawing and latency issues in Windows only, and as soon as I can polish those out, it's release time! Of course I have 5 different systems to build for... makes me a little worried. Perhaps it's moments like these where mitigating risk is the best option. Perhaps tomorrow night? Fingers crossed! 🏇 |
When doing test prints with highly intricate line drawings using penmode 3, drawing from SVG clipart using intricate settings, fill (or maybe stroke) occasionally draws huge lines very far out near the edge for no apparent reason. Very possibly related to stroke fill, but it's really awful and ruins prints. See here:
The text was updated successfully, but these errors were encountered: