Std_MergeProject: Behavior of materials?
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Std_MergeProject: Behavior of materials?
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 (7.17 KiB) Viewed 11082 times
Last edited by Roy_043 on Mon Sep 30, 2019 7:49 pm, edited 1 time in total.
Re: Std_MergeProjects: Behavior of materials?
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.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.
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 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.
To support the documentation effort, and code development, your donation is appreciated: liberapay.com/FreeCAD.
Re: Std_MergeProject: Behavior of materials?
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.
To support the documentation effort, and code development, your donation is appreciated: liberapay.com/FreeCAD.
Re: Std_MergeProject: Behavior of materials?
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.
To support the documentation effort, and code development, your donation is appreciated: liberapay.com/FreeCAD.
-
- Veteran
- Posts: 2190
- Joined: Tue Jan 03, 2017 10:55 am
Re: Std_MergeProject: Behavior of materials?
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?
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?
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 ...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.
Re: Std_MergeProject: Behavior of materials?
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.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.
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?
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.
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?
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
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