25 posts tagged with "development"

One of the sorely missing features in FreeCAD is a convenient system for creating custom data elements and interacting with them.

A common use case is constraining multiple features in a sketch to the same value. Instead of tweaking every instance of a horizontal distance constraint, you would create a custom data element (or property) called “Length” and then reference it via the Expression Engine. Then every time you change the value of that custom element, the entire sketch is updated automatically.

FreeCAD has a basic implementation of a materials system. While it works in some scenarios, we think it can be vastly improved to become a lot more useful. Let’s discuss what’s already available, what’s missing, and what’s a possible way forward with this. But first, why are we even discussing it?

Discussions about FOSS issue practices often center around getting issue creation right. Have we set contributors up for success with guidelines and issue templates? Are we asking them to look at existing issues for their proposal first? These are bare minimum requirements.

We act like someone creates an issue and throws it over the wall, after which someone else picks it up to move it forward—all of which hinges on writing a good issue. If the issue goes stale, it wasn't a good issue, right?

There's a problem with running development FreeCAD builds for actual work and it's going to get uglier soon. Here's the deal.

Historically, the development process in the FreeCAD community has been entirely volunteer-driven. This approach served the community amazingly well — up to a point. We got a very capable 3D CA* program out of it, but as the project grew, it became harder and harder to make significant changes.

VR CAD is usually portrayed like Tony Stark designing Iron Man suits, putting the emphasis on VR as an evolution of design tools. This is Hollywood stupid. VR design/UI isn't mature enough for that. Instead, we should be thinking about VR as a sharing environment where a designer can demonstrate a model in context.

We started this series with the assumption that there is a strong community demand for a default assembly workbench in FreeCAD. The community discussion that followed that article confirmed our belief. We then researched existing options — Assembly 2, A2plus, Assembly 3, and Assembly 4 — and even quickly studied related workbenches and macros.

Our research had a number of limitations though. We avoided exploring the earliest solutions such as the original workbench by Jürgen Riegel and FreeGCS because they were incomplete. We also decided against studying both Exploded Assembly and Animation workbenches because this type of feature deserves dedicated attention.

In the previous posts in this series we’ve already discussed reasons to create a default assembly workbench and then explored existing options: Assembly 2, A2plus, Assembly 3, and Assembly 4.

There are several more tools that provide a subset of their features, and these tools regularly come up in discussions on creating assemblies: the BodyBuilder macro, the Manipulator workbench, and the Part-o-magic workbench. Since none of them can realistically serve as a foundation for a potential default assembly workbench, in this review, we’ll focus on their interaction models to see what we can learn from them.

In the previous posts in this series, we talked about the need for a default assembly workbench in FreeCAD and reviewed Assembly 2, A2plus, and Assembly 3. Let’s talk about Assembly 4.

This is the fourth part in the series where we explore the possibility of creating a default assembly workbench for FreeCAD. We started out with a conversation about why we need a default assembly workbench in the program, then reviewed Assembly 2 and A2plus. Now let’s talk about the Assembly 3 workbench.