Code review of merged Link3 branch

[wmayer]

Now, the reason why plain group does not appear to support subname path is because it's view provider does not stack the children under its root node.

Ah, now I understand. Thanks for the explanation.

[realthunder]

It can't say what the original idea was to have the tree widget there because the git history doesn't go far enough. But I think the dialog once was modal and to avoid to disturb the workflow too much the tree was there for convenience. But because the dialog is non-modal (now) the tree can be considered obsolete -- especially if it's problematic with the Link philosophy.

I submitted a PR to add support of Link or object's inside Linked group in Tessellation task.

I discovered a strange problem. Not really related to the PR, it is repeatable even in 0.18. When VBO is enabled, trying to tellelate a colored object will cause strange edge color problem with other objects. It's hard to describe, so I captured a screencast. It looks like a material leaking in coin. But I can't find out where or why. Notice that hiding the colored mesh makes problem disappear. When the mesh is visible, newly created object will be infected with this problem. Disabling VBO does not fix it. Restart FC with VBO disabled seems to avoid the problem.

[wmayer]

When VBO is enabled, trying to tellelate a colored object will cause strange edge color problem with other objects. It's hard to describe, so I captured a screencast. It looks like a material leaking in coin.

OpenGL is a state machine and when setting a status somewhere in a function without resetting it afterwards this may affect further rendering.

This kind of rendering artefacts often are caused by using a SoGroup node when a SoSeparator should be used. FYI, a SoGroup does nothing special in terms of rendering, it just forwards all the events to its children while a SoSeparator additionally pushes and pops the state.

But in this case it could also be when VBO is active that somewhere in the nodes using it a state is only set but not reset. I guess finding and fixing this issue will require a lot of trial & error.

[realthunder]

But in this case it could also be when VBO is active that somewhere in the nodes using it a state is only set but not reset. I guess finding and fixing this issue will require a lot of trial & error.

I have fixed the problem here along with some follow up patches.

[Zolko]

Hello realthunder and wmayer, and all the others who contributed,

thank-you very much for your effort to include this fantastic App::Link feature into FreeCAD, I believe this will set a milestone for FreeCAD development. Having used V0.19-pre with Assembly4 for some time, I think this feature (App::Link) is now very stable.

So time has come to add (or ask-for) some features that, I think, will make this tool even more appealing: the ability to link to an object and passing a variable to that object in the process.

I explain: what I'd like to have is that App::Link should "call" an object like a library, passing variables during the call. Thus, one could link a profile and specify the length of the profile: a single file would have defined the section and an extrusion with a default length, but the part could be linked ("called") with the parameter "length" set that would override the default length. Or a CHC screw could be called by setting the diameter and the length. Or a subassembly could be called with different configurations. The possibilities would be infinite. The best high-end CAD systems have this interface. Not all parameters should be "callable", only those that the part has declared as such (like in a software library).

This variable call would be a new interface inside FreeCAD and specific to App::Link, so now would be the best time to think about such feature, before the feature freeze in preparation of the v0.19 release. I don't know whether all FreeCAD objects should have this callable interface, or only some of them, but if only 1 type would be eligible then please make it the App::Part. In this case App::Part and App::Link would form the logical building-blocks for assemblies in FreeCAD. Once the variable is in a part, a spreadsheet should be able to distribute the parameters to all objects inside the App::Part container.

I have looked at the source code but I'm unable to tell where the magic should be. I have tried to play with spreadsheets to achieve this functionality but I failed: either I could modify the part and then all instances of that part, or nothing. Long story short: I was unable to have twice the same part with different length using spreadsheets. That's why I believe a new interface is needed.

[vocx]

... so now would be the best time to think about such feature, before the feature freeze in preparation of the v0.19 release...

You cannot expect a completely new feature like what you want to be included in 0.19. That's a very short time to develop and test. Take App::Link itself. It was finally merged into FreeCAD after two years, and realthunder still has more code that he would like to merge (the solution to the topological naming problem). That code may be submitted for testing, but it's possible it won't be merged after another round of testing, so maybe until 0.20.

