Merging of my Link branch

[triplus]

When i experience some topo naming related issue or a related discussion was ongoing on the forum. I usually tested that and compare to stock FreeCAD behavior. True i could share results more often. But focusing on two such big efforts like Link and TopoNaming at once. That just isn't feasible. Especially as the developers feedback beyond @realthunder was sparse. Around this time last year Link effort was in position like the TopoNaming effort is ATM. TopoNaming effort just isn't there yet it needs to mature more.

Links effort on the other hand (especially now when partial loading got tackled too) matured one more year (from when it was claimed to be in a upstreamable state). Projects like Assembly 3 demonstrating its usefulness ... Lots of areas emerging where developers are in immediate need to start using such feature. In short the time is right now to start tackling the upstreaming part strategy. And i feel if there is the will we aren't talking about 50k LOC for making FreeCAD 0.18 Link ready. But first we need a Link related PR to start focusing on how to make it happen.

[Mark Szlazak]

When i experience some topo naming related issue or a related discussion was ongoing on the forum. I usually tested that and compare to stock FreeCAD behavior. True i could share results more often. But focusing on two such big efforts like Link and TopoNaming at once. That just isn't feasible. Especially as the developers feedback beyond @realthunder was sparse. Around this time last year Link effort was in position like the TopoNaming effort is ATM. TopoNaming effort just isn't there yet it needs to mature more.

Links effort on the other hand (especially now when partial loading got tackled too) matured one more year (from when it was claimed to be in a upstreamable state). Projects like Assembly 3 demonstrating its usefulness ... Lots of areas emerging where developers are in immediate need to start using such feature. In short the time is right now to start tackling the upstreaming part strategy. And i feel if there is the will we aren't talking about 50k LOC for making FreeCAD 0.18 Link ready. But first we need a Link related PR to start focusing on how to make it happen.

Just as a clarification, what exactly about toponaming needs to mature? The theory looks state of the art, is it implementation?

Thank you.

[realthunder]

When i experience some topo naming related issue or a related discussion was ongoing on the forum. I usually tested that and compare to stock FreeCAD behavior. True i could share results more often. But focusing on two such big efforts like Link and TopoNaming at once. That just isn't feasible. Especially as the developers feedback beyond @realthunder was sparse. Around this time last year Link effort was in position like the TopoNaming effort is ATM. TopoNaming effort just isn't there yet it needs to mature more.

The reason it seems that Topo Naming keeps showing problem is because everyone is using it, so it is the easiest to test, and can be thoroughly tested real quick. I've also put up more detailed document (comparing to Link) for the code. If wmayer wants to review the code, he'll find it easier to read than Link, which is scattered all over the place. And, I'm sure I can hunt down bugs fast, too. I have already made a few adjustment to make it more legacy file friendly.

On the other hand, I am the only programmer of using Link right now. It works well because, well, the author himself is writing the demo and test. Link is in the core, so it does not directly use topo naming. It does have some code to make topo naming work for external link. Other features, like step import, partial document loading, and Assembly3 itself do use topo naming, mostly for getting colors from multiply layers of shape compounding. Implementing that without topo naming is certainly possible, but not a easy task.

All in all, we still need to hear what wmayer thinks about it.

[fosselius]

I could start building my RoboticCreator workbench on your branch in order to test more features that might not be as exposed for normal users.
But it feels a bit "wrong" to build 3d party addons/workbenches based on a branch that is under rapid development, it would in essence be an fork of the assembly3 workbench. On the other hand, your branch provides a lot of changes i really want to take advantage of...

Things i would need to start with:
Locating places in assemblies with degrees of freedom to "detect" joints, i could also have the user manually placing joints as i did in the old workbench. @realthunder You have "finding total degrees of freedom" on your TODO list for asm3 right?
Iterate through all kind of objects/links to find solids/shape/inertia
Export "meshes of fuses of several types of objects (export mechanical link/subassembly as stl or obj that can be included in SDF or URDF)
SDF:
http://gazebosim.org/tutorials?tut=build_model
URDF:
http://wiki.ros.org/urdf/Tutorials/Buil ... %20Scratch

secondary goals:
Add bullet physics support based on the work of JMG (bullet can import SDF and URDF files)
https://github.com/JMG1/FreeCAD_BulletPhysics
Add some way of coding/controlling robot models in the physics simulation inside FreeCAD.

