Ideas needed: Xref
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
-
- Veteran
- Posts: 2190
- Joined: Tue Jan 03, 2017 10:55 am
Re: Ideas needed: Xref
I used assembly2 alot. I think the biggest problem of assembly2 is a conceptual error. Instead of selecting all those connecting faces, edges in the assembly file, and trying to solve the unsolvable problem of updating those faces and edges after part model changes, one should in fact defining those faces and edges in the part file. The part author knows what faces or edges are supposed to connect to others. And the part author knows when and how to update those geometries manually, when he updates the model. Yes, manually. There is no way to solve this problem automatically. The part file may contain more than one parts of course, and the part author can use special container to mark which geometry can be imported as part, and inside those parts, which faces/edges are connectable. The faces or edges can even be separate copies of the actual geometry (optionally invisible), instead of just text sub element name reference to the model.
Re: Ideas needed: Xref
It makes no real difference if you add parent/child relationship on Assembly or on Part(Design) level.realthunder wrote:I used assembly2 alot. I think the biggest problem of assembly2 is a conceptual error. Instead of selecting all those connecting faces, edges in the assembly file, and trying to solve the unsolvable problem of updating those faces and edges after part model changes, one should in fact defining those faces and edges in the part file. The part author knows what faces or edges are supposed to connect to others. And the part author knows when and how to update those geometries manually, when he updates the model. Yes, manually. There is no way to solve this problem automatically. The part file may contain more than one parts of course, and the part author can use special container to mark which geometry can be imported as part, and inside those parts, which faces/edges are connectable. The faces or edges can even be separate copies of the actual geometry (optionally invisible), instead of just text sub element name reference to the model.
Re: Ideas needed: Xref
I think @realthunder workaround makes a difference for some type of parts. Specially bolds nuts rings etc etc that are parts placed always on the same method.triplus wrote:It makes no real difference if you add parent/child relationship on Assembly or on Part(Design) level.
Re: Ideas needed: Xref
Hi,yorik wrote:How they do it in digital project. Pretty similar to what we are discussing here...
I didn't know about Digital project but looking the video it was pretty familiar, and saw it was based on CatiaV5 so that's why.
Caria behave exactly this way with generating CGR files first when you open an assembly. it doesn't looks like they are stored inside the file.
The "publication" seen in the video are element (all kind of element) choose by the designer to be exposed to other in an assembly. so you can use them without loading the full file.
and so that's exactly the proposal of Realthunderrealthunder wrote:Yes, manually. There is no way to solve this problem automatically. The part file may contain more than one parts of course, and the part author can use special container to mark which geometry can be imported as part, and inside those parts, which faces/edges are connectable.
I vote for it!
Re: Ideas needed: Xref
One more way to do it. Interesting... With that system one can actually use any other file as reference, no need to "mark" the geometry to be importednemesis wrote:Caria behave exactly this way with generating CGR files first when you open an assembly.
- Pauvres_honteux
- Posts: 728
- Joined: Sun Feb 16, 2014 12:05 am
- Location: Far side of the moon
Re: Ideas needed: Xref
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!
Anyway, the even lighter format than CGR I talked about is JT (Jupiter Tesselation): https://en.m.wikipedia.org/wiki/JT_(vis ... on_format)
With this format it's possible to load a complete car and slowly rotate it on a secretarys computer (they usually have the lowest of the low spec's). For comparison a complete car in full format is at the very least in the tens of gigabytes.
I'm pretty confident Jürgen started something with that format back in the days.
Now, what no one has utilized yet is the possibility to exploit storage in the files header. With a smart framework around it one might be able to get the lightest of the light formats there are on this planet.
The principle is simple: store the very minimum you later can use to calculate the simplest possible geometric form a human can possibly understand to show on the screen. When the user wants more details she/he loads the JT-file(part or assembly), got an urge for even more details? Load the full format! And behold the might of gigabytes chewing up all your prescious RAM.
Don't forget this is done / shall be done per file, i.e. part or assembly. It is NOT about all or nothing.
By the way, we are talking about assemly as in a file which can only contain other files, right?
Anyway, the even lighter format than CGR I talked about is JT (Jupiter Tesselation): https://en.m.wikipedia.org/wiki/JT_(vis ... on_format)
With this format it's possible to load a complete car and slowly rotate it on a secretarys computer (they usually have the lowest of the low spec's). For comparison a complete car in full format is at the very least in the tens of gigabytes.
I'm pretty confident Jürgen started something with that format back in the days.
Now, what no one has utilized yet is the possibility to exploit storage in the files header. With a smart framework around it one might be able to get the lightest of the light formats there are on this planet.
The principle is simple: store the very minimum you later can use to calculate the simplest possible geometric form a human can possibly understand to show on the screen. When the user wants more details she/he loads the JT-file(part or assembly), got an urge for even more details? Load the full format! And behold the might of gigabytes chewing up all your prescious RAM.
Don't forget this is done / shall be done per file, i.e. part or assembly. It is NOT about all or nothing.
By the way, we are talking about assemly as in a file which can only contain other files, right?
Re: Ideas needed: Xref
Well, it looks like he was not very interested in integrating it. it's a propriatary format.Pauvres_honteux wrote:I'm pretty confident Jürgen started something with that format back in the days.
edit : But in that's also a ISO standard since 2012
edit2 : Maybe X3D is good alternative as it is LPGL or VRML as it is already supported
- Pauvres_honteux
- Posts: 728
- Joined: Sun Feb 16, 2014 12:05 am
- Location: Far side of the moon
Re: Ideas needed: Xref
Uhmm, that could be debateable...nemesis wrote: ... he was not very interested in integrating it.
https://github.com/jriegel/FreeCAD/tree ... /Jt/Engine
Re: Ideas needed: Xref
FYI:
"OPEN CASCADE JT Assistant is intended to be a basis for development of custom applications dealing with JT data format"
https://www.opencascade.com/content/jt-assistant
"OPEN CASCADE JT Assistant is intended to be a basis for development of custom applications dealing with JT data format"
https://www.opencascade.com/content/jt-assistant
Re: Ideas needed: Xref
not sure ... that's the standard example available with all teamcenter versionPauvres_honteux wrote: Uhmm, that could be debateable...
the question is "Is there an opensource lib available to read/writ jt file without licence issue, andjidoeuf wrote:"OPEN CASCADE JT Assistant is intended to be a basis for development of custom applications dealing with JT data format"
JT are now at version 10.2 in teamcenter 11.2 so, jt assistant is already outdated. that's the issue with a non opensource format I guess. But Developers would have a better point of view than me I guess....JT file versions 8.0 - 9.5 are currently supported. Mesh data and assembly structure are visualized. Monolithic and non-monolithic assemblies are supported.