Ideas needed: Xref

[yorik]

Now that was a looong winding road for you lot to walk before you got back to what I originally proposed at the beginning of this thread!

"The path is more important than the goal", says the Wise

I think the format doesn't really matter that much, because ultimately, if you save the OpenInventor display mesh to some format, you'll have to convert it back to OpenInventor to display in FreeCAD. So why not save in OpenInventor format directly and it's done (apart from possible performance differences of course). But what's interesting is that there isa kind of "convergence" here, many apps and framework are choosing that path (saving the display mesh to a file).

Now imagine this: We could save the mesh representation (whatever the format) INSIDE the .FCStd file. It would just be a matter of opening the zip and adding a file. Of course probably that mesh file would vanish when resaving the file, but we can solve that. Wouldn't that be cooler than a separate CGR (or whatever) file?

[saso]

I think it is important to be clear in such discussion about supporting file formats (yes, if it is technically and legally possible to do it we can support the import/export/linking (xref) of any file format, open or not) and our default implementation (I guess we can agree we don't want something that is not open here). It is not just about JT, also the CGR was brought in to the discussion as an comparison to the OpenInventor representation that we are already using and the possibilities to extend and reuse it in a way catia is doing with CGR and not that we would go and switch over to CGR.

[lalberts]

Hello,
I basically have NO understanding of most what has been said here.
We run DDS-CAD here in the office. This in Norway (Linus homeland) developped planing software is citing a bunch of applications it is based on.
They have their projects saved in something like a GIT project.. (is it Xerces?)

Lukas

Drittlizenzen
Die von DDS-CAD verwendeten Drittlizenzen:
Boost
Staircon
Polysun
Lightworks Author
SuperPro dongle (hwl)
ODA
ActiveX Data Objects (ado)
sgCore
FTGL
FreeType
Open Cascade
Xerces
Zlib
OPCODE
SQLite
iCU (UniCode)
COPYRIGHT AND PERMISSION NOTICE

Copyright (c) 1995-2009 International Business Machines Corporation and others. All rights reserved.

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, provided that the above copyright notice(s) and this permission notice appear in all copies of the Software and that both the above copyright notice(s) and this permission notice appear in supporting documentation.

http://userguide.icu-project.org

[lalberts]

DDS-CAD 13 has now also a 3rd license for

fable

? no idea what it is
Lukas

[triplus]

As this thread was bumped. Soonish there will be Assembly 3 available for testing:

https://forum.freecadweb.org/viewtopic. ... 10#p200038

And i am guessing there should already be some "Xref" related work done as a part of it.

[cadgiru]

Thanks for all the feedback guys, I begin to get ideas:

- Although some (autodesk mainly) applications allow you to embed any file into any other, without the need to do anything special in the file that you plan to embed, others (solidworks, or the assembly/body system) require you to do something: put your stuff under one structure (body), or save under a special name. This all means you have to "prepare" your file somehow to be importable. This is actually not so terrible as it sounds (to me ), it's actually very little work. I think it would be totally tolerable.

- Seeing my list above, why not have all the options? Imagine a "xref" object, which has a file path property, a timestamp (to autoreload the file if it has changed), and an enum property that can be "compound", "one shape" or "representation". Compound would make the object a compound, and list all the individual objects of the embedded file under it. One shape would show one, big, one-color shape which is internally a compound of all the shapes of the embedded file, but doesn't let you access the individual shapes. The advantage would be that the import would not require any GUI operation (we would be just reading the individual brep files from the fcstd file) and therefore would be much faster. And finally, "representation" would read only an OpenInventor node from the fcstd file.

- So for that last mode to work, one would need to "prepare" the file to be embedded, by adding all the objects one wants to embed to a certain object (a kind of lightweight "body") which will store their openinventor representation in the file. If such preparation is not made, this last mode will not be available.

- We still have to test that, but the selection system is embedded into the coin representation. So it's possible that on importing the coin node, selection still works as if these objects were really existing in the document. But there is the problem of possible double names... Somthing to check on later.

- Of course there is still the problem that in the first (compound) mode, one could create links to the imported objects, and when updating the file, these objects could be gone. But we can minimize the problem by warning the user on file update if some link will become broken...

How does that sound?

Of all the CAD systems I have used (many) , I find that MicroStation by Bentley systems has the most intuitive and flexible system for attaching reference files.
If this is still a topic, I will be more than happy to document its features.

First here is a link https://flh.fhwa.dot.gov/resources/cadd ... es_v8i.pdf

This system is really flexible... Some of the major features:

• Ability to attach Absolute or relative path to file

• Turn on and off display of file

• Turn on and off ability to snap to Ref

Have been working my way through Yorik's Arch tutorial. During this I have found great help in splitting files by copy Group(s) between files.
As long as they all share a common origin this seems to work great. (For Arch Projects this is a must, and defined very early in the design process. Partial IFC files seem to be the trend at the moment. Mainly split by discipline.

Regards

[Opus]

MicroStation by Bentley systems has the most intuitive and flexible system for attaching reference files.

+1

[joancabeza]

I don't know in what stage is that issue now but I've been thinking about it latelly. I think the idea of being able to create a master where you were linking all the other parts would be efficient. A file where you link the architecture part, the structural part, MEP part, site part... Even though in this file you couldn't edit the linked files (that is what most of the time happens when yu work with xref) If you want to edit you go to the original file.

The idea of double-clicking ghost objects is fantastic but I would prioritize lightweiht. One thing it could be is that somehow you could have the linked files active / inactive.

Also because I don't know if this could help with the problem that is working with techdraw in a architectural model. Nowadays the worst problem is that even in small projects once you create a page everything goes slow. That implies that you make the plans on the last stages of your work (not desirable). For example, I've recently make a proposal and once I wanted to make the plans I desisted and exported the dxf files and made them with Draftsight. And it's a pitty because it has been made great job with techdraw and it offers most of the things needed. It has some limitations in order to control linewith and others but even at this stage it's pretty cool now.

So I imagine a master file with the linked files where you make the plans of your project.

[yorik]

I'm currently experimenting with simple xrefs, should have something in not long. It won't have all the fancy stuff just yet, though.
About techdraw, indeed it is too slow for most arch/BIM work at the moment. It is also on my radar to have a closer look at it and then talk Wandererfan into it to see what can be done.

[realthunder]

I have implemented external links, and partial document loading, meaning that only the referenced content is loaded. I'd say my implementation is near complete by now, feature wise speaking, but still need a bit more test. The externally linked objects works just like native objects, you can directly edit them in-place.

Partial document loading is documented here, with a screencast (which I copied below) showing the potential improvement on FC's scalability. I will soon release a new version of my fork of FC for anyone interested to test.