Home › Forum › SOFA › Using SOFA › [SOLVED] Duplicated components in xml export
Tagged: 64_bits, SOFA_other, Windows_10
- This topic has 5 replies, 3 voices, and was last updated 7 years, 9 months ago by Alex Bilger.
-
AuthorPosts
-
12 April 2016 at 08:21 #6527Alex BilgerBlocked
Hello guys,
I noticed a bad behavior when exporting a scene in xml. The components are duplicated within the same node. The node components are written, then the sub-nodes, and then the same node components again.
You can get the same behavior by opening any sofa scene and exporting it (File -> Save As in runSofa), then open it in a text editor.
I see that the xml export uses visitors. I found that the objects are processed twice: once in processNodeTopDown and once in processNodeBottomUp. So I removed the processing part in processNodeBottomUp, and kept only the node closure. I get the expected behavior. Could you guys confirm this is the right thing to do?
I tested on Windows with a very recent commit.21 April 2016 at 13:55 #6556GuillaumeKeymasterHi Alex,
I confirm this problem.
Here is the fix you propose, correct me if I’m wrong.void XMLPrintVisitor::processNodeBottomUp(simulation::Node* node) { /* for (simulation::Node::ObjectIterator it = node->object.begin(); it != node->object.end(); ++it) { sofa::core::objectmodel::BaseObject* obj = it->get(); if ( obj->toBaseInteractionForceField() == NULL && obj->toBaseInteractionConstraint() == NULL && obj->toBaseInteractionProjectiveConstraintSet() == NULL && obj->toBaseLMConstraint() == NULL ) this->processObject(obj); } */ --level; for (int i=0; i<level; i++) m_out << "\t"; m_out << "</Node>"<<std::endl; }
The lines commented were added by old commit #340cf88f with comment “CHANGE XMLPrintVisitor to put interaction classes after children nodes. Also reactivate full DataTypes tests in PairInteractionForceField::canCreate as a consequence.”.
I don’t know if this is still relevant.Regards,
Guillaume.21 April 2016 at 14:28 #6562Alex BilgerBlockedThis is what I propose and it seems to work for me. Maybe this fix does not work in the context of the commit you mentioned, I don’t know. If we keep this code, then maybe the condition to process the object is not right?
I also would like to highlight a problem with xml export: when exporting, we loop over the objects and write all the data in this object. This is not correct as some component compute things differently if some data are provided or not. This means the initialization is not the same with the exported scene than in the initial one. I don’t have a fix for that. Maybe by writing only the provided data? But that would mean to write file names instead of the position/faces in the case of a MeshLoader for instance.
Alex
7 June 2016 at 10:25 #7069GuillaumeKeymasterHi Alex,
Since we migrated to GitHub recently, I just opened a pull request with your fix: https://github.com/sofa-framework/sofa/pull/4
Next time, do not hesitate to do the same!
Cheers,
Guillaume.20 December 2016 at 13:47 #8228HugoKeymaster20 December 2016 at 14:20 #8229Alex BilgerBlockedThanks, I’ll open a pull request next time.
-
AuthorPosts
- You must be logged in to reply to this topic.