If I have understood correctly this means that, in your LinkDev branch, if a sketch constraint refers to an external object that is lost, that object is copied locally and becomes detached from the original referred object. So the constraint itself needs not to be deleted.
The external geometries in sketch are projected into sketch plane, so they are always copied. But the upstream sketch does not save the external geometry into file, they are always rebuilt when restoring. In addition, the copied geometries are kept in an array in the exact order of the reference links. Any missing reference will cause great trouble. I have changed it to save the external geometry and use a map from reference to index. The user now has full control of how to deal with a missing reference.wsteffe wrote: ↑Sat Dec 29, 2018 10:08 am If I have understood correctly this means that, in your LinkDev branch, if a sketch constraint refers to an external object that is lost, that object is copied locally and becomes detached from the original referred object. So the constraint itself needs not to be deleted.
Well, I don't want to force the user to use the workbench in one way. They can still add objects directly and select two elements and create the constraint. In this way, the element group contains internal elements that are used by the assembly itself instead of the upper level, so they are not considered as interface in this case.
Thanks for the tutorial. I guess, by using the trick, basically doing what i tried to do, but in reverse order for now!triplus wrote: ↑Fri Dec 28, 2018 2:31 pm For now, you can use the "Replace with link" trick as I shown below. If you want to link across different document. Simply copy the original object, such as the sketch here to a new document, and then go back and change the link. Make sure you have at least saved once both the linking and linked documents.
If you ever decide to add or explore such parametric features. I was thinking, as this are basic geometry building blocks, maybe introducing a new toolbar and adding the features, as a set of standalone commands, could make sense? For example Point, Line, Wire, Face, Shell, Solid. Line feature would therefore have 2 Point features underneath it (or if possible i guess 2 existing vertices selected from other features)? I have always missed the possibility, of using such direct parametric modeling approach, by having access to basic geometry building blocks in FreeCAD.It should be easy to do, we've already have feature like Part::Face.
In the "Concepts" section of your Design wiki you wrote the following sentence: "Any constraint involving some assembly will only indirectly link to the geometry element through an Element of some child assembly."realthunder wrote: ↑Sat Dec 29, 2018 11:14 pm They can still add objects directly and select two elements and create the constraint. In this way, the element group contains internal elements that are used by the assembly itself instead of the upper level, so they are not considered as interface in this case.
I usually do (or try to do) that. Since every model/component is a sub-model/sub-component according to the next level of the "project", I'm simply declaring the "Interface" for the upper level of assembly. There is no such thing as "top level assembly" in my perspective. Every assembly is potentially a sub-assembly for another possible project.A user could put into the elements group also things that are not referred by any constraint. But I really can not see why he should do that.
That is true. Every element inside any constraint is indeed a link to the real element object, which may in turn links to to another element in lower level assembly. However, there must be a bottom level assembly, where the element inside actually links to the geometry object. The way I recommend is to wrap each geometry model inside an assembly container, and manually create elements inside to define its interface to be used by higher hierarchy. No constraint will be create inside this bottom level assembly, since there is only one geometry model. But it can be inconvenient from time to time, where the user just what some quick try. So I do allow adding multiple geometry models inside a bottom level assembly, and therefore the constraints created inside this kind of assembly uses elements inside its own element group. If we follow the software terminology, this self using elements are like private attributes. But I don't want to make the assembly container structure too complicated, so I didn't make that distinction.
I do the same but I was meaning a different thing and, to be more clear, I I should have said:
A third analogy, which in my view is very instructive to catch the spirit of the interfaces, can be taken from a complex project (organized in a hierarchy of sub-projects) which is carried out in an industrial organization.
I think a single feature can do all of these. It can easily detect the intended type of shape to build by checking its children shape type. For any child vertex, it creates an edge, and so on.
