Material improvements

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!
eivindkvedalen
Posts: 602
Joined: Tue Jan 29, 2013 10:35 pm

Re: Material improvements

Post by eivindkvedalen »

yorik wrote: What about multi-solid objects? I think for example, to a window, which has metal (or wood) parts, and glass. Both Arch and FEM use a lot of these compounds (or compsolids soon!). One might hook the material to a toposhape, which might bring a lot of problems, not sure it's a good idea to go that way.
Wouldn't a window in principle be an assembly of multiple parts? In that case each part would have their own material. However, as I understand we now have compsolids, which are actual multiple solids. To support this, the material property needs to be able to address multiple separate solids. If we also stack materials as suggested in my previous post, a solid material specification will be a vector of vectors; each solid has a vector of materials. For surfaces, I would create a map (solid, face) -> vector of materials.

Eivind
eivindkvedalen
Posts: 602
Joined: Tue Jan 29, 2013 10:35 pm

Re: Material improvements

Post by eivindkvedalen »

ulrich1a wrote:Adding a material property is something, that is definitely needed.
I found some time ago this post from ickby: viewtopic.php?f=10&t=16021
where I started to think, if this can also be used to add all the missing properties in FreeCAD:
- material with all its subproperties: densitiy, youngs modulus, color, etc. wood would also need a direction, as it is an anisotropic material.
- face properties like threads or knurling (used for example in step-files)
- organisational properies like part-numbers, material cost ...
- manufacturing properties like tolerances, surface finish etc.
The material framework can be used (or abused) for this! Currently it's just a matter of registering new properties. This has to be done compile-time, but can be done by individual (C++) modules.

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

Re: Material improvements

Post by yorik »

To me the plan looks very good Eivind! Indeed there are many different cases, but it seems that what you are proposing will be pretty flexible. This topic is actually good to gather these cases...
eivindkvedalen
Posts: 602
Joined: Tue Jan 29, 2013 10:35 pm

Re: Material improvements

Post by eivindkvedalen »

Hi all,

I've had some progress with my material code, and have some code to share now. Please notice that this is in the very early stages. The code is at https://github.com/eivindkv/free-cad-code/tree/Material , almost rebased to most recent master.

Things more or less done:
- Added a MaterialDatabase class. This is the collection of various sources described below. Material queries happens from this database.
- Added a DefaultMaterialSource class. This source is read-only and contains the original pre-defined materials that could be selected in FreeCAD. It also contains a DEFAULT material, that all other materials can inherit from, to ensure that visual properties are defined.
- Added a DocumentMaterialSource class. Per-document materials are stored here. If visualization materials are changed, a copy is stored here.
- Added a FileMaterialSource class. FCMat materials cards are provided by this source. Multiple sources may be added (system/user).
- Added a PropertyPartMaterial class. This class and its helper classes encapsulates materials for solids and surfaces.
- Added a PropertyPartMaterial member Material to Part::Feature, along with its Shape.

I've been focusing on the data structure part now; almost nothing is done on the Gui part, except propagating material colors from the Material property to the view provider, so the colors of the parts change.

I have also added a Python interface (this is what I actually use for testing), and a typical use-case could be:

App.ActiveDocument.Box.Material.setSolidMaterial(0, "PLA");

This will assign the PLA material to solid 0 of Box. Properties can then be queried, e.g

App.ActiveDocument.Box.Material.Solid[0].YoungsModulus

Surface materials are accessed as e.g

App.ActiveDocument.Box.Material.Solid[0].setSurfaceMaterial(0, "GOLD")

(provided that Solid[0] has been set first).

The material databases are accessed either at App.getMaterialDatabase() or doc.MaterialDatabase (ideally they should have the same syntax; something for later). The material database in App is the application-wide database, so adding/removing/editing materials should be possible to do without an open document. The material database in the document links to the application-wide one, but also provides a private material source for materials specific for the document.

Please let me know what you think.

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

Re: Material improvements

Post by yorik »

I just browsed through your code Eivind, that's fantastic! (now I need to test...)

Awesome that you managed to unify all the bits and pieces of different material implementations throughout FreeCAD under one structure... that's really impressive! I like that the Material property is independent of the Shape property. So you can do App.ActiveDocument.Box.Material.setSolidMaterial(2, "PLA"); regardless of if there is a solid nr. 2 or not. That seems pretty solid to me. I also like the solids/surfaces materials, it seemed too much for me when you first talked about it, but I begin to see the picture, you have "generic" surface materials for all the non-solid situations (Mesh, Part shells, etc), and also solid materials that are very useful for cases that enforce solids (PartDesign, Arch). That makes a lot of sense.

A coupe of questions:

1) When creating a new document, a new material database is attached to that document, that contains a) legacy materials (the old Coin materials, bronze, gold, etc), b) the contents of system and user .FCMat cards and c) a place for document-specific materials. When saving the file, only part c) is saved together with the document, so when reopening the file, parts a) and b) are re-attached, right? What happens is a file is using a material card, but is opened on another machine that doesn't have that card? Are all materials used in a document always copied to c)? I couldn't find that...

2) You say the App Material Database is editable too? How would that work? Where would that be saved?

3) In your implementation, the properties that a material can have are hard-coded. No way for a user to add custom properties. I wonder if we should allow that or not... There are arguments on both sides...

4) Did you think about possible duplicates? Like, if you have a steel stored in the document materials, and another same steel in FCMats... Should that be left to the user to sort out? Some apps do that kind of "decision" for you, for ex. if you have a file with a material named concrete, on opening a file, Revit will discard "your" concrete and use "his" concrete, and I really don't like that...
damian
Posts: 583
Joined: Sun May 31, 2015 6:16 pm

