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

Material improvements

Post by eivindkvedalen »

Hi,

As mention in the Help forum, I've started working on better material support in FreeCAD. These are the changes/additions I want to implement:
1) Extend and modify the Material class to support arbitrary, but pre-defined, properties.

This is done by adding a vector of boost::any variables. This will provide a type-safe way of accessing various properties, minimizing conversion code throughout FreeCAD. The currently existing member variables are replaced by functions calls accessing this vector. These should be exposed in python as normal attributes.

2) Add a material property to the class/classes that represent a solid.

This property needs to handle the material for the solid itself, but also the surface. This is done by having a single reference for the solid, and a map of faces -> materials for the surface. This makes it possible to color different faces of a solid. Also, each face may have multiple materials (e.g paint + silk print).

3) Add infrastructure for a material database.

This is done to unify access to the materials. Two main classes are defined: MaterialDatabase and MaterialSource. A database is basically a collection of sources. One of the sources will be the standard FCmat files already defined and used.

I don't think these changes will be very intrusive to the already existing material support in FreeCAD; in fact my gut feeling is that this will simplify things, and code in other workbenches can be minimized.

For the moment I don't have any code worth sharing; what I have barely compiles, doesn't have all the functions, and most likely doesn't work properly yet :)

Eivind
User avatar
NormandC
Veteran
Posts: 18587
Joined: Sat Feb 06, 2010 9:52 pm
Location: Québec, Canada

Re: Material improvements

Post by NormandC »

Hello Eivind,
eivindkvedalen wrote:Also, each face may have multiple materials (e.g paint + silk print).
Do you mean that we could apply a bitmap image on a face, and have it stored into the model?
eivindkvedalen
Posts: 602
Joined: Tue Jan 29, 2013 10:35 pm

Re: Material improvements

Post by eivindkvedalen »

NormandC wrote:Hello Eivind,
eivindkvedalen wrote:Also, each face may have multiple materials (e.g paint + silk print).
Do you mean that we could apply a bitmap image on a face, and have it stored into the model?
That is my goal, but I don't know if that is possible or not with the current graphical framework FreeCAD uses.

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

Re: Material improvements

Post by yorik »

Excellent plan!!!

I agree with you, this could simplify a lot material handling throughout FreeCAD. At the moment we have many scripts (in Material, in Arch, in FEM,...) that all do a lot of the same things. From my point of view, the most important points are:

- proper unit handling (values in material cards are often expressed in different units that are not always well handled ATM)
- unified way to work with several materials per object (both FEM and Arch do it in different ways)
- unified way to handle material objects in a FreeCAD document (currently objects that have a material in arch or fem use a propertylink to link to a material object that stores the material info itself, but both have differetn ways to edit/update the material object)
eivindkvedalen wrote:I don't know if that is possible or not with the current graphical framework FreeCAD uses.
I think it is possible, but you might need to tweak the ViewProviders a lot (create many different coin materials, textures, etc). Supporting textures will also bring a lot of additional issues (texture size and orientation, also called mapping, etc). I would definitely separate the two subjects.
eivindkvedalen
Posts: 602
Joined: Tue Jan 29, 2013 10:35 pm

Re: Material improvements

Post by eivindkvedalen »

yorik wrote:Excellent plan!!!
Thank you! :)
yorik wrote: - proper unit handling (values in material cards are often expressed in different units that are not always well handled ATM)
In C++ this is handled in a type-safe way; boost::any does this. In Python, the C++ types are now mirrored, so a Quantity type in C++ will be a Quantity in Python as well. Same for all other types. To make this work, the property name and type must be registered in the database. Currently this is done compile-time. This is not ideal, but I need to have conversion functions from string to boost::any and from boost::any to PyObject (and vice versa). New types can in principle be defined by modules, but I haven't exposed the interface for this yet.
yorik wrote: - unified way to work with several materials per object (both FEM and Arch do it in different ways)
In my design that is 1 material per solid + n surface materials. A surface material may span the complete surface, or just a face. Also, a face may contain multiple surface materials (stacked in order). Does that cover the needs for Arch and FEM?
yorik wrote: - unified way to handle material objects in a FreeCAD document (currently objects that have a material in arch or fem use a propertylink to link to a material object that stores the material info itself, but both have differetn ways to edit/update the material object)
I think the material(s) should be a property of the solid. Is Part::Feature the place to put this? This is where the shape is stored, and I think this is the most low-level solid in FreeCAD?
yorik wrote:I think it is possible, but you might need to tweak the ViewProviders a lot (create many different coin materials, textures, etc). Supporting textures will also bring a lot of additional issues (texture size and orientation, also called mapping, etc). I would definitely separate the two subjects.
This is not first priority :)

