Std_MergeProject: Behavior of materials?

A forum to discuss the implementation of a good Materials system in FreeCAD
Roy_043
Posts: 545
Joined: Thu Dec 27, 2018 12:28 pm

Std_MergeProject: Behavior of materials?

Postby Roy_043 » Mon Sep 30, 2019 1:00 pm

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 411 times
Last edited by Roy_043 on Mon Sep 30, 2019 7:49 pm, edited 1 time in total.
vocx
Posts: 1886
Joined: Thu Oct 18, 2018 9:18 pm

Re: Std_MergeProjects: Behavior of materials?

Postby vocx » Mon Sep 30, 2019 5:34 pm

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.
vocx
Posts: 1886
Joined: Thu Oct 18, 2018 9:18 pm

Re: Std_MergeProject: Behavior of materials?

Postby vocx » Tue Oct 01, 2019 12:50 am

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.
vocx
Posts: 1886
Joined: Thu Oct 18, 2018 9:18 pm

Re: Std_MergeProject: Behavior of materials?

Postby vocx » Tue Oct 01, 2019 12:58 am

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?
realthunder
Posts: 1231
Joined: Tue Jan 03, 2017 10:55 am

Re: Std_MergeProject: Behavior of materials?

Postby realthunder » Tue Oct 01, 2019 1:49 am

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 (latest version 0.10.2) along 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
Roy_043
Posts: 545
Joined: Thu Dec 27, 2018 12:28 pm

Re: Std_MergeProject: Behavior of materials?

Postby Roy_043 » 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.
User avatar
bernd
Posts: 8486
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland

Re: Std_MergeProject: Behavior of materials?

Postby bernd » Wed Oct 02, 2019 4:53 am

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
Site Admin
Posts: 14999
Joined: Thu Feb 19, 2009 10:32 am

Re: Std_MergeProject: Behavior of materials?

Postby wmayer » Wed Oct 02, 2019 8:10 am

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.
Roy_043
Posts: 545
Joined: Thu Dec 27, 2018 12:28 pm

Re: Std_MergeProject: Behavior of materials?

Postby Roy_043 » Wed Oct 02, 2019 10:18 am

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
Posts: 8486
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland

Re: Std_MergeProject: Behavior of materials?

Postby bernd » Wed Oct 02, 2019 10:54 am

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