Material overhaul

A forum to discuss the implementation of a good Materials system in FreeCAD
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
User avatar
grandcross
Posts: 350
Joined: Sun Oct 11, 2015 3:08 pm
Contact:

Re: Material overhaul

Post by grandcross »

yorik wrote: Fri May 26, 2023 9:27 am - Maybe writing unit tests for Arch and FEM that test material support would be handy here so we can detect incompatibility issues early. For Arch there is one already: https://github.com/FreeCAD/FreeCAD/blob ... ch.py#L399 but we might add a simpler one. For FEM I'm not sure
What heresy is this? :D

Yes. Regression testing will be vital.
yorik wrote: Fri May 26, 2023 9:27 am - Think of the possibility for workbenches to implement some sort of "micro-editor". Some workbenches might want to work with only a few material parameters, and will not want to use the full-fledged material editor. Maybe you could design your UI code in a way that some parts of it could be reused by others (I'm thinking for example, of the materials tree)
I'm already thinking along the same lines. The tree would definitely be useful as a widget if not a full mini editor. Even for my own stuff I need a combination of material properties (either Shear modulus or Young's Modulus and poisson ratio), so perhaps a filtering function. Easier in an API than a UI, but potential performance issues either way.
yorik wrote: Fri May 26, 2023 9:27 am - Some external resources might be needed, like texture images, or hatch patterns. These might be a simple file path, or an URL, but I imagine these could also be embedded, so we have a self-contained material. The ability to embed any kind of data could also be useful for the complex cases you described, I imagine a whole table or diagram or formula could be embedded too.
Good idea. Yaml can handle binary data and links are links.
User avatar
grandcross
Posts: 350
Joined: Sun Oct 11, 2015 3:08 pm
Contact:

Re: Material overhaul

Post by grandcross »

I've promised more information after creating some prototypes so here goes. There's a lot to this so there I'll split it into a few replies.

Most of the progress so far has been in material cards and their handling. One issue is that with large numbers of materials, potentially with workbenches adding to the list as well, the volume is much too large to handle with a combobox.
matgui1.png
matgui1.png (46.82 KiB) Viewed 10004 times
Instead they're organized into libraries and folders. The current materials are in a system library, with additional libraries added by workbenches and users. Selecting a card will display the information in 3 separate tabs, one each for general information, properties, and a special one for appearance based properties.
matgui2.png
matgui2.png (52.18 KiB) Viewed 10004 times
matgui3.png
matgui3.png (67.59 KiB) Viewed 10004 times
1/...
User avatar
grandcross
Posts: 350
Joined: Sun Oct 11, 2015 3:08 pm
Contact:

Re: Material overhaul

Post by grandcross »

The current model is a single monloithic model containing a large number of predefined properties broken up into categories. That's going away in favour of a larger number of more granular models described generically as Models and Appearance models matching the tabs.

For example, what are currently described as mechanical properties can be divided further, such as density, isotropic linear elasticity, and so on. The linear elastic model shown previously inherits from both density and isotropic linear elasticity models. Users will be able to add specific models they require.
matgui4.png
matgui4.png (129.5 KiB) Viewed 9997 times
This has a few advantages. It makes the models expandable to support other mechanical models than what are stock in FreeCAD. These expansions would typically be provided by the external workbenches or macro developers. It will also allow them to require specific models to function, and to allow them to filter based on the completeness of those models. For example, I need density, or Orthotropic Linear Elasticity. The current version would require checking all parameters in each model individually. Inheritance would mean information would not need to be duplicated in multiple places, such is currently the case for density in both the mechanical and fluidic model categories. They can be more context aware. For example, the current model has a field Father which is meant to bestow a class of properties to that model of which the model card system is unaware. This can be defined in a model that relates to the context, such as in an architectural model.

Model files are defined using Yaml. This makes them user readable. They are identified using UUIDs so duplicate names become irrelevant. Here's aan example (subject to change!):

Code: Select all

