Page 1 of 1
Std_MergeProject: Behavior of materials?
Posted: Mon Sep 30, 2019 1:00 pm
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.
Re: Std_MergeProjects: Behavior of materials?
Posted: Mon Sep 30, 2019 5:34 pm
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.
Re: Std_MergeProject: Behavior of materials?
Posted: Tue Oct 01, 2019 12:50 am
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.
Re: Std_MergeProject: Behavior of materials?
Posted: Tue Oct 01, 2019 12:58 am
by vocx
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?
Re: Std_MergeProject: Behavior of materials?
Posted: Tue Oct 01, 2019 1:49 am
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.
Re: Std_MergeProject: Behavior of materials?
Posted: Tue Oct 01, 2019 7:11 am
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.
Re: Std_MergeProject: Behavior of materials?
Posted: Wed Oct 02, 2019 4:53 am
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 ...
Re: Std_MergeProject: Behavior of materials?
Posted: Wed Oct 02, 2019 8:10 am
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.
Re: Std_MergeProject: Behavior of materials?
Posted: Wed Oct 02, 2019 10:18 am
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.
Re: Std_MergeProject: Behavior of materials?
Posted: Wed Oct 02, 2019 10:54 am
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