Research Variant Parts

[pieterhijma]

Proposal description

The essence of the proposal is to research how to achieve true variant parts in FreeCAD in order to achieve improved support for parameterization. This research will target both FreeCAD users and FreeCAD developers as audience and it will be focused on 1) explaining users the current problems of variant parts in FreeCAD and the potential of the functionality that this research proposes as a solution, 2) and keeping a potential solution manageable in terms of complexity if the FreeCAD core needs to be changed.

This proposal builds on the current work on VarSets and the problems that emerged with an early implementation in #12532, an earlier iteration of this proposal in #3, and the discussion with @yorikvanhavre and @shaise (see summaries of the discussions in both links).

This project will attempt to improve on copy-on-change links and configuration tables in order to address the various issues that this functionality has for parameterization, such as reliance on temporary hidden files as is the case for SubShapeBinders, and hidden references, functionality that poses a risk to make FreeCAD models brittle. This conversation explains the shortcomings of Spreadsheet configuration tables well and in my humble opinion the same is true for variants based on SubShapeBinders.

The ultimate goal is to provide FreeCAD users with what I call an Application Geometry Interface (see #12120) something that is to the best of my knowledge not possible in other CAD programs (other than coded CAD solutions). Adding this functionality would align with objective Streamlined Workflow, but also with objective Prevent shooting yourself in the foot).

Deliverables

The research will be presented in three different ways:

• forum posts for users,
• forum posts for developers, and
• PRs that are targeted at developers.

The research is conducted by developing code and this code is presented in various PRs possibly with alternative implementations. The forum discussions for developers and users allows the community to make decisions in preferred implementation direction, or – for example – to understand the trade-off in added functionality in relation to the added complexity in the FreeCAD core.

• Forum posts for users:
  • Explain current options for variants and their problems, making use of videos.
  • Explain the potential of variant parts by means of videos.
• Forum posts for developers: Provide context on the issues and PRs, and provide the community with options in implementation direction.

Expected PRs on three different topics, there may be PRs that have the same functionality but different implementations:

• PRs for referring to child properties: In this set of PRs we investigate how a parent document object can refer to properties of child document objects while attempting to maintain the DAG for recomputation and preventing dependency cycles.
• PRs for omputing shapes for variants: In these PRs we investigate how to compute shapes for variants from a base part without relying on hidden copies of a base part or hidden temporary files. This forms the basis for the next set of PRs.
• PRs for variant parts: With these PRs we investigate to what extent we can create variants in a similar way to SubShapeBinders without the requirement to have temporary documents given the solution from the previous PR.

Since this is a complicated topic with potentially low level changes to FreeCAD's core, the forum posts will serve as a way for the community to discuss 1) what functionality the community would like, 2) the tradeoff between changes in FreeCAD's core and the functionality the solution provides and, 3) implementation variants and direction.

Timeline

• Forum posts explaining the problem and potential: Start in September, finish end September
• Refer to child properties: Start in Oktober, finish end of Oktober
• Compute shapes for variants: Start in November, finish end of November
• Variant parts: Start in December, finish end of December

Risks and mitigation

I would like to carry out this work as an independent contractor.

A risk of this project is that this is a challenging topic as is apparent in the lengthy discussions in #3. After discussion with @yorikvanhavre and @shaise, it is clear to me that we need to find a way to involve the community and this modified proposal tries to improve on that. This project should really be regarded as a research project that may result in the conclusion that there is no better solution than what FreeCAD currently has or that the required changes are too large or complex for FreeCAD's core. However, because the potential of the anticipated functionality is so high, I think it is more than worth of investigating the proposed functionality. Without a doubt, it will provide us with a better understanding of the challenges at hand to support the above functionality.

To mitigate the risks, this work can be considered to have two stages where stage 1 is independent from stage 2 and useful on its own: 1) referring two child properties and 2) variant parts.

A solution for stage 1 is useful on its own and it will touch the issue of cyclic dependencies. Currently, it is not allowed in FreeCAD to refer to child properties because of cyclic dependencies, so it is necessary to find a solution for the proposed behavior, possible by making informed decisions on where to allow a cyclic dependency. Any knowledge that we gain in this area, allows us to find solutions for other problems regarding cyclic dependencies.

