Polygons causing double travel

[jpadie]

I had a thought last night that it may not be necessary to mill polygons at all. Just test that the connectors are already isolated and then ignore the vertices from the brd file.

seemingly there is no difference in the rendering within CP of a board with/without the polygon apart from the connectors (minimal thought/testing on this - here be dragons...).

with polygon

without polygon

suggestion:
if this logic is correct, give people the option via a checkbox not to mill polygon vertices and connectors (if they are already in the milling pattern).

[ameennihad]

Last month, I spent few days trying to find a way to achieve this, but it's too complex and it will consume too much time in rendering the board since we need to compare each signal with all other signals, so the time required will increase exponentially with number of signals (or even more if some signals are of multiple polygons)
I thought of a solution that requires rewriting the rending code from scratch, it will produce more accurate clearance between signals but it will not reduce milling time. If I ever decided to develop that I will make it as option, so users can decide to render the board in old or new method.

[jpadie]

I think that i would rather the rendering take a few seconds more than even a simple board having the milling time extended by 50% a simple board a couple of days ago went from 59min to 1h45mins! for the classic CP use case is it fair to say that most boards will have less than 2000 contacts per layer? related question: (I am not familiar yet with this code base) - how do i examine the structure of the object that gets created from the parsed board file? does it get pushed to the console at all? as an aside: for debugging I think that everyone should be encouraged to namespace their console logging on a widget level. that makes filtering much more straight forward.

…

On 11 Feb 2017, at 10:46, ameennihad ***@***.***> wrote: Last month, I spent few days trying to find a way to achieve this, but it's too complex and it will consume too much time in rendering the board since we need to compare each signal with all other signals, so the time required will increase exponentially with number of signals (or even more if some signals are of multiple polygons) I thought of a solution that requires rewriting the rending code from scratch, it will produce more accurate clearance between signals but it will not reduce milling time. If I ever decided to develop that I will make it as option, so users can decide to render the board in old or new method. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#24 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AX4EgRNmjdOpSq5G_mxHNLVBELxoHuN6ks5rbYNegaJpZM4L-IK5>.

[chilipeppr]

I think deduping the polygon paths could be done with some creative use of the Clipper library that we make heavy use of throughout the Eagle BRD widget, but I have not figured out a good way yet. It's sort of a riddle and if you could figure out a good way that would be amazing. I do think you always need to process the polygons, because in your rending of with and without, you ended up with 2 pins not connected to your ground plane and thus your board would fail. Another approach could be line intersection raycasting. I do this in the 3D viewer for inspect mode where I project where you mouse is on a ray and see if it intersects a line in your Gcode. So, a similar technique could be done at the Three.js layer, rather than via Clipper, because the Three.js library has a comprehensive raycaster intersection system with a tolerance range.

…

On Sat, Feb 11, 2017 at 1:54 AM, jpadie ***@***.***> wrote: I think that i would rather the rendering take a few seconds more than even a simple board having the milling time extended by 50% a simple board a couple of days ago went from 59min to 1h45mins! for the classic CP use case is it fair to say that most boards will have less than 2000 contacts per layer? related question: (I am not familiar yet with this code base) - how do i examine the structure of the object that gets created from the parsed board file? does it get pushed to the console at all? as an aside: for debugging I think that everyone should be encouraged to namespace their console logging on a widget level. that makes filtering much more straight forward. > On 11 Feb 2017, at 10:46, ameennihad ***@***.***> wrote: > > Last month, I spent few days trying to find a way to achieve this, but it's too complex and it will consume too much time in rendering the board since we need to compare each signal with all other signals, so the time required will increase exponentially with number of signals (or even more if some signals are of multiple polygons) > I thought of a solution that requires rewriting the rending code from scratch, it will produce more accurate clearance between signals but it will not reduce milling time. If I ever decided to develop that I will make it as option, so users can decide to render the board in old or new method. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub <https://github.com/ chilipeppr/widget-eagle#24#issuecomment-279133232>, or mute the thread <https://github.com/notifications/unsubscribe- auth/AX4EgRNmjdOpSq5G_mxHNLVBELxoHuN6ks5rbYNegaJpZM4L-IK5>. > — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#24 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHidbcIGmNVWIJNjtF4qyJfQKEOXFvOMks5rbYVrgaJpZM4L-IK5> .