Another question regarding the Python material interface. Material today have both a constructor and a set method. This doesn't fit very well into my current plan. How much will things break if we remove these two functions? They would basically be replaced by a database access to get the materials, something like:

mat = db.getMaterial("GOLD")

to get an existing one, or

mat = source.createMaterial("PLATINUM")

to create a new material in the given source.

Material properties are accessed like

mat.YoungsModulus

in Python, and something like

boost::any_cast<float>(mat->getProperty("YoungsModulus")) in C++.

(In C++ properties can be indexed by a numeric ID as well, to speed things up).

There will be different sources. I have defined three already:
- DefaultMaterialSource: All legacy materials for visualization. These only contain the color definitions.
- FileMaterialSource: This contains materials in FCMat format.
- DocumentMaterialSource: This may contain materials created for the document owning the source. In its most basic use, if you modify the color of an object, a copy will be stored here (not implemented yet!).

FileMaterialSource may be added multiple times, so it can be used for both system and user-defined materials.

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

Re: Material improvements

Post by yorik »

eivindkvedalen wrote: I think the material(s) should be a property of the solid. Is Part::Feature the place to put this? This is where the shape is stored, and I think this is the most low-level solid in FreeCAD?
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.

Maybe the best way would be to work a bit like the DiffuseColor property (an array of materials). That might require more thinking, though. Not sure we want one item in the array for each face... Also what happens for objects with non-solid shapes, etc.

I think your changes to the python API would not be a big problem,ATM both Arch and FEM are still in a state where doing those changes would be easy, specially if it's for the greater good ( mat.YoungsModulus for example :) )
User avatar
bernd
Veteran
Posts: 12849
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland
Contact:

Re: Material improvements

Post by bernd »

Your ideas sounds great to me eivind!

+1 to yoriks post.

Managing the materials in a building modell will be really a challange ... Just some ideas in the regard of solid (volume) material ...

I'm not really sure yet if we should only allow one material for an volume object (solid or whatever) In real world design off a building I can imagin dozens of attributes for materials. If only one attribute is different one has to use a different material. Resulting in dozens different materials. An simple example.

For most people involved in planing a building concrete is one material. This is fine for all people and for all building models of this building except one person, me. I use in my calculations (FEM) two or three differend concrete materials with a different youngs modulus. But as said before all others do not need to know these are different concrete types. It is even not visible on the drawings just in my calculation.

Normally this does not matters, because every person (architect, structural engineer, cost calculator, light engineer, electrical engineer, water engineer, what ever engineer is needed for a building ) has its own software, its own building modell and its own materials. FreeCAD is the only software (at the moment) which could combines different models and thus different materials from different persons in one building model.
ulrich1a
Veteran
Posts: 1957
Joined: Sun Jul 07, 2013 12:08 pm

Re: Material improvements

Post by ulrich1a »

Adding a material property is something, that is definitely needed.
How to achieve this also in case of compsolids is a good question. Do have compsolids more than one volume, like a shape has more than one face?

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.

Ulrich
ulrich1a
Veteran
Posts: 1957
Joined: Sun Jul 07, 2013 12:08 pm

Re: Material improvements

Post by ulrich1a »

ulrich1a wrote:Do have compsolids more than one volume, like a shape has more than one face?
Found the answer. A compsolid has more than one "Solid". So the material property has to be a subproperty of the Solid.

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

Re: Material improvements

Post by eivindkvedalen »

bernd wrote:Your ideas sounds great to me eivind!
...

For most people involved in planing a building concrete is one material. This is fine for all people and for all building models of this building except one person, me. I use in my calculations (FEM) two or three differend concrete materials with a different youngs modulus. But as said before all others do not need to know these are different concrete types. It is even not visible on the drawings just in my calculation.
Thank you for your feedback. This can be achieved by using inheritance; materials have a Father property to specify that. I already have support for this. In this way it is possible to override properties like youngs modulus. However, inheritance may not be the right answer, so for the solid specification, I think composition of several materials is the way to go. The composition should we stacked, so it is possible to override other properties. I think inheritance and stacked composition will solve most problems of material specialization.

For surface materials, I think we shall interpret the stack as several individual materials; the intention here is to say something about the actual manufacturing, e.g paint, silk-print, special coatings, etc. To override certain properties here will require inheritance, but I think that is ok.

Eivind
Post Reply