OpenCutList - a Crowdfunded Extension

What is OpenCutList ?

OpenCutList extension generates cut lists, estimates, cutting diagrams, labels, exploded views, SVG, DXF for woodworking or similar projects.

By inspecting the components and material properties of a scene, OpenCutList automatically generates list of parts, a summary report, cutting diagrams, and labels based on material properties of the parts. Supported material types include Solid Wood, Sheet Goods, Dimensional Lumber, Veneers, Edge Bandings and Accessories.

This extension provides a solution to most of the needs of a passionate amateur, an independent craftsman, or a medium-sized carpentry business.

Crowdfunded ?

The OpenCutList project is entirely based on a collective effort thanks to the voluntary work of part of the team and the community (translators, documentation writers, support assistants) and to a remuneration of the developers financed by its users thanks to the funds collected at each major release.

Its main philosophy is utility, transparency and common good.

This operating model has the major advantage of allowing the team to remain in a work of passion and to free itself from the constraints of the customer/supplier relationship. In this context, the team focuses its energy on features and not on marketing.

OpenCutList is not free. Like all Open Source software, it is a common good that owes its existence only to the generosity of donors. Currently 1709 donors who have provided the project with $50k in 4 years. A drop in the ocean compared to the 40k active users and over 340k downloads on the Extension Warehouse. But it is the small rivers that make the big rivers :wink:

If you are already a donor or if this post has inspired you to become one. Thank you very much on behalf of the entire community.

Without you, no more features and no support would be possible.

Useful links

OpenCutList 7.0 Promises

  1. QR Code in Labels
  2. DC Attributes and more in Formulas
  3. A new Part Drawing Tool
6 Likes

We have just passed the 40% funding mark for the next version 7.0. Thanks to all the contributors!

It is time to start announcing more the various promises of this next release.
We will make these announcements as the funding progresses.

Promise #1 : QR Code in Labels

With OpenCutList 7.0, you will be able to put fully customizable QR codes on your labels using Ruby formulas.

If you find this feature useful, join the contributors in making this great project a reality :sparkling_heart:

5 Likes

We have just passed the 45% funding mark for the next version 7.0. Welcome to all new contributors!

Promise #2 : DC Attributes and more in Formulas

Many of you have asked for more advanced customization. So, with OpenCutList 7.0, you will be able to access all data related to the definition and instance of each part component.
This gives you access to all attributes (DC or custom) in exports, drawings, cutting diagrams, and labels!

Exports

Drawings

Cutting Diagrams

Labels


If you find this feature useful, join the contributors in making this great project a reality :sparkling_heart:

3 Likes

This is a fantastic project and a very well-crafted and capable plugin. I just contributed to the 7.0 version and I encourage other users to do so as well.

Continued success and congrats on your accomplishments to date.

2 Likes

Thank you very much @db11 :blush:

Hi @boris.beaulant

I have a question about using OpenCutList with Profile Builder 4. I am not sure if you use or are familiar with this plug in, but it uses the green axis for length of members. I always disable “automatic orientation of parts” for my cabinet builds because of many situations in which we rotate grain (i.e. a deck of a narrow cabinet). But for profile builder members it makes sense to enable that feature. I wonder if it would be worth having “automatic orientation of parts” be enabled and disabled per each material.

You can “lock orientation on axis” on individual part. (that is the same as disable automatic dimensions for these parts).

But in this case, length is along the red axis.

Else, I’m curious to know why Profile Builder choose the green axis for length … :thinking:

@boris.beaulant Thanks!

I have a thread on PB4’s forum asking that very thing.

We have just passed the 53% funding mark for the next version 7.0. Welcome to all new contributors!

Promise #3 : Export drawings to Layout on multiple pages

It will be possible to export the drawing to a Layout file by adding it as a new page.
A good solution for bringing together several drawings from the same project in a single document.


If you find this feature useful, join the contributors in making this great project a reality :sparkling_heart:

3 Likes

We have just passed the 57% funding mark for the next version 7.0. Welcome to all new contributors!

Promise #4 : A new Part Drawing Tool

