yorik wrote:Excellent plan!!!
- 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.
- 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?
- 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
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.