Model:
  Name: 'Linear Elastic'
  UUID: '7b561d1d-fb9b-44f6-9da9-56a4f74d7536'
  URL: 'https://en.wikipedia.org/wiki/Linear_elasticity'
  Description: "Materials that are linearly elastic obey Hooke's law i.e. the stress and strain relationship is linear"
  DOI: "10.1016/j.ijplas.2004.06.004"
  Inherits:
    - Density:
      UUID: '454661e5-265b-4320-8e6f-fcf6223ac3af'
    - IsotropicLinearElastic:
      UUID: 'f6f9e48c-b116-4e82-ad7f-3659a9219c50'
  AngleOfFriction:
    Type: 'Quantity'
    Units: ''
    URL: 'https://en.wikipedia.org/wiki/Friction#Angle_of_friction'
    Description: "Further information can be found at https://en.wikipedia.org/wiki/Mohr%E2%80%93Coulomb_theory"
  CompressiveStrength:
    Type: 'Quantity'
...
2/...
User avatar
grandcross
Posts: 350
Joined: Sun Oct 11, 2015 3:08 pm
Contact:

Re: Material overhaul

Post by grandcross »

Parameters will have expanded capabilities. Currently they describe single values, such as a string or quantity. This will be replaced with an object of a type appropriate to the parameter, such as a distribution, list, array, temperature based series, etc. Multivariable series could be queried as a table, or as an interpolated value. Default values can be specified for things such as temperature to simplify use by code not requiring a full series

The editor will have visualization aids where appropriate, such as a graph of time series data (ignore the graph shown here... it's for visualization only)
matgui5.png
matgui5.png (33.93 KiB) Viewed 9992 times
IMPORTANT

This is the portion that will have the biggest impact on existing code. The card data can no longer be supplied as a key/value dictionary. To get a value, the code will have to call an api, potentially parameterized with a temperature, pressure, etc. This should be transparent to the end user. Core workbenches will be fixed to support this but external workbench developers will have to be aware of this change.

3/...
User avatar
grandcross
Posts: 350
Joined: Sun Oct 11, 2015 3:08 pm
Contact:

Re: Material overhaul

Post by grandcross »

Back to the cards themselves, there are a few additional points.

It should be possible to "inherit" cards i.e. copy and only change one or two parameters. This will be restricted to single inheritance but can be infinitely deep. Since the system library will be immutable (at least through the UI), this will be required if you intend to modify any of the standard cards. The UI for this operation has not yet been refined.

Card data could optionally be embedded into the document allowing it to be more easily shared.

Imports of material from other products should be possible from other products and CAD systems, but this will be part of a later effort.

The user interface shown here, or more appropriately the final form of what is shown here, will be what is displayed when assigning a material to a part.

Finally, there will be a lot of facilities made available to the developer. Widgets for card selection, object display and editing, etc. will be provided. Since the interface is shifting to APIs, this will be defined, refined, and supported. The goal is to make life for the addon developers as simple as possible.

4/...
User avatar
grandcross
Posts: 350
Joined: Sun Oct 11, 2015 3:08 pm
Contact:

Re: Material overhaul

Post by grandcross »

From a development timeline point of view, this will be done first. Integrations into the core objects and appearance routines are all going to be informed by this. It's also the part most likely to break other people's code, so doing this first will provide the best opportunity for testing and fixing.

Implementation will be in the core in C++ with Python support as is currently done in the rest of the product. This will ensure maximal compatibility throughout the product.

UIs shown here are quick prototypes and are not complete. These will be refined as we progress.

I say 'we' here but so far it's just me. If you feel like contributing to the coding, there are some good divisions of effort. If you prefer to contribute UI/UX, testing, or documentation expertise, that is also extremely welcome.\

../5
User avatar
yorik
Founder
Posts: 13640
Joined: Tue Feb 17, 2009 9:16 pm
Location: Brussels
Contact:

Re: Material overhaul

Post by yorik »

This is going great!!!

I would indeed take a moment to think of a good embedded <> linked solution. One might want to give a FreeCAD file to another person containing custom made materials. The other person does not have the card on their computer, so the data should be embedded into the FreeCAD file.

How will that work, what if the other person has a material with a same name on their computer, or even the same one but an older version. How will a "priority" system work.

Also, probably you saw that already, FreeCAD has the ability to save the contents of a property as a file inside the .FCStd file (ex. DiffuseColor or Path in the Path WB). It might be interesting to literally save materials as .FCMat cards inside the FCStd file, so the same priority system can be applied universally, for both in-cards and in-file materials, they would all technically be in-cards.

Also: Arch Materials have a small code that creates a colored icon from the material color ;) https://github.com/FreeCAD/FreeCAD/blob ... al.py#L441
User avatar
grandcross
Posts: 350
Joined: Sun Oct 11, 2015 3:08 pm
Contact:

Re: Material overhaul

Post by grandcross »

yorik wrote: Mon Jun 05, 2023 12:41 pm This is going great!!!

I would indeed take a moment to think of a good embedded <> linked solution. One might want to give a FreeCAD file to another person containing custom made materials. The other person does not have the card on their computer, so the data should be embedded into the FreeCAD file.

How will that work, what if the other person has a material with a same name on their computer, or even the same one but an older version. How will a "priority" system work.

Also, probably you saw that already, FreeCAD has the ability to save the contents of a property as a file inside the .FCStd file (ex. DiffuseColor or Path in the Path WB). It might be interesting to literally save materials as .FCMat cards inside the FCStd file, so the same priority system can be applied universally, for both in-cards and in-file materials, they would all technically be in-cards.

Also: Arch Materials have a small code that creates a colored icon from the material color ;) https://github.com/FreeCAD/FreeCAD/blob ... al.py#L441
Some thought has been given to some of this although perhaps not all.

As you pointed out, embedding in the file is an option. I see this being controlled with a selectable preference, similar to how preview images can be embedded in the file.

For name conflicts, files are referred to internally using a UUID created when the model/card is created. This will make name conflicts irrelevant. It doesn't address the older version problem though. This will require some thought.

I'll look at your icon code. That could be interesting.
User avatar
jdupuy
Posts: 6
Joined: Mon Nov 21, 2016 7:45 pm
Location: Columbia, MO, US
Contact:

Re: Material overhaul

Post by jdupuy »

For name conflicts, files are referred to internally using a UUID created when the model/card is created. This will make name conflicts irrelevant. It doesn't address the older version problem though. This will require some thought.
I like this!

A possible suggestion: have the UI selector use a different color/font/italics or some other visual marker for the names of user-provided cards vs default cards. That way if two "Obsidian" entries are present, you can easily tell if it is the default Obsidian material or the user's specific Obsidian material card.

Or, to make later python scripting easier, the visual marker could simply be punctuation in the string. So, Obsidian vs *Obsidian. Or, [Obsidian] vs Obsidian.

Also, a way-into-the-future comment: from the point of view of the Path workbench, I've long been hoping to use materials to control cutting paths with wood. These changes get me half-way there; allowing me to change travel and spin speeds based on specie of wood.

ignore the comment below. Having reviewed the forum and other items, people have been wanting grain direction, but again, I'd make that a "later project":

But the materials are currently assumed to be isomorphic: they don't have a direction (a 3d vector). It would be nice, if one day, they could have one. That way the spindle can change directions, speeds, (or even mill bit) depending on whether it is cutting cross-grain, with-grain, or an angle. And it would be nice if the visuals also showed the grain direction.

But adding a vector is probably a "something to do later" thing. IMO, I wouldn't worry about it right now. Not many people are clamoring for it. :D
jedbrown
Posts: 11
Joined: Fri Mar 31, 2023 3:45 pm
Contact:

Re: Material overhaul

Post by jedbrown »

Will the UUID change on each edit or only upon "creation"? What happens when a material is created and sent to a colleague, they edit parameters (like moduli, yield stress) and send it back. These are now two different materials with the same name. Are they related? Do they have the same or different UUID?

I think wood and other anisotropy should be represented by a field (can be spatially varying), and certainly not a vector defined in the material. Wood can be bent (e.g., steamed to make ribs in a boat), carbon fiber can be oriented arbitrarily, etc. Note that a vector (field) is not sufficient for general anisotropy. Equivariant constitutive models (those satisfying reference frame invariance) are typically modeled using a material tensor field.
Post Reply