It is always interesting to save a few seconds on each modelling operation. Therefore, with OpenCutList 7.0 we are going to add a tool to make things faster, much faster!

The following video gives you an overview:

And here is a small preview of the grid copy tool with mirroring option :

Grid copy

If you find this feature useful, join us in making this great project a reality, make your contribution today :sparkling_heart:.

4 Likes

@boris.beaulant Thanks for your reply. I think that what I am asking is how would you use Instance Names to organize a large build? The way you show them in parentheses in the Parts List makes me think you have a recommended workflow.

For our system I don’t see a way to use them (we turn on “hide instance names”). I make every differently sized or differently painted (paint on faces, OCL material on component) part a unique definition and I think this may be the wrong way to do it. Should I be using scaling instead so that I can have fewer definitions?

Instance names are simply a list in the Parts List. Because a part can merge several instance names and even parts without an instance name.

In labels, or cutting diagrams which are themselves a list of instances, it is possible to use instance names, on the other hand.

But overall OpenCutList does not rely on instance names at all.

It’s certainly the same question as “Should I always drive my car backwards?”. You will move … but the car has been fully optimized to drive forward :wink:

Unfortunately I have to decide between a tradeoff of using dynamic components and scale factors or static components and Curic Trowel / Stretch. Curic extensions do not like working on scaled components or dynamic components. But it allows making changes to many parts at once. And if I’m working with unscaled components, they now all have to be unique Definitions. If that makes sense.

Scaling forces us into a workflow that might overall be slower even if it’s faster in some ways.

Currently the easiest approach is certainly to use DC (and then scale).

But I agree that an extension that could be able to stretch components without scale them would be better to keep component logic and integrity. But event if Curic Stretch is a powerful tool it currently make all or none component unique and it’s not necessary what we always need.

Currently the easiest approach is certainly to use DC (and then scale).

Thanks for your thoughts!

We see other disadvantages to using scaling and DC.

  • texture distortion. If all our cabinet doors share the same definition then the narrowest and widest cabinets have stretched grain.
  • an overall lack of flexibility in the components themselves without needing to make more and more DCs (costing big upfront time) or adding more and more attributes to existing DCs (also costly). In our workflows we find ourselves using simpler DCs to “rough out” a project, and then in many cases having to use Eneroth DeDCify or +Definition to further customize them. It’s at this point that the scaling can cause problems. I am considering a workflow where I use dynamic components only to generate part names with the DC “Name” property, but using Curic tools to size them from there. In other words, DCs without scale and position attributes. Bleh, that doesn’t seem great either!

The DCs are great when we are doing easy projects without a lot of custom elements but in many cases it would have just been easier to manually model it piece by piece.

But I agree that an extension that could be able to stretch components without scale them would be better to keep component logic and integrity. But event if Curic Stretch is a powerful tool it currently make all or none component unique and it’s not necessary what we always need.

What about an extension that takes a preselect and merges all identical objects (equal size, position, rotation, and material/tag attributes) into one definition. OCL already has the “group similar parts” functionality.

Many things are possible. But the problem is not easy to solve in the general case.

Personally, I dream of a tool like Curic Stretch or FredoScale that is smarter to handle components to be made unique. But also to determine where the components can be stretched … maybe in OCL 16 PRO :joy:

2 Likes

When exporting to Layout the viewport shows new edges that have been created on the surfaces of my model which are not in the original. These do not show up in the preview of Drawings nor if I print to PDF but if I export to Layout they are present. Opening the OCL created temp SKP file I see these are real edges added to the model. Seen this before, any ideas?


Hello @endlessfix ,

The parts must be redrawn in temp definition to be sent to Layout to keep only what must be visible without changing the original definitions.
To be efficient in this task, OpenCutList uses the add_face_from_mesh method. Which creates a lot of triangles and makes each edge lose its visibility status.
This visibility is therefore recalculated. And this calculation seems to have weaknesses.

Can you share the 3D model of this part ?

Sure, here is a file of the part in question, hope it helps. Thank you for the response.

Sample file.skp (902.2 KB)

Thanks, I will investigate this.