[realthunder]

@realthunder You have "finding total degrees of freedom" on your TODO list for asm3 right?

Yes, sure. Finding DOF is not that useful, we need to find out which parameters are free. I'll do it after releasing 0.8. Need to modify libslvs to expose this functionality.

[fosselius]

Please rebase your branch again! you got wmayers 'bad' commit, he have already resolved that in 5e63d3ded96c2a02544bc770681b42b9addb45dc
see: https://forum.freecadweb.org/viewtopic.php?f=4&t=30159

so now i can build mainline but not linkstage3

[realthunder]

Please rebase your branch again! you got wmayers 'bad' commit, he have already resolved that in 5e63d3ded96c2a02544bc770681b42b9addb45dc
see: https://forum.freecadweb.org/viewtopic.php?f=4&t=30159

so now i can build mainline but not linkstage3

Done! I just add that 'bad commit' like minutes ago, because of build failure on mac, and was just now in the middle of release build for linux.

[triplus]

Just as a clarification, what exactly about toponaming needs to mature? The theory looks state of the art, is it implementation?

Thank you.

Much effort was invested in the past when it comes to the theory and selecting the approach FreeCAD will use. Luckily @realthunder in the end took from that point on. When it comes to the implementation. But it is just too soon to say this is upstream material. Such things need to mature in downstream branches for in average two development cycles. That is when the development is active on such scale as @realthunder demonstrated. On a Sketcher side of things i for example like the approach where algorithms compare changes against existing geometry and decide what to do next. All that is good and it is not about being against all this being upstreamed. It's just the upstreaming process needs to be a bit conservative when it comes to FreeCAD core. Core changes affect the past and the future. More end user and developer involvement will be needed too. For things to mature further. Therefore i somehow see this as FreeCAD 0.19 development cycle material.

And in the end TopoNaming effort has little to do with Link effort. Making FreeCAD 0.18 Link ready would still be a huge achievement.

@realthunder

If you want my honest opinion. Extract the Link effort out of the Link branch and create a PR. It likely won't take you more than a week? And lets do that first and see how it goes. Less LOC, one full scope to review. Easier to tackle after getting merged and end users and developers starts using it and providing feedback. As once that starts to happen there is no going back. On how things will be made available in FreeCAD 0.18 development cycle that is likely how in general in this area will stay for years to come. Partial loading effort to me sounds like an essential Link effort functionality. Therefore i don't know if this should be tackled separately. Likely not. Partial loading will be the default behavior when creating external Links?

If succeeded FreeCAD 0.18 will end up providing Link functionality to developers and end users. Wouldn't that be something? The rest can wait and mature a bit longer. And it is not like if we add TopoNaming effort in its current state in the FreeCAD 0.18 development cycle. For TopoNaming issues to go away for FreeCAD 0.18 end users.

[realthunder]

If you want my honest opinion. Extract the Link effort out of the Link branch and create a PR. It likely won't take you more than a week? And lets do that first and see how it goes. Less LOC, one full scope to review. Easier to tackle after getting merged and end users and developers starts using it and providing feedback. As once that starts to happen there is no going back. On how things will be made available in FreeCAD 0.18 development cycle that is likely how in general in this area will stay for years to come.

As much as I hate to do the repeating work, if wmayer finds it is necessary to split it out, I'll do it.

Partial loading effort to me sounds like an essential Link effort functionality. Therefore i don't know if this should be tackled separately. Likely not. Partial loading will be the default behavior when creating external Links?

It is enabled by default, for any object. But with the default behavior, it still has to load all the depending object, which is not useful, say, if you put one model per file, all objects of that file is likely to be a long dependency chain. To break that chain, the object needs special implementation, which I outlined in the document, and has Assembly container as a demonstration.

[realthunder]

New release is out. Please give it a try.

It is easiest to test the Topo naming stuff. Just open whatever model you have, load it, and recompute, see if there is anything broken. As a comparison, please also try in the upstream, mark the document for recompute, and recompute it. The problem you have maybe because of the upgrade of occt. Not recompute everything may actually hide a lot of problems.

On the other hand, maybe the model is consider good enough and fixed. You can turn off auto element mapping using parameter BaseApp/Preferences/Mod/Part/General/AutoElementMap, set to False, and restart FC.