Ability to create curved channels

[rkrishnasanka]

Background
Currently, 3DuF only has the ability to create channels/connections that are straight or have sharp edges.

Goal
Add the drawing code in paperjs that can generate Paths using either the RobustPath or the FlexPath classes seen in the python library gdstk
(https://heitzmann.github.io/gdstk/gettingstarted.html#paths). This will add new tool buttons called "Robust Path Connection" and "Flex Tool Connection".

Note: These will be integrated into a single connection tool at a later point

Difficulty Level 2
requires the ability to translate c++ implementation into structures created by paper.js

Skills

• Ability to understand C++ implementations and translate them into javascript
• Familiarity with how 3DuF user tools are created
• Familiarity with paper.js library

Mentors:
@nmz787

Contact
Krishna

[nmz787]

I reviewed the links above and compared the APIs from these examples:
http://paperjs.org/tutorials/paths/working-with-path-items/
http://paperjs.org/tutorials/paths/using-color-and-style/
https://heitzmann.github.io/gdstk/gettingstarted.html#paths

and noticed that the basic common requirements for a curved path in either library are:

• list of points
• width

While on call with Michael, I suggested that he start with a simple dictionary with a structure like this:

{
  'points': [(0, 0), (3, 0), (3, 2), (5, 3), (3, 4), (0, 4)],
  'width': 5
}

and then write code in either language that consumes this common data source. Using a dictionary will allow for serialization to save designs to disk, for reloading later in either Paper.JS or gdstk (for export to GDSII for fab consumption). As more design requirements are discovered, it should allow easy additions.

During serialization, I think all curved-path objects would need packaged together, so it could be properly parsed and appropriate language-specific API calls made. Something like:

{
  'flexpaths': {
    'path_name_or_id_1':
      {
        'points': [(0, 0), (3, 0), (3, 2), (5, 3), (3, 4), (0, 4)],
        'width': 5
      },
    'path_name_or_id_2':
      {
        'points': [(30, 75), (30, 25), (80, 25),(80, 75)],
        'width': 3
      }
   }
}

Hopefully that's on the right track!

[rkrishnasanka]

@nmz787 Followup question - Is there any way to track the bend radius in this ?

[nmz787]

It looks like paper.js only has this unitless smooth factor:
http://paperjs.org/reference/path/#smooth

However gdstk has an argument like bend_radius=5.

I can't tell if each value has the same effect (determining the bend radius) or if the paper.js value somehow determines the bend differently.

I think testing and comparison is the easiest way to find out. If they're different, then some normalization will need to be determined

[rkrishnasanka]

@nmz787 The current dictionary you have is pretty much what we store (plus some extra info) in the 3DuF connection object. However, I think you need to be looking at these implementations for curved channels when drawing in paper.js paperjs/paper.js#371. It's because rather than setting the stroke (which will play havoc when we try to manufacture/convert using the SVGs we instead figure out how to draw two parallel lines along the curved path.

Also, check these links - https://microbians.com/mathcode

https://stackoverflow.com/questions/37072075/paper-js-draw-multiple-parallel-paths-from-one-path

[nmz787]

I'm a bit thrown off by your last comment. It seems getting an outline of a path is a different goal. Also, I thought GDS was the manufacturing file format you were targeting. I would have thought g-code is a more hobbyist/machinist format, and GDS a more commercial supplier format. Are you sure you want to lump all these requirements into this one task/issue, or would it make more sense to get curved paths working in both APIs, then request a new feature to obtain outlines? If you've got an SVG, and know your manufacturing tools, it seems like converting to a raster then doing edge detection would get everything in one go. But again, seems like enough of a change request from the original issue of curved channels to warrant further discussion/delivery of requirements in a new/separate task

[nmz787]

Also, what's the reason for wanting outlines, unless you're cutting stencils or something. It seems you want the path volume fully exposed when doing lithography, (resin) 3d printing, etc.

[rkrishnasanka]

Also, I thought GDS was the manufacturing file format you were targeting

@nmz787 right now we support CNC-Milling and Laser Cutting because of our SVG outputs. So basically if you have one of the GCode generators provided by the Desktop CNC Mills, we can easily generate the G-Code from the SVGs.

The goal is to have the support for the following manufacturing processes:

1. CNC Milling - SVG (done), STL (prototype)
2. Laser Cutting - SVG (done)
3. 3D Printing - SVG (??), STL (prototype)
4. Photolithography - GDS (concept)

So while having curved channels is what we want, we want to make sure that the drawing code we have for it does offset+outline rather than manipulate the stroke values (therein also lies the challenge IMO). This way, we can just upgrade the current connection objects to have a bendRadius parameter and still have it work with the currently supported manufacturing processes.

[nmz787]

It seems unintuitive to cause the designers/users to see a manufacturing detail like outlines, when the result they want is a solid. I would approach this by solving the current issue of curved paths using the APIs provided, then enable the correct post-processing to outlines if the designer/user is targetting that style manufacturing. I'm still a little unclear why a milling machine would only need outlines, unless it was milling a stencil. If it was milling bulk metal to use as a casting master, it would still need the filled volume. Likewise with laser cutting, or 3d printing. Can you clarify the specific manufacturing flow that just needs outlines?

…

On Thu, Aug 26, 2021, 9:40 AM Radhakrishna Sanka ***@***.***> wrote: Also, I thought GDS was the manufacturing file format you were targeting @nmz787 <https://github.com/nmz787> right now we support CNC-Milling and Laser Cutting because of our SVG outputs. So basically if you have one of the GCode generators provided by the Desktop CNC Mills, we can easily generate the G-Code from the SVGs. The goal is to have the support for the following manufacturing processes: 1. CNC Milling - SVG (done), STL (prototype) 2. Laser Cutting - SVG (done) 3. 3D Printing - SVG (??), STL (prototype) 4. Photolithography - GDS (concept) So while having curved channels is what we want, we want to make sure that the drawing code we have for it does offset+outline rather than manipulate the stroke values (therein also lies the challenge IMO). This way, we can just upgrade the current connection objects to have a bendRadius parameter and still have it work with the currently supported manufacturing processes. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#371 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAITWRSNJBIG5DCTKTJSFILT6ZU7FANCNFSM5B5DQRNQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

[rkrishnasanka]

@nmz787 I think there might be a miscommunication here, what 3DuF does right now:
Takes a dictionary of waypoints and channelwidth to draw rectangular path objects like what is shown here:

These rectangular path objects have 0 px stroke
So when we plop the SVG into a tool like BantamTools gcode generator, we get the following:

So if we can implement bezier offsetting like in this one https://microbians.com/math/bezieroffseting.html or whatever offsetting algorithm they have in GDSTK in paper.js, I think it would solve the problem. Not sure if this was communicated across correctly (apologies for that!).