Although stage 1 can be regarded as independent of stage 2, the latter depends on stage 1 and requires solutions for dependency management because if a property of a variant part is changed, we need to recompute based on the source document object. At this time not clear how to properly manage dependencies.

Compensation

I would like to carry out this work with for a total of 8000 EUR.

About you

My name is Pieter Hijma (pieterhijma on the forum and pieterhijma on GitHub). I'm an independent contractor (https://pieterhijma.net) and as a co-founder of the Open Toolchain Foundation, I would love to contribute to improve FreeCAD as it is an important part of open toolchains. This functionality is inspired by my personal issues regarding modularity as a FreeCAD user. For example, my post on my Fab Academy program already mentions using different categories for parameters.

I have been working on Variable Sets as an independent contractor for Ondsel. This work can be regarded as an extension of that work, but with a more fundamental solution that was out of the scope of the Ondsel contract. In that sense, I have experience contributing to FreeCAD and experience relevant to this proposed work.

I haven't worked on similar software before but I have solved similar tasks that are more architectural of nature before. An example is the Cashmere project ([1], [2]) that needed a clean interface between two existing systems.

[pieterhijma]

To understand what is different in this proposal compared to #3:

• Posed explicitly as a research project
• Involve the community in a very early stage, both users and developers
• Expressed the solution in more generic terms to allow a broader range of possible solutions:
  • to try to maintain the recomputation DAG,
  • to try to work around changes to the execution model
  • to try to work around making FreeCAD's core more complex
• Split up in sets of small PRs instead of large PRs.

I hope this modified proposal gets the thumbs up from the community to be carried out!

[chennes]

Thank you for your proposal, @pieterhijma -- I'm sorry for the delay on getting this picked up. I will get the FPA Grant Review Committee started on it today.

[pieterhijma]

No problem, thanks for the notification.

[yorikvanhavre]

"Working against the DAG" seems to be the main subject here (the gist of the proposal is actually in the comment below the proposal, why not include them in the main text?), and IMHO a very good one. Not sure if variants have so much relevance here? Anyway, defining safe ways to work against the DAG, that don't harm the strengths of the DAG, seem to me a good and useful research subject, and also a way maybe to better or fix some problematic implementations done in the past.

[macdroid53]

Hmm...I have had thoughts and questions since configuration tables were introduced in 0.20. Configuration tables provide the capability to choose a given configuration of a solid. This does not address, what I think used to be referred to, as a family of parts. This probably needs some exampled discussion. Given a standardized cross section, for example 80X20 extruded aluminum. Given the cross section sketch, the configuration table will allow the selection and creation of a given length of extrusion. But, the configuration changes any occurrence of the extruded solid. So, the config table doesn't provide the capability of having a 100cm and 200cm extrusion. The "family of parts" allows multiple solids of the same cross section that have different lengths. This is similar to the Fasteners workbench, where I might have 10 M5 screws in my model, but 5 different lengths. The only tool I know of currently in FreeCAD that addresses this is the Lattice2 Para series. Here multiple solids are produced based on an array of values. Then links to members of the series can be made. Does this proposal address both of these scenarios or only the configuration table style functionality?

[pieterhijma]

"Working against the DAG" seems to be the main subject here (the gist of the proposal is actually in the comment below the proposal, why not include them in the main text?), and IMHO a very good one. Not sure if variants have so much relevance here? Anyway, defining safe ways to work against the DAG, that don't harm the strengths of the DAG, seem to me a good and useful research subject, and also a way maybe to better or fix some problematic implementations done in the past.

Thanks, indeed "working against the DAG" is a very important part. It would make variant possible, but it can have other benefits as well as you point out.

About the gist in the comment below: I tried to make the description independent in case there was a different committee before. The comment below the description is more like a "diff" for those who are familiar with the earlier proposal. Indeed, I could have put it in the description text as well.

[pieterhijma]

@macdroid53, it addresses both of these scenarios. In fact, if the cross-section sketch happens to be reusable for other cross-section sizes, then you could create a family of parts for different cross-section sizes as well, all based on a single sketch.