No, the matter in a solid consists of a single material. However, this is described by a list of materials. The difference between the composition and the stack is the way how the look-up of its properties is done.
For a composition, the look-up is started at the top of the stack, and the first match is returned. This makes it possible to override sub-sets of a material by stacking another on top. E.g if you read the post by bernd, he would like to have concrete with different values for YoungsModulus. This is possible by having a “standard” concrete at the bottom of the stack, and then different materials with only one property (or a few), YoungsModulus, that differentiates one type of concrete from another.
For surfaces, think of the stack as a bunch of physical layers. When searching for a property, you must first specify the layer in which to do the look-up. As an example, think of an object with a background color and a silk-print on top. One layer would then specify the background color, and the second one could specify a transparent texture that would be put on top. This is how I envision it; it is not implemented yet
2º) could a solid have a MaterialComposition? The question is with a single solid, no with a compsolids.
Each solid is a MaterialComposition object, and the Material property contains an array of solids to cover compsolids.
3º) how will the thickness of every layer be specified?
This could be specified as a property, but would not easily be reflected in the geometric model.
Yes, I know this structure will face the same problems wrt topological naming. I can add string based look-up to the API for completeness; the implementation will most likely change a lot when topological naming is sorted out.
No problem i just wanted to make sure i will try out the latest code. I tried to compile the code today and it looks like 2 files are missing. In src/App/Application.cpp (line 115 and 116):
Yes i did that but it didn’t help. I got a lot of errors after for example:
error: ‘FileMaterialSource’ was not declared in this scope
_pMaterialDatbase->addMaterialSource(std::make_shared<FileMaterialSource>("System", system_dir.c_str()));
note: forward declaration of ‘class App::MaterialDatabase’
class MaterialDatabase;
I can confirm this branch compiles now. There are still some (very likely not your changes related) issues involved and i needed to disable few modules to successfully compile your branch. Likely related to this:
Therefore you might want to provide a branch containing the latest changes in the future for other testers compiling without issues. I tested as described:
I think that the PLA material definition isn’t in the right location; I think I had to copy the files manually when testing. The file-based materials are supposed to be in either
I tested this by moving materials in all mentioned locations and tested a few more. The same issue was always produced. Therefore best to leave it as it is for now and in the future when you will start working on it again we can test further.
I think i got the general idea. Your work will very likely enable FreeCAD and all its modules to use materials in straightforward fashion in the future.
Thank you for taking to do the rebasing, iirc I got some conflicts last time I looked into this. Currently I’m super busy, so I’m not sure when I can work more on this. Also, I’d like to finish the hole-feature first, as that is closer to completion…
No worries! I’ll try to keep my branch rebased occasionally. Might even try to do a bit of work on it once a few other things are popped off the TODO stack.
Lately I did some development on Material module of FreeCAD. I started to sort out some devs but stopped because einvind did all the work already. He even did it ten times better than just some better Python devs for material handling. OK, I gave it a try and started to rebase eivinds branch https://github.com/eivindkv/free-cad-code/tree/Material2 but had to give up. To much conflicts on FreeCADs insides on C++ I do not have a glue how to solve. It would be really cool if we could give this great development new live and somehow could rebase it on master …
It’s good to see attention in this area bernd. I think it will be easier for you to update from the branch on my github mentioned a few posts back here, rather than eivind’s original work. I’ll try to update that branch sometime soon - not likely to be in the next week as I have some work to get done on the car which has a hard deadline…
BTW you will get some problems with material-editor.ui This is something I changed lately and I would fix if all the other would compile and run. Just checkout one of the ui files.