zig-zag voronoi separation

[Noobman]

Running visolate 3.1.1 in win7, with gerber files from Kicad (*.pho), from RDB_ts board.
On summary, the voronoi paths separation has a zig-zag instead of a quasi-straight median between the polygons.

Havent noticed differences when playing with parameters except voronoi lim, and only if that is less than unity. I dont think that is related though, its probably just how the parameter works, but i also get an error about it there. From playing with this, zig-zag shape changes when voronoi lim is very low, like 0.05, but that seems like a corner case which starts to spill errors about "nnuID", as seen from terminal in 3rd picture. And for example at settings like voronoi lim like 0.01 and lower it seems voronoi paths become like "outline" shapes, again probably how it would work, but it is still stacking up that error.

This is the gerber file (just needs an extension change from jpg to *.gbr). Header says its exported from gerbv because i changed the origin with gerbv, but otherwise the file is exported by kicad.

[Noobman]

I only installed java development kit and java3d, as i took the liberty to write on reprap pcbmilling page. Normally it runs fine and without errors, so i think there are no other dependencies. Also, with the test file included, everything works fine. Voronoi paths are correct and the parameter voronoi lim less than unity does not give any errors.

So its probably something with this gerber file. I checked and i think gerbv says G36/37 - zero instances. Perhaps something with other codes. I'll try play around and remove some of them and see what happens.

[Traumflug]

I guess it's a known limitation and/or missing feature.

To get these Voronoi color fields, Visolate draws a frustum/truncated cone around each track an each pad, then views the result from the top. The isolation paths go where the cones intersect. You can see all the cones when taking a more simple layout, then turn on the "tilt" and "voronoi" checkboxes to allow 3D rotation with the right mouse button.

One problem with aligned rectangular pads is, the intersection of two of their cones isn't clear. The cone sides facing to each other are clear, but not the ones parallel to each other. Because two faces sharing the exact same orientation in space, you get fickle colors and accordingly zig-zag G-code paths.

Short of finding some trickery to solve this problem by coding, making all pads round helps a lot. Copper space reserved for the pad will remain the same.

If you have a good solution for solving the problem geometrically, let me know. In case I ever start to integrate Voronoi paths into gEDA/pcbs G-code exporter, this is the very reason why I'd go with an approach different from the one with drawing cones.

That said, there's possibly a problem left with drawing the cones around rectangular pads. Didn't look into that too closely.

[Noobman]

Again "aha" - i thought the stuff is done in 2D, didnt even realized its 3D until you told me to click the tilt button.
The pads are smd (1206), so i think it means that instead of voronoi i will have to stick with the outline style tracks.

I really have no clue about how to make this work, but i'm not afraid of trying and failing, so here we go :)

Geometrically i am still thinking in 2D. Step one, increase all polygon sizes in all directions with incremental 1%, then collect all intersection point between any two different polygons, then rinse and repeat. The idea being that after a whole lot of iterations all the points should start to form parts of the path, in between, even proportional to the initial size and shape of objects. As this dotted line can grow to infinity it would need an stop (loop exit criteria), e.g. when both ends need another similar line nearby, since for voronoi each net is an island then each line needs to end by touching another at both ends. So growth's intersection points can form a dotted line at least some sort of path, until they meet another path. I think if all paths between two adiacent polies are found like this, and they connect to other paths with one of those poly and a third one, then it might be done, e.g. meaning there arent any "loose ends" literally, therefore each net is an island.

Or perhaps i'd try exploit the fact that most of the stuff is in 90 or 45 degrees. Sort of to scan the gerber horizontally, identify all median points between any two polygons met, and make some horizontal segments. Then scan again vertically, and then again at each 45 degree orientation. In the end would need to then find a way to choose which parts to keep and which to throw. Probably segments or vectors which are "more paralel" or "more distant" to neighbor polies or some other criteria like that.

