Ideas needed: Xref

A forum dedicated to the Arch module development
cwstirk
Posts: 15
Joined: Thu Dec 05, 2013 7:07 pm

Re: Ideas needed: Xref

Postby cwstirk » Thu Mar 02, 2017 5:08 am

The CAX-IF recommended practice for STEP external references is here
https://www.cax-if.org/documents/rec_pr ... ef_v21.pdf
Many CAD modelers, viewers, and translators support STEP external references.
https://www.cax-if.org/vendor_info.php? ... &comp_id=5
It contains useful concepts that you can use, and refers to the PDM Schema usage guide, which is much older and rarely implemented. The new AP242 BO Model XML Assembly Structure is also not widely implemented yet.

STEP Part 21 edition 3 is probably the best future solution through anchor and reference capabilities (along with UIUD, digital signatures, and javascript), though there are only demonstration implementations so far and it has not been incorporated into the public CAX-IF recommended practices. It looks like the latter are coming based on what LOTAR and the CAX-IF are up to privately.
User avatar
yorik
Site Admin
Posts: 8633
Joined: Tue Feb 17, 2009 9:16 pm
Location: São Paulo, Brazil
Contact:

Re: Ideas needed: Xref

Postby yorik » Thu Mar 02, 2017 2:31 pm

Interesting document, thanks! It could give us more ideas.

As usual, I'm planning to implement this in python, inside the Arch WB, because it's faster and easier to experiment and modify, but as usual in freecad, if it works well, a more robust and more freecad-wide version can be recoded later in c++.
triplus
Posts: 4985
Joined: Mon Dec 12, 2011 4:45 pm

Re: Ideas needed: Xref

Postby triplus » Thu Mar 02, 2017 3:54 pm

Well if that is the case the simplest solutions in my opinion would be:

  • Copy/paste the functionality from Assembly 2 module.
  • Or work on Assembly 2 module directly if this piece of functionality needs additional work.

The reason on why that makes sense to me is everything you wrote you would need to implement Assembly 2 module already does now. It works with external documents and it knows on how to extract the simplified geometry from the external files.

I know you might not like the idea too much as you are interested in Arch. But if you would do that i am 99% sure somebody else would emerge and do some work on making the assembly solver more robust. I am guessing it's mainly math therefore somebody good at math would be needed. And as Assembly 2 module never got merged in master it always was considered as something of a temporary nature. But the years went by and it's still alive and kicking.
Jee-Bee
Posts: 624
Joined: Tue Jun 16, 2015 10:32 am
Location: Netherlands

Re: Ideas needed: Xref

Postby Jee-Bee » Thu Mar 02, 2017 5:07 pm

triplus wrote:Well if that is the case the simplest solutions in my opinion would be:

  • Copy/paste the functionality from Assembly 2 module.
  • Or work on Assembly 2 module directly if this piece of functionality needs additional work.

The reason on why that makes sense to me is everything you wrote you would need to implement Assembly 2 module already does now. It works with external documents and it knows on how to extract the simplified geometry from the external files.


I think i agree with this.
User avatar
yorik
Site Admin
Posts: 8633
Joined: Tue Feb 17, 2009 9:16 pm
Location: São Paulo, Brazil
Contact:

Re: Ideas needed: Xref

Postby yorik » Fri Mar 03, 2017 2:35 pm

The assembly2 actually opens the other document under the hood, then transfers the objects from the new document into the existing one. That works for small documents, but would be very slow for large ones. That's what I want to avoid actually
ickby
Posts: 2457
Joined: Wed Oct 05, 2011 7:36 am

Re: Ideas needed: Xref

Postby ickby » Fri Mar 03, 2017 3:13 pm

Yorik, I agree that we need something well thought for this problem. We cannot load the whole document, that would kill FreeCAD memory wise. I generally like the idea of only importing the scene graph for fast and eaesy handling. However, at some point a user would want to interact with the file somehow, select a face, measure a volume etc. It would be a shame if this would not be supported, as this would make the file unusable for assemlies or any detailled queries. A Idea of mine to solve this is delayed loading.

