Realthunder Link implementation: Architecture discussion

[triplus]

In my opinion your current proposal (when it comes to topological naming) doesn't solve much if anything. It just adds another "layer of geometry" (this is what you call abstraction) on top of the existing geometry. And that new "layer of geometry" has exactly the same problems when it comes to changing topology compared to using the existing geometry directly. If you are interested in topological naming effort involve yourself in the GSoC project:

https://forum.freecadweb.org/viewtopic.php?f=10&t=22373

And start from there. There is much more to it compared to your current proposal.

P.S. And don't try to mix both areas (things like going after a single PR) for now as Links effort by itself is already a complex thing. Achieving things like working cross-document geometry. Light/shallow clones/copies (or whatever it will be called) of geometry. That developers and users will use frequently. That would be something. And highly likely a few months/years of work involved. For example when it comes to topological naming effort it took a few years (of effort) just to get something written up as a theory/proposal for GSoC.

[realthunder]

Yes, it is a bit off topic to this thread. I am not proposing to solve topological naming problem per se, but a way to reduce its negative impact due to its volatile natural, not by adding some extra feature, but by how link can be used. That GSoc project is trying to attack the problem directly and make the topological name more stable. I don't think there is any conflict there.

[triplus]

Yes, it is a bit off topic to this thread. I am not proposing to solve topological naming problem per se, but a way to reduce its negative impact due to its volatile natural, not by adding some extra feature, but by how link can be used.

Unless i am missing something in your current proposal link and linked geometry (topology vise) should work and behave in the same way.

P.S. That is whenever the topology of link and/or linked geometry does or doesn't change expectations of the outcome should remain the same. I don't see how Link geometry could be less volatile in this regard. Unless you would go a step further and add things like algorithms deciding what is what based on the geometry (history) and comparing things geometrically. Or something like that. But as said such efforts are probably out of scope from Link effort perspective.

[realthunder]

Unless i am missing something in your current proposal link and linked geometry (topology vise) should work and behave in the same way.

Take assembly2 for an example, its constraint uses PropertyLinkSub to point to the base geometry, an edge or face. The constaint is defined in the assembly file. If multiple hierarchy of assembly is used, it becomes difficult to locate and update those constraint once topological name changes in the model. What I am proposing is to define those base geometry using specialized object and put it inside the model file where it is close to the source of the change. It can still use something like a PropertyLinkSub. When topological name changed, say from Face1 to Face10, you'll still have to manually change that, but now it is easy to find.

In the assembly file, the constraint no longer needs to know the actual Face/Edge number, it can simply use PropertyLink, or PropertyXLink if it is across document, to link to that base geometry definition object inside the model file, and relying on that object to retrieve the actual Face/Edge. Assembly of higher hierarchy can chain multiple links to obtain the base geometry all without using the topological name.

See, it is not specific about my Link object, but it is one of its use case. It can act like either PropertyLink or PropertyLinkSub depending on how you use it.

[triplus]

When topological name changed, say from Face1 to Face10, you'll still have to manually change that, but now it is easy to find.

Now i begin to understand from where the confusion was coming from. When you say improved topological naming support you are talking about it should be easier to find the base geometry topology when the topology changes. And i thought you where saying link will somehow just know new Face10 is the old Face1 when the topology changes. And i just didn't see how that could work in your current proposal.

P.S. I don't know ATM to be honest if abstraction (this is how you are describing the new additional geometry layer) is needed to achieve that. I have a feeling you don't necessarily have to create a new Link geometry just to be able to find for example faces of base geometry when the topology of the base geometry changed. But said that and if it will turn out this approach makes the most sense i am fine with it. From Link geometry perspective i am guessing it should be good at finding the base geometry topology. That much is true. As without such capability it wouldn't work anyway.

As for everything else i guess lets wait and see how things will work out for us and evolve over time.

[Pauvres_honteux]

Hi guys, us mere mortals are totally lost in these discussions, would it be too bold to ask you to make a picture each, explaining your standpoints?
Anything picture-like on the back of an envelope, take a photo of it and add it here, please?
And make sure to separate coding possibilities from user experience. E.g. we users sees two different things on the screen but in the background its the same, as in code wise same same.

An example: Explanatory picture

[realthunder]

Hi guys, us mere mortals are totally lost in these discussions, would it be too bold to ask you to make a picture each, explaining your standpoints?
Anything picture-like on the back of an envelope, take a photo of it and add it here, please?

Hmm...that's going to be difficult, because the discussion is about API design, there is not actually much UI available right now. Maybe it will be easier for user to join the discussion once I port assembly2.

[Pauvres_honteux]

Okey, roger that.
But will not the API at the very least have consequences for the function(s) we users experience and workflow and what's possible and what is not possible, in the different scenarios?

Wouldn't you guys agree that you should be able to immortalize the above said with an artwork worthy a cody such as yourself?

How about a consequence tree?
Or a flow chart?

[realthunder]

But will not the API at the very least have consequences for the function(s) we users experience and workflow and what's possible and what is not possible, in the different scenarios?

Agreed. The workflow is only meaningful under some concrete context. And in this case, obviously, the (future) assembly workbench, which I actually used (assembly2) as an example in my last few posts.

Wouldn't you guys agree that you should be able to immortalize the above said with an artwork worthy a cody such as yourself?

Wow, that sounds epic! I wish so! But, then, I am not really a picture person. If I try to draw something while talking, the picture comes out like kid's doodle, and the talking become nonsense, too. But that's no excuse, and I do believe that a picture worth a thousand words. I'll try to add them in the future discussion when suitable.

[Pauvres_honteux]

... comes out like kid's doodle, and the talking become nonsense, too.

Ooh, I know that feeling all to well ! Mi walking and chewing chewing gum at the same time, just won´t work.
But some day I´ll master it! Shame on thy giving up!