Arch materials

[yorik]

I'm experimenting with materials for Arch objects, and find myself in a bit of a dilemma. Currently each Arch object has a "Material" property which can hold a material (dictionnary). This is cool because very flexible, and the material info is packed into the object. But of course there is the mainproblem that the info is duplicated (each object holds a copy of a material), and you cannot guarantee that two different objects, each with a material named "steel" use exactly the same values (both steel materials can be different).

The alternative used for ex. by the FEM workbench is to create a separate material object, and have each Arch object link to it.

But I don't like that much either because an Arch model can have a lot of materials and soon your tree will be cluttered with materials... Of course we could always store them in a folder...

Anybody has a better idea?

[rockn]

Hi Yorik,
What's the aim of the material property ?
Does IFC handle material property ?
Can we imagine that starting a FEM analysis from an Arch object, his material is automatically added to the analyst ?
Does the .FCMat handle texture ? To a future Textured View mode ?

Could it be just a String picked from the FEM material list ? Then when it's needed (like for IFC export, FEM analysis, Textured view mode), the string is analysed and the specific information is picked from the FCMat properties.
In this way, the string describe a specific material but don't handle too much information...

I'm agree that Steel, Wood etc ... are useless. For example for Wood structure I need to know what kind of wood it is (C24, GL24h, D30 etc) that describe exactly the mechanical property of the material and also his appearance.
About that : i have to create all FCMat file for wood.

[yorik]

Yes to all questions

The IFC exporter still doesn't handle materials, but once this is implemented in FreeCAD, I'll do that. The Arch materials are the same as FEM materials, so yes of course they will be usable in FEM. Once it is implemented the Analysis script will need to be modified to catch Arch materials if available, but that should be easy.

About textures, yes, the .FCMat definition is not complete (nor limited), so it is entirely possible, but we need to think about how to do that. Anyway that's for later.

Indeed the "Steel", "Wood" mats are not very useful at the moment. The idea is that people create more, as needed... But we already have a lot of steel materials... I think what we could do now is rename all the cards like this: Steel-Generic.FCMat, Wood-Generic.FCMat, etc... This will be easier to categorize. I'll do that now before it's too late

[rockn]

Ok, cool !
So what do you think of just added a String property with a combobox that display the material of FCMat available then enhanced the IFC exporter and FEM start analysis tool.
In fact I don't see the advantage to have a dictionary property for Arch object if there is yet all property in FCMat cards...
Perhaps a string is less robust or unusable to get the right FCMat cards...?

There is a discussion in FEM forum about different location of the FCMat cards : viewtopic.php?f=18&t=10490

[yorik]

It is a good idea, but the problem is this, then: You - as a user- create a new model, you assign a wood material to an object. Then, you see that the default wood material provided with FreeCAD is not what you want. You modify it, and save it as a new .FCMat. Then now when you distribute your model to someone else, you need to ship your .FCMat file together, and the other user needs to copy it to some folder... This is not very friendly, and the big advantage of FreeCAD is that all what's needed is always packed into the .FCStd file... I think we should do that here too...

The problem is that then indeed we loose the relationship with the original .FCMat, but I think that is exactly the idea: You create a material in FreeCAD from a .FCMat card, but, once it is in FreeCAD, it is independent from the card. Your model doesn't need the card anymore (you should of course be able to update it from a card).

These materials ARE dictionaries (key:value pairs), so that's not a problem. The question I'm asking myself is how to have several objects refer to the same material, without cluttering the tree with dozens of material objects...

[rockn]

Well I see, I have an idea. I will write it...
But now there is a problem with your last commit I think :

Code: Select all

CMake Error at src/Mod/Material/CMakeLists.txt:42 (ADD_CUSTOM_TARGET):
  Cannot find source file:

    /home/jo/Logiciels/FreeCAD/free-cad-code/FreeCAD_sf_master/src/Mod/Material/StandardMaterial/Concrete.FCMat

  Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
  .hxx .in .txx

[bernd]

Cool discussion what you guys do.

I would not use in Arch the way the materials are defined in Fem. We should find something better. In Fem they are defined the way it is easiest to export to calculation software CalculiX. My idea is to have some script which generates the Fem material object definition from the much better not yet existing Arch material definition.