Other than geometrical approach at some level i think it resembles something i met in control theory like a robot in a maze, with an avoid obstacle behavior, e.g. one bot trying to move in the maze and keeping away from obstacles. E.g. a mix of go-to-goal behavior with obstacle avoidance behavior. There were even matlab simulations and alike, but that was more for the unicycle and other systems stuff and complex system state parameters (accel, velocity, etc) while the pcb probably doesnt need those parameters. Goal could be either reach an intersection with free paths, or reach the pcb edges. Sort of one "software-bot" could try move around keeping equal distance or a distance pondered to the weight/surface of obstacles around, and perhaps if it reaches an intersection it then can multiply itself new one for each new path, and further on it would delete itself when reaching the board edges, or on intersections if creates new bots for all directions. If it could properly identify each intersection and path opportunity i think this might work, but its probably hard to interpret intersections and such. Otherwise it may miss something, so perhaps would need a ERC check. This is perhaps very close with what would i do if i would try draw such paths by hand myself, so from this perspective i think its not too bad to think at it, even if its perhaps quite outside the box.

I hope this is at least entertaining :)

[Traumflug]

i think it means that instead of voronoi i will have to stick with the outline style tracks.

Not neccessarily. Voronoi paths around two rectangular pads are the same as those around two rounded ones, so it doesn't hurt to change them.

That said I fear I didn't investigate yet wether it's possible to simply ignore the corners of a rectangle. Are you good at coding? Visolates' code is pretty well structured, so changes are pretty easy to do.

Step one, increase all polygon sizes in all directions with incremental 1%, then collect all intersection point between any two different polygons, then rinse and repeat.

Yes, this is a promising approach. Except that "1%" would be 1 pixel. There are algorithms which can do such a resizing by resizing each pixel individually, so the complexity of the geometry doesn't even enter the picture, as long as you can draw it at all.

[Noobman]

Aha i understand now, i could change the 1206 footprint to have circles instead of rectangles, and then when voronoi paths are created, it wouldnt matter because the created shapes would also fit rectangles or even more. I could change the footprint and its *.cmp component associations but that means i would have to make alternate pcb version specifically for voronoi paths, and that is quite a backtrack fix.

I think it could be more fitted to have something like that done around the "Fix topology" stage, like another button to "Fix rectangles", which could replace rectangles with biggest equivalent inner circles, sort of a patch. Finding maximum radius by the minimum center to edge perpendicular. Unfortunately TBH, i pretty much sux at software. What do you think about such a hotfix, would it be hard to implement?

[Traumflug]

i could change the 1206 footprint to have circles instead of rectangles

Ovals, not circles. Just like a short piece of track.

I think this is doable. It's likely even possible to keep the rectangular pads, just the cone drawn below it should be rounded. Cone drawing is done in visolate/Net.java. There's makeConeGeometry() for the pads and makeLineGeometry() for the tracks. There's even commented debugging code which draws additional lines to enhance visibility of the cones. I'd start with a single pad and checking wether the cone(s) are actually drawn the way they should be. Then decide wether the cone should be a oval or a quarter-cone at each vertex of the rectangle. The cone doesn't neccessarily have to have the same base geometry as the pad for it, until Visolate 2.1.6, actually a sharp cone around a single point was drawn (ignoring the size of the pad).

After all this bla bla, I'm pretty sure you'll find out yourself. Just try it.

[Noobman]

I did changed the smd footprint to ovals and that solved most of the problem.

Uh, again totally sux at coding.

Is there in java3D some method that can fillet the sharp corners? Could be added inside a procedure or something under the "fix topology" function or something like that. Some very very small fillets to round corners. So any method like fillet or at least bevel or chamfer? I dunno where to even start looking.

[Traumflug]

Sucking at coding isn't a permanent property. People learn by doing; so will you ;-)

As said, modifying the geometry as part of fixing topology is probably the wrong approach. It's just the cone which needs enhancements and these cones are drawn triangle by triangle in Net.java. Lots of sample code already there.

[Noobman]

Ok, but i kind of got too much on my plate already irl - and that is without trying to dive into java :)