1. On import only the scene graph is imported. This could be stored in the document like DeepSoics idea with the tip list as basis
2. The xml file, which contains the document structure, is hold in a special type for later processing, lets call it JustInTimeDocument
3. If a user access a geometry shape the JustInTimeDocument loads that special object by reading in the xml file data and everything that is need additionaly and provides that temporary object. One step further is to load only what is required. Some properties can be derived from the xml alone, some may need the extra files that come with FcStd.

As for very large project the user will not require all documents, and never select all of them for some task. Hence this would be way less resource intensive than a full file load. One could even create a garbage collector of some kind to release the objects again if not needed anymore.

I think this is not doable from python, and is a serious effort, but would be awesome to have!
triplus
Posts: 4985
Joined: Mon Dec 12, 2011 4:45 pm

Re: Ideas needed: Xref

Postby triplus » Fri Mar 03, 2017 4:17 pm

OK therefore Assembly 2 loads the complex geometry from a file and extracts the simplified version of geometry and uses that. To be honest i don't see an issue here? You do need to load simplified version of the geometry from the external file somehow? There is no way around that?

If the process can be improved and to be made more efficient that would always be welcomed.
User avatar
yorik
Site Admin
Posts: 8633
Joined: Tue Feb 17, 2009 9:16 pm
Location: São Paulo, Brazil
Contact:

Re: Ideas needed: Xref

Postby yorik » Sat Mar 04, 2017 3:10 pm

ickby wrote:1. On import only the scene graph is imported. This could be stored in the document like DeepSoics idea with the tip list as basis
2. The xml file, which contains the document structure, is hold in a special type for later processing, lets call it JustInTimeDocument


I see your idea.. One would have a file that contains only the openinventor nodes of another file. Then, for example, you would double-click one of these "ghost" objects, and under the hood, that object would be fully loaded from the file, allowing you to edit it. That seems spendid! Indeed it is a much heavier thing, and you are right, certainly not doable in python. There are complications like, when you edit such an embedded object, then "close" it, the iv node of the whole file would need to be updated, without opening the file...

But we can still make a python prototype to experiment with I think, see how the imported iv behaves, etc. That would be useful anyway when doing the real thing :)

ickby wrote:3. If a user access a geometry shape the JustInTimeDocument loads that special object by reading in the xml file data and everything that is need additionaly and provides that temporary object. One step further is to load only what is required. Some properties can be derived from the xml alone, some may need the extra files that come with FcStd.


I think the mergeDocument code in src/Gui can already do a good part of what you described, load only one object from a file, etc.

Actually the PartDesign Part object could be used here, it doesn't do any shape computation, so it would fit well for arch stuff. I remember @DeepSoic commenting on something like that already...

One thing is a turning point here I think: Everything we described so far relies on the scenegraph. So it would be a pure GUI functionality, not available in non-GUI mode. The App part would just contain a link to the embedded file and that's it. But I think that makes sense, a program wouldn't need the visual representation anyway, the file link would be sufficient for it to reconstruct the whole file if needed.
triplus
Posts: 4985
Joined: Mon Dec 12, 2011 4:45 pm

Re: Ideas needed: Xref

Postby triplus » Sat Mar 04, 2017 5:10 pm

yorik wrote:One would have a file that contains only the openinventor nodes of another file. Then, for example, you would double-click one of these "ghost" objects, and under the hood, that object would be fully loaded from the file, allowing you to edit it.


Effectively ending up doing what Assembly 2 already does.

P.S. I realised i look at it more from the user point of view anyway. And after few years of involving myself in discussions around this area i feel i got this part figured out for now. As for any future development regarding this area good luck and thanks in advance.
User avatar
yorik
Site Admin
Posts: 8633
Joined: Tue Feb 17, 2009 9:16 pm
Location: São Paulo, Brazil
Contact:

Re: Ideas needed: Xref

Postby yorik » Sat Mar 25, 2017 2:56 pm

How they do it in digital project. Pretty similar to what we are discussing here...
phpBB [video]