I have allready been using materials in arch for month. I'm importing them from ifc. I've not been making pull request for this Shame on me. I just used property strings. But the thing is I don't exchange models an thus I know whats behind the strings. As you mentioned if one gives a model away it is just a string. The other doesn't know anything about it. Hey guys we are in the middle of the problems of the big ones (ArchiCAD and Revit and Vecor Works and Allplan.) They take thousands of dollars call it BIM and even haven't solved the problems. I have a docens modells of architects around but hundreds of differnt strings for concrete and none of the software can handle the materials of the others ...

The Arch materials are the same as FEM materials, so yes of course they will be usable in FEM.

Yes and no. In Arch it doesn't matter if it is C25/30 or C30/37 or C75/90, all are Concretes but in Fem it really matters. The youngs modulus is differnt for all off them.

I started to use three different Material definitions for each ArchObject.
MaterialArch
--> mostly for texture handling and colors --> Concrete --> fairfaced concrete or not, existant or new, precast or site concrete
MaterialEngineering
--> for structural calculations --> Concrete --> C25/30 or C30/37 or C75/90
MaterialCost
--> for calculating of cost --> depends even more like freezing and salt resistence and selfcompressing or not.

What I would like to say is we should try to be as flexible as possible because every person has different needs on material.

[yorik]

But now there is a problem with your last commit I think :

Oops.. I hadn't seen these files were enumerated in the cmake file... It should be fixed now.

About Bernd's comments: I agree 100%, if I'm designing a concrete building, as an architect, at least in the early stages of design, I don't need to bother with the concrete type. I could use a "generic" concrete material. Later on, this can be replaced, following the cases.

But the current materials system is good enough to support these different scenarios. All entries don't need to be filled in the materials card. All workbenches should always take care to check if an entry exists in a material card, and never suppose it will always be there (apart maybe from the obvious ones such as the material name). But the FEM wb does it correctly, and I'm doing it that way in the Arch wb too. So far so good.

You can even add more properties to the currently available in the FCMat scheme. The parser will handle them without problems. So it's very powerful.

But I think it is also good that you can "lock" things at the arch level, that is, you CAN specify a material that has all the settings set, including FEM properties, etc. For example in your scenario, I would imagine that, for example, all your engineering concrete materials also carry the architectural properties. But actually you could very well keep your current workflow too.

At the moment, if you open a material in the FEM module that has no young modulus, you can set (or modify) it in the task panel. I'm doing the same for Arch (for ex. you can change the color or the description on the fly). I wish there was a kind of online library of arch materials, but at least we can go building them bit by bit...

Back to my original problem, I think it will be hard to avoid using Material objects... Otherwise we'll have big problems later (several objects having "apparently" similar materials which are in reality different.

Maybe there would be something to do at the freecad level, like have a kind of separate section in the tree where materials would appear. But that's a rather big change of philosophy... For now we could simply create a group, though.

[saso]

This is indeed an interesting issue to think about and I wonder if it really makes sense to manage all this only from the materials. Just something to think, what if all the important Arch object would have all this as properties and materials would be just one way how to set them (a sort of quick default), but users could also set and reset them manually, by individual objects or groups (the new clones?) without the need to actually make a new material. This way all this properties would be directly part of the model (model objects) and there would be no need to share the materials when sharing the model. In this way, the only thing that would break when sharing the model with no materials would maybe be the textures for the rendering and personally I would not find that to bad

Edit to the above: So in a way the .FCMat files would only be sort of template files for material properties...

And to add one more thing to think about on this topic, it is also quite often the case with such properties of the building elements that you get only the properties of the complete element. For example the structural, thermal, sound, fire, price,... properties of the complete window, door, wall,... not the actual individual layers, elements and materials that they are made of.

So a sort of "material properties" of an building element that is a "group"...

[yorik]

Indeed at the moment the Arch clone objects only clone the shape of their parent. But it would be a piece of cake to have them clone the material too.

You're right about the windows, at the moment they have only one material slot, I was thinking of adding 2 others (one for the glass and a third one for eventual panel material), but this might deserve further thinking too, indeed you usually don't want to bother to specify the type of glass of each window you add...

Anyway, the more the discussion goes, the more I think the easiest way would be to have a kind of folder, containing all the materials of your model (made from scratch or picked/modified from a .FCMat card), and then pick in that folder to attribute materials to objects... What do you guys think? I'm a bit annoyed to have that folder lying around in my model tree, but it's actually a very small inconvenience that could gain a better idea later.