Maybe you should create a new thread with this idea of yours. There are no deadlines. As soon as you develop a prototype, the faster it can be tested and included into FreeCAD.

I say that what you want is similar to object oriented programming. You want each instance (App::Link) of a class (original Linked object) to have its own properties (lengths, widths, etc.). I think it can be done, but how? That's the tricky part. Maybe we should wait until the current App::Link is tested and stable enough before adding more things.

I remember reading in this forum some discussions, maybe in the Assembly3 thread, and one person said something like "not every object oriented programming concept can be applied to 3D solid modelling". That means that it may be a good idea from a programming point of view, but it does not necessarily mean it's a good idea from the point of view of CAD.

[realthunder]

The best high-end CAD systems have this interface. Not all parameters should be "callable", only those that the part has declared as such (like in a software library).

Can you provide an example, or give some links to showcase this capability in other CAD? I am curious to how they provide this function to the user.

I was unable to have twice the same part with different length using spreadsheets. That's why I believe a new interface is needed.

IMO, what you are asking defeats the purpose of Link, because you want new geometry, while Link shares them. You can achieve similar effect by simply copying the objects. You can make your design fully configurable using a spreadsheet, but access the spreadsheet through a Link (that is, instead of Spreadsheet.A1, use Link.A1). You can put the spreadsheet in a separate file, or not. It doesn't really matter. The point is that you can easily change the Link to point to a new 'profile'. To generate new assembly with a different 'profile', simply copy the assembly objects and change the link to a different spreadsheet. You can of course create a macro or something to automate this process with the click of a button.

If you want more fancy configurations like inheritance or override, use a stack of spreadsheets, and remember to access parent/child sheet using Link as well.

[ezzieyguywuf]

I discovered a strange problem.

What if you change the height of the cylinder, so that its top surface is no longer co-planar to the two cubes?

Also, what is a VBO?

[chrisb]

Also, what is a VBO?

It's in Preferences->Display->3DView (Vertex Buffer Object).

[Zolko]

The best high-end CAD systems have this interface. Not all parameters should be "callable", only those that the part has declared as such (like in a software library).

Can you provide an example, or give some links to showcase this capability in other CAD? I am curious to how they provide this function to the user.

In SolidWorks they're called "configurations":

https://www.cati.com/blog/2018/01/solid ... gurations/
https://grabcad.com/tutorials/using-sol ... mbly-level

In T-Flex they're called "variables":

https://www.youtube.com/watch?v=WndPlY8aQoY

You can achieve similar effect by simply copying the objects. You can make your design fully configurable using a spreadsheet, but access the spreadsheet through a Link (that is, instead of Spreadsheet.A1, use Link.A1). You can put the spreadsheet in a separate file, or not. It doesn't really matter. The point is that you can easily change the Link to point to a new 'profile'. To generate new assembly with a different 'profile', simply copy the assembly objects and change the link to a different spreadsheet. You can of course create a macro or something to automate this process with the click of a button.

If you want more fancy configurations like inheritance or override, use a stack of spreadsheets, and remember to access parent/child sheet using Link as well.

This sounds like quite exactly what I would like to achieve. Just to be sure: I would like that a "Part" (assembly or single solid) be opened several times in the same assembly/document with different set of parameters. Is it possible with your scheme ?

This would be the workflow:

• create a file called "Beam"
• make a sketch
• make an extrusion
• let's suppose that the parameter name of the length of the extrusion is called "Length"
• create an assembly
• insert part Beam, call the link "Beam_1"
• set Length of Beam_1 to 100
• insert part Beam, call the link "Beam_2"
• set the Length of Beam_2 to 150

I have managed to do that, but when I set the Length of Beam_2 to 150, it also set the Length of Beam_1 to 150 !

IMO, what you are asking defeats the purpose of Link, because you want new geometry, while Link shares them

Would that mean that it's not possible currently to do what I would like to do ?