Re: Material improvements

Post by damian »

Good Morning @eivindkv:
Thank you for 4.000 lines and 49 files of code. Incredible! :lol:
I don't know to read C++ code (the developer corner is not my territory!). However the material issue is transcendental for me and I would like to do a requests. Excuse me if I understood incorrectly your code or if I go too faster ('this is in the very early stages' :lol: ).

You said:
Also, each face may have multiple materials (e.g paint + silk print)
------
Also, a face may contain multiple surface materials (stacked in order)
------
for the solid specification, I think composition of several materials is the way to go. The composition should we stacked
------
Your idea of MaterialStack applied to surfaces (faces) is amazing. This is similar to Radiance's system, where a surface can carry an unlimited number of materials, plus an unlimited numbers of textures and patterns. This is the Everest talking about specification of surfaces. Congratulations!

My concerns is that I don't clearly see the MaterialComposition.

1º) will the MaterialComposition have layers?

2º) could a solid have a MaterialComposition? The question is with a single solid, no with a compsolids.

3º) how will the thickness of every layer be specified?

Thank you very much
User avatar
PrzemoF
Veteran
Posts: 3520
Joined: Fri Jul 25, 2014 4:52 pm
Contact:

Re: Material improvements

Post by PrzemoF »

Do we need to make any changes to the material files or scripts that are currently in the master to operate on the files and material spreadsheet?

I'm talking about this [1] and this [2]

[1] https://github.com/FreeCAD/FreeCAD/tree ... rdMaterial
[2] https://github.com/FreeCAD/FreeCAD/tree ... rial/Tools
eivindkvedalen
Posts: 602
Joined: Tue Jan 29, 2013 10:35 pm

Re: Material improvements

Post by eivindkvedalen »

PrzemoF wrote:Do we need to make any changes to the material files or scripts that are currently in the master to operate on the files and material spreadsheet?

I'm talking about this [1] and this [2]

[1] https://github.com/FreeCAD/FreeCAD/tree ... rdMaterial
[2] https://github.com/FreeCAD/FreeCAD/tree ... rial/Tools
No, one of the data sources reads (and will eventually write) the FCMat format, so there's no need to change this.

Eivind
eivindkvedalen
Posts: 602
Joined: Tue Jan 29, 2013 10:35 pm

Re: Material improvements

Post by eivindkvedalen »

yorik wrote:1) When creating a new document, a new material database is attached to that document, that contains a) legacy materials (the old Coin materials, bronze, gold, etc), b) the contents of system and user .FCMat cards and c) a place for document-specific materials. When saving the file, only part c) is saved together with the document, so when reopening the file, parts a) and b) are re-attached, right? What happens is a file is using a material card, but is opened on another machine that doesn't have that card? Are all materials used in a document always copied to c)? I couldn't find that...
Yes, the legacy materials and the system/user sources are always attached. Materials are not currently copied to the document; I'd like to avoid copying, as it makes the database fragmented and harder to maintain. The document-specific source is mainly now to store the colors of the solids/faces applied by the user. These need to be stored somewhere; before it was in the material property itself, but now each material object belongs to a source, thus it must be stored there. In the document, references to materials are stored by name. This means that if you open the file on a another machine without the system-wide materials, the material-lookup will fail. This must of course be handled in a graceful way.
yorik wrote: 2) You say the App Material Database is editable too? How would that work? Where would that be saved?
The Material database in App comprises the files-based sources, i.e the FCMat-based directories. Saving is not implemented yet for these file-based material sources. In general, each material object belongs to a source, and it will eventually be stored back to the source where it belongs if it is changed.
yorik wrote: 3) In your implementation, the properties that a material can have are hard-coded. No way for a user to add custom properties. I wonder if we should allow that or not... There are arguments on both sides...
Yes, they currently are hard-coded. If we stick to a pre-defined set of types, it is possible to define new properties. Providing type-safety is what makes this a bit tricky, because each type needs conversion functions both to and from python, but also to and from boost::any. However, I think type-safety is important, as it must be handled somewhere anyway, so having it in the "core" is probably best.
yorik wrote: 4) Did you think about possible duplicates? Like, if you have a steel stored in the document materials, and another same steel in FCMats... Should that be left to the user to sort out? Some apps do that kind of "decision" for you, for ex. if you have a file with a material named concrete, on opening a file, Revit will discard "your" concrete and use "his" concrete, and I really don't like that...
The material databases and sources are stacked, so when searching for a material, it will pick the one a the top of the stack.

Eivind
ickby
Veteran
Posts: 3116
Joined: Wed Oct 05, 2011 7:36 am

Re: Material improvements

Post by ickby »

Hello,

I have no clear picture about material support, but one note on the API: In the code examples you provided you access Materials like "Solid[0]", which indicates the usual freecad python subshape accessing scheme by index. Accessing subshapes however does also work by strings, like "Face1" or "Edge2" in TopoShape class which should also be supportet in your API. This may sound like splitting a hair, and it definitely is for the current situation. However, ezzy is currently working hard on topological naming. Once done it is quite likely that the string based subshape identification can use tnaming, as this is what the link properties use, but not the indexed based identification. So maybe it is a good idee to have that in mind while designing the API and the underlying data structure. Your code will suffer from naming issue like everything else that uses subshapes. And on second note it would be nice to have both options for specifying subahpes anyway :)
Post Reply