Ideas needed: Xref

A forum dedicated to the Draft, Arch and BIM workbenches development.
realthunder
Posts: 1396
Joined: Tue Jan 03, 2017 10:55 am

Re: Ideas needed: Xref

Postby realthunder » Sat Mar 25, 2017 3:26 pm

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.
Try Assembly3 (latest version 0.10.2) along with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
triplus
Posts: 9278
Joined: Mon Dec 12, 2011 4:45 pm

Re: Ideas needed: Xref

Postby triplus » Sat Mar 25, 2017 9:26 pm

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.
It makes no real difference if you add parent/child relationship on Assembly or on Part(Design) level.
Jee-Bee
Posts: 1992
Joined: Tue Jun 16, 2015 10:32 am
Location: Netherlands

Re: Ideas needed: Xref

Postby Jee-Bee » Sun Mar 26, 2017 5:44 am

triplus wrote:It makes no real difference if you add parent/child relationship on Assembly or on Part(Design) level.
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.
User avatar
nemesis
Posts: 350
Joined: Tue Mar 25, 2014 11:24 pm
Location: France, Lyon

Re: Ideas needed: Xref

Postby nemesis » Sun Mar 26, 2017 7:30 am

yorik wrote:How they do it in digital project. Pretty similar to what we are discussing here...
Hi,
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.
realthunder 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.
and so that's exactly the proposal of Realthunder
I vote for it! :D
User avatar
yorik
Site Admin
Posts: 11686
Joined: Tue Feb 17, 2009 9:16 pm
Location: São Paulo, Brazil
Contact:

Re: Ideas needed: Xref

Postby yorik » Sun Mar 26, 2017 5:00 pm

nemesis wrote:Caria behave exactly this way with generating CGR files first when you open an assembly.
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 imported
User avatar
Pauvres_honteux
Posts: 262
Joined: Sun Feb 16, 2014 12:05 am
Location: Far side of the moon

Re: Ideas needed: Xref

Postby Pauvres_honteux » Mon Mar 27, 2017 4:59 am

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?
User avatar
nemesis
Posts: 350
Joined: Tue Mar 25, 2014 11:24 pm
Location: France, Lyon

Re: Ideas needed: Xref

Postby nemesis » Mon Mar 27, 2017 6:45 am

Pauvres_honteux wrote:I'm pretty confident Jürgen started something with that format back in the days.
Well, it looks like he was not very interested in integrating it. it's a propriatary format.

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
User avatar
Pauvres_honteux
Posts: 262
Joined: Sun Feb 16, 2014 12:05 am
Location: Far side of the moon

Re: Ideas needed: Xref

Postby Pauvres_honteux » Tue Mar 28, 2017 6:01 am

nemesis wrote: ... he was not very interested in integrating it.
Uhmm, that could be debateable...
https://github.com/jriegel/FreeCAD/tree ... /Jt/Engine
jidoeuf
Posts: 43
Joined: Sun Mar 01, 2015 4:06 pm

Re: Ideas needed: Xref

Postby jidoeuf » Tue Mar 28, 2017 6:33 am

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
User avatar
nemesis
Posts: 350
Joined: Tue Mar 25, 2014 11:24 pm
Location: France, Lyon

Re: Ideas needed: Xref

Postby nemesis » Tue Mar 28, 2017 7:02 am

Pauvres_honteux wrote: Uhmm, that could be debateable...
not sure ... that's the standard example available with all teamcenter version ;-)
engine.PNG
engine.PNG (67.56 KiB) Viewed 1261 times
jidoeuf wrote:"OPEN CASCADE JT Assistant is intended to be a basis for development of custom applications dealing with JT data format"
the question is "Is there an opensource lib available to read/writ jt file without licence issue, and
JT file versions 8.0 - 9.5 are currently supported. Mesh data and assembly structure are visualized. Monolithic and non-monolithic assemblies are supported.
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....