See also the different release notes at the bottom of https://github.com/realthunder/FreeCAD_assembly3/wikidulouie wrote: ↑Sat Mar 16, 2019 4:05 pm LinkStage3 documentation is here:
https://github.com/realthunder/FreeCAD_ ... /wiki/Link
https://github.com/realthunder/FreeCAD_ ... re-Changes
Assembly3 preview
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Re: Assembly3 preview
Re: Assembly3 preview
No but the last time they don't respond much because of lack of time. I guess @yorik and @wmayer need 48 hour in a day if they have to respond on everything.
Btw In the beginning of @realthunder link work he show he is good at throwing mud to other developers too(together with ickby).
I'm happy they are now more in the same direction.
Btw2 i explecidly didn't want to point to anybody. No need for that!
-
- Veteran
- Posts: 2190
- Joined: Tue Jan 03, 2017 10:55 am
Re: Assembly3 preview
I will hopefully be free to work on FC in about a week's time. I'll first bring my branch up to date with upstream. I originally planned a few features for the next release, but since we are talking about 0.19 development now, I think it is better for me to release a merged version for testing first.
After that I will spent some time to try to split the Link code. There are several parts of Link code (mostly in Part Mod) that is inter-related to my topo naming interface. Like I suggested last time, I strongly suggested to merge the Link and my Topo Naming together, as without the latter the user is going to face the usual FC problems like jumping geometry reference, loss of coloring, etc, only that the problems will be worse because of wider linkage possibility. Besides, the Link functionality is scattered in quite a few places (coin rendering, selection, treeview, etc.), while the topo naming adds a set of new APIs in the existing TopoShape and implemented in only one file, and with better documentation. The rest of code changes are just to use those APIs instead of raw OCC API.
After that I will spent some time to try to split the Link code. There are several parts of Link code (mostly in Part Mod) that is inter-related to my topo naming interface. Like I suggested last time, I strongly suggested to merge the Link and my Topo Naming together, as without the latter the user is going to face the usual FC problems like jumping geometry reference, loss of coloring, etc, only that the problems will be worse because of wider linkage possibility. Besides, the Link functionality is scattered in quite a few places (coin rendering, selection, treeview, etc.), while the topo naming adds a set of new APIs in the existing TopoShape and implemented in only one file, and with better documentation. The rest of code changes are just to use those APIs instead of raw OCC API.
Yes, it will be a problem. The Link rendering part needs to be reworked, and this is a very tricky part. But I am sure whatever I moved into will have similar functionality.
- roerich_64
- Veteran
- Posts: 1465
- Joined: Thu May 21, 2015 7:00 pm
- Location: Ostfriesland
Re: Assembly3 preview
Sounds goodrealthunder wrote: ↑Sat Mar 16, 2019 11:49 pm I will hopefully be free to work on FC in about a week's time. I'll first bring my branch up to date with upstream. I originally planned a few features for the next release, but since we are talking about 0.19 development now, I think it is better for me to release a merged version for testing first.
couldt you make your asm3 as a workbench?
In my eyes then it comes more tollerance
BR
Walter
Die Liebe wird siegen, denn sie ist unzerstörbar
Re: Assembly3 preview
Thanks for the confirmation. If we will for whatever reason move away from Coin3D in the future, that will likely end up being hard task to achieve anyway. Not just Link related.realthunder wrote: ↑Sat Mar 16, 2019 11:49 pm Yes, it will be a problem. The Link rendering part needs to be reworked, and this is a very tricky part. But I am sure whatever I moved into will have similar functionality.
Great news. Looking forward for the PR.After that I will spent some time to try to split the Link code.
Splitting the Link related work in a separate branch and syncing that with upstream. Maybe for now that would save you some hassle, compared to first trying to sync the whole code base of Assembly 3 against FreeCAD upstream, and for that to diverge again rather quickly.
P.S. As for the TopoNaming. I know you would like to combine all this in one scope. I feel that such approach could introduce more confusion and issues regarding QA and would prolong the review process. Technically Link doesn't need TopoNaming solution? That is, if people start using Link functionality, for things like adding standard parts from external library to an assembly. That should already be rather robust, without the TopoNaming solution? For purposes, when the topology is expected to change, like LinkDeep, and other use cases in FreeCAD. For that TopoNamning solution starts to make more sense. And when it comes to the TopoNaming effort, i feel that things should still mature a bit more. If developers like @ickby would get involved and after more discussions and understanding would happen ... There is still a chance it could get tackled in the current development cycle. But lets do the Link first, and worry about the rest latter?
Re: Assembly3 preview
Looks like @realthunder continues to hack away at Assembly3 per https://github.com/realthunder/FreeCAD_ ... its/master
That's encouraging
That's encouraging
Alone you go faster. Together we go farther
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Re: Assembly3 preview
yes but i think the Link work is more interesting to follow:
https://github.com/realthunder/FreeCAD
compared to mainline: *note* commits and changes does not directly reflect progress/improvements. its not an good benchmark, but still ^_^
-
- Veteran
- Posts: 2190
- Joined: Tue Jan 03, 2017 10:55 am
Re: Assembly3 preview
Well, it is a bit misleading indeed. There is one big commit in particular, which is due to regenerating the expression syntax parser. That's really a small change in the source file, but resulting a huge change in C++ generated code.
Re: Assembly3 preview
@realthunder
Read this more as a thinking out loud type of question. App::Link is therefore a lightweight representation of the linked feature. Being capable of extracting some properties from the linked feature document object. A discussion has been started here:
https://forum.freecadweb.org/viewtopic. ... 30#p301293
Do you feel it would be possible to create a group of App::Link features acting as a single document object? Or does each App::Link feature need its own document object? If creating souch group would be possible, could such group be able to suppress/promote any individually linked feature document object? That is when working in the same document, and could that yield in more performance, due to lower number of document objects.
Read this more as a thinking out loud type of question. App::Link is therefore a lightweight representation of the linked feature. Being capable of extracting some properties from the linked feature document object. A discussion has been started here:
https://forum.freecadweb.org/viewtopic. ... 30#p301293
Do you feel it would be possible to create a group of App::Link features acting as a single document object? Or does each App::Link feature need its own document object? If creating souch group would be possible, could such group be able to suppress/promote any individually linked feature document object? That is when working in the same document, and could that yield in more performance, due to lower number of document objects.
-
- Posts: 439
- Joined: Tue Apr 04, 2017 6:06 pm
- Location: SF Bay Area, California
Re: Assembly3 preview
Hi realthunder. I brought this up before and it has always been in the back of my mind ever since. Some class teaching assistants claim that CAD products like NX, CATIA and CREO can handle very large assemblies of say 100,000 parts while Solidworks (maybe not Solidworks 2019) and others cannot. Usually unsatisfying answers are given as to why this is so. Do you know why? I am asking because it could be important to how FreeCAD’s assembly gets developed.
Second thing that one may wonder is why would an assembly of 100,000 parts be made in the first place. A response I got was that a center of gravity maybe needed. After all, it was Boeing that one time boosted it got a jet designed so fast because it used CATIA.