Std_MergeProject: Behavior of materials?

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
User avatar
Roy_043
Veteran
Posts: 8450
Joined: Thu Dec 27, 2018 12:28 pm

Std_MergeProject: Behavior of materials?

Post by Roy_043 »

What should happen if Std_MergeProject (BIM_Library relies on this) is used? The current behavior: Create another materials node and add duplicate material definitions is not ideal IMO.
Attachments
Materials_After_Merge.png
Materials_After_Merge.png (7.17 KiB) Viewed 10902 times
Last edited by Roy_043 on Mon Sep 30, 2019 7:49 pm, edited 1 time in total.
vocx
Veteran
Posts: 5197
Joined: Thu Oct 18, 2018 9:18 pm

Re: Std_MergeProjects: Behavior of materials?

Post by vocx »

Roy_043 wrote: Mon Sep 30, 2019 1:00 pm What should happen if Std_MergeProjects (BIM_Library relies on this) is used? The current behavior: Create another materials node and add duplicate material definitions is not ideal IMO.
The Std MergeProject command seems to be defined by the basic Gui system, so this is probably something that the core C++ developers should address.

https://github.com/FreeCAD/FreeCAD/blob ... c.cpp#L320

The function that actually does the merging seems to be MergeDocuments::importObjects()

https://github.com/FreeCAD/FreeCAD/blob ... c.cpp#L359

This seems to be defined in src/Gui/MergeDocuments.h and MergeDocuments.cpp

https://github.com/FreeCAD/FreeCAD/blob ... s.cpp#L143

Code: Select all

std::vector<App::DocumentObject*>
MergeDocuments::importObjects(std::istream& input)
{
    this->nameMap.clear();
    this->stream = new zipios::ZipInputStream(input);
    XMLMergeReader reader(this->nameMap,"<memory>", *stream);
    std::vector<App::DocumentObject*> objs = appdoc->importObjects(reader);

    delete this->stream;
    this->stream = 0;

    return objs;
}
I don't know how this works exactly but it seems it just simply reads and merges the XML data of the input document. I don't think it does any sort of analysis of the data to see what to import or to exclude. So, maybe it just does a "dumb" merging of the XML tags, which is why you get duplicate Material objects.

I suggest to move this thread to open discussion so that more developers take a look at it. I think it would also make sense to create a tracker issue because this is about the base system, and not particular to Material or the BIM Workbench.
Always add the important information to your posts if you need help. Also see Tutorials and Video tutorials.
To support the documentation effort, and code development, your donation is appreciated: liberapay.com/FreeCAD.
vocx
Veteran
Posts: 5197
Joined: Thu Oct 18, 2018 9:18 pm

Re: Std_MergeProject: Behavior of materials?

Post by vocx »

Roy_043 wrote: Mon Sep 30, 2019 1:00 pm ...Create another materials node and add duplicate material definitions is not ideal IMO.
What should the expected behavior be? Take the materials from one node and place them all inside a single material, and remove the duplicates?

That sounds like a feature request.
Always add the important information to your posts if you need help. Also see Tutorials and Video tutorials.
To support the documentation effort, and code development, your donation is appreciated: liberapay.com/FreeCAD.
vocx
Veteran
Posts: 5197
Joined: Thu Oct 18, 2018 9:18 pm

Re: Std_MergeProject: Behavior of materials?

Post by vocx »

realthunder wrote: Sun Sep 29, 2019 10:31 am ping
Hi realthunder, ping again. I think you modified a bit the src/App/MergeDocuments.cpp code. But did you change the way the documents are merged? Or what the OP describes already was the standard before? That is, were two material objects created after merging?
Always add the important information to your posts if you need help. Also see Tutorials and Video tutorials.
To support the documentation effort, and code development, your donation is appreciated: liberapay.com/FreeCAD.
realthunder
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

Re: Std_MergeProject: Behavior of materials?

Post by realthunder »

vocx wrote: Tue Oct 01, 2019 12:58 am Hi realthunder, ping again. I think you modified a bit the src/App/MergeDocuments.cpp code. But did you change the way the documents are merged? Or what the OP describes already was the standard before? That is, were two material objects created after merging?
This looks like the correct behavior, that is, import all objects from the other document and rename them if necessary to avoid name collision.
Try Assembly3 with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
User avatar
Roy_043
Veteran
Posts: 8450
Joined: Thu Dec 27, 2018 12:28 pm

Re: Std_MergeProject: Behavior of materials?

Post by Roy_043 »

I understand the logic behind the current behavior. But certain nodes like "Materials", but also "Layers", should exist only once in the document I think. If you insert 10 chairs with the BIM_Library command you don't want to end up with 10 "Materials" nodes and 10 "Wood" materials that, apart from their names, are identical.
User avatar
bernd
Veteran
Posts: 12849
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland
Contact:

Re: Std_MergeProject: Behavior of materials?

Post by bernd »

Roy_043 wrote: Tue Oct 01, 2019 7:11 am I understand the logic behind the current behavior. But certain nodes like "Materials", but also "Layers", should exist only once in the document I think. If you insert 10 chairs with the BIM_Library command you don't want to end up with 10 "Materials" nodes and 10 "Wood" materials that, apart from their names, are identical.
From user point of view I must admit it makes sense what you said. Adding a ticket on mantis might not be a bad idea ...
wmayer
Founder
Posts: 20242
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: Std_MergeProject: Behavior of materials?

Post by wmayer »

Roy_043 wrote: Tue Oct 01, 2019 7:11 am I understand the logic behind the current behavior. But certain nodes like "Materials", but also "Layers", should exist only once in the document I think. If you insert 10 chairs with the BIM_Library command you don't want to end up with 10 "Materials" nodes and 10 "Wood" materials that, apart from their names, are identical.
Well this might be the logic of your use case but there might be other use cases with different logic where multiple materials or layers are required. So, from an implementation point of view the Merge function must not make any assumptions of what might be useful or not.

Then, you can also create several materials or layers via Python or create a project file with several instances. There is nowhere any mechanism either to forbid this.

So, if you want an instance to control this behaviour you must implement a document observer e.g. in Arch that checks how many materials/layers are inside a document after loading/merging a project and let it automatically delete the superfluous ones.

It's probably best to register the observer when entering the Arch wb and un-register it when leaving the wb.
User avatar
Roy_043
Veteran
Posts: 8450
Joined: Thu Dec 27, 2018 12:28 pm

Re: Std_MergeProject: Behavior of materials?

Post by Roy_043 »

Just to clarify:
I obviously do not want to restrict the use of materials to a single material. But having multiple "Materials" nodes each containing duplicate materials in the same document is undesirable. I don't think that I am alone in this, so this is not a unique use case.
In the '10 chairs scenario' you would end up with 10 materials ("Wood" - "Wood009"), all the same (except for their names), but none of them would be superfluous I think: All 10 materials are references once.
User avatar
bernd
Veteran
Posts: 12849
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland
Contact:

Re: Std_MergeProject: Behavior of materials?

Post by bernd »

we need to distinguish:

The node:
- I do not see any use case to have duplicate material or layer nodes in the document tree. (these are groups aren't they?)
- This is AFAIK not possible to archive in ArchWB with the GUI, not even in Python with standard Arch methods

The objects itself, materials and the layers:
- It should be up to the user if the materials from two documents get merged and how they get merged if there are duplicates.

I see werners point. There could be hundreds and thousands of different kind of objects thus in general there will be a duplicate and only for special objects it could be different.

Eventually it is a feature request for these Arch obejects and not a bug.

bernd
Post Reply