Part Container, Problems and Solutions

[realthunder]

From this thread I think I should clarify what the problem is and how it relates to assembly.

I have considered the issues you listed here. My SubShapeBinder links to the parent container of the actual bound shape. Like all other object in FC, it does not allow circular dependency, so we can be sure the parent container the SubShapeBinder links to is not a parent of SubShapeBinder itself.

When the container of the bound shape moves, the shape binder auto updates the placement. So if the container of the shape binder stays still, from the user perspective, the placement is correct.

However, when the container of the shape binder moves, say by the assembly solver, the placement is wrong from the user perspective. But there is no auto update this time, because the child (the shape binder) has no dependency on its parent (the moved container).

The user has to manually sync the placement of the binder (if that's what he want), by double clicking it. He can then proceed to do some more modeling work, and then refresh the assembly solver. A correct model will eventually stabilized by itself as everything falls in the user desired location.

Other CAD that supports this design-in-context use case has a concept of 'Snapshot', where the context is freezed when brought in, and can be manually synced by the user. This is similar to what our shape binder can be. I have added property called BindMode to allow complete freeze of shape update as well.

[DeepSOIC]

ping

ping

BTW, yesterday i found out that "Links go out of scope" error was disabled. I found git commit 7fed1a29c14c6eb5d6bf16fca826c4be2941346b, but I couldn't find any discussion surrounding that. I am curius to know, why.

[freecad-heini-1]

BUT: The consequence of such things is that we make a geometry dependend on placement of other parts. E.g. a shapbinder in body1 links to geometry in body2. The linked shapebinder in body1 would change when placement of body2 is changed, and than the geometry of body1 is recalculated (that is what everyone wants from the shapebinder). Formally we make geometry dependend on placement.

Now imagine how assembly constraints work: You link geometric feature together with a certain relation, and from this a placement for Parts is calculated to fullfill this relation. E.g. you make two planes coplanar. So for any system of assembly constraints we can state: By definition placement depends on geometry

The Problem: We created a nice circular dependency. When placement depends on geometry (constraints) and geometry depends on placement (Shapebinder) we cannot solve the problem anymore. After recalculating either the constraint is not fullfilled correctly or the shapebinder is not correct anymore.

Please let me explain how assembly in other cad-system mostly work. I know some cad-system. If you create a asm, first thing is that the new asm file will create automatically datum features like a asm-coordinate cross, asm-datum-plane and asm-datum-axis. If you assemble one ore more part into the assembly you use the given datum-features. So the position is absolute to the asm datum features, but each part can have it's own datum features. Now you copy some faces from one part to the next, maybe with something similar as a shapebinder or a clone. If you move the original part in it's position, the copied shape moves too and if you move the part with the copy - the copy will stay at it's position, but the part move. There is no reason for a circular dependency with this workflow. A typical circular dependency occur if you copy the copy back to the first part. But you can avoid circular dependency if you give training to the cad-users and explain them what circular dependency are and how to avoid. For complex assembly a top-down-design method with master-sketches or skeleton models is needed and skilled users they must know how to handle.

[wmayer]

ping

ping

BTW, yesterday i found out that "Links go out of scope" error was disabled. I found git commit 7fed1a29c14c6eb5d6bf16fca826c4be2941346b, but I couldn't find any discussion surrounding that. I am curius to know, why.

I once mentioned it in one of the several forum threads about this topic that it doesn't help anybody if many users run into this problem because many commands are not ported yet to this mechanism. The average user doesn't know why it happens nor how to fix it. This way he will see a warning that something is or will be wrong with his work flow but for now can at least continue.

The problem is known since around October, many user regularly reported about it and there was almost no helping hand to get this properly fixed. Since until end of January still nothing mentionable was done and I didn't want to delay the release further I decided to tmp. soften this hard restriction.

[DeepSOIC]

...

Thanks for the answer. I feel like it's not tmp. because it has made it into release.

[freecad-heini-1]

I once mentioned it in one of the several forum threads about this topic that it doesn't help anybody if many users run into this problem because many commands are not ported yet to this mechanism. The average user doesn't know why it happens nor how to fix it. This way he will see a warning that something is or will be wrong with his work flow but for now can at least continue.

The problem is known since around October, many user regularly reported about it and there was almost no helping hand to get this properly fixed. Since until end of January still nothing mentionable was done and I didn't want to delay the release further I decided to tmp. soften this hard restriction.

Thank you very much Werner. That's a very good answer and it described the situation perefect.

[wmayer]

...

Thanks for the answer. I feel like it's not tmp. because it has made it into release.

Well, for the 0.17 release it's permanent, of course. But with 0.18 we have all options.
Btw, as far as I understood the whole issue came up with the not yet existing assembly workbench where it's not possible to correctly compute the placements if objects can be put everywhere. But why does this actually restrict the whole application? Wouldn't it make more sense to restrict things only where needed?

[DeepSOIC]

Well, for the 0.17 release it's permanent, of course. But with 0.18 we have all options.
Btw, as far as I understood the whole issue came up with the not yet existing assembly workbench where it's not possible to correctly compute the placements if objects can be put everywhere. But why does this actually restrict the whole application? Wouldn't it make more sense to restrict things only where needed?

The whole idea of this restriction was to not break all projects, as accounting for placements becomes gradually implemented. Now, say one implements placements for Part Union. Then, every project which did cross-container fusion will get a changed project. But after all, that is not such a big deal, since the fusion is "broken" as of now, so it's unlikely people would use it across containers with nonzero placements, anyway.

[freecad-heini-1]

...

Thanks for the answer. I feel like it's not tmp. because it has made it into release.

Well, for the 0.17 release it's permanent, of course. But with 0.18 we have all options.
Btw, as far as I understood the whole issue came up with the not yet existing assembly workbench where it's not possible to correctly compute the placements if objects can be put everywhere. But why does this actually restrict the whole application? Wouldn't it make more sense to restrict things only where needed?

I like what I see from Realthunder. The improvements to avoid topolocigal-naming, the assembly3 workbench, the color management. Please help that this great work will be integrated into 0.18 master.

[chrisb]

BUT: The consequence of such things is that we make a geometry dependend on placement of other parts. E.g. a shapbinder in body1 links to geometry in body2. The linked shapebinder in body1 would change when placement of body2 is changed, and than the geometry of body1 is recalculated (that is what everyone wants from the shapebinder). Formally we make geometry dependend on placement.

Now imagine how assembly constraints work: You link geometric feature together with a certain relation, and from this a placement for Parts is calculated to fullfill this relation. E.g. you make two planes coplanar. So for any system of assembly constraints we can state: By definition placement depends on geometry

The Problem: We created a nice circular dependency.

From what I read here we can agree that in the current state - without assembly - we can have a ShapeBinder respecting the placement of it's ancestors. We don't have cyclic dependencies in a wellformed model, to implement it is super simple.

If we introduce an AssemblyContainer it could contain everything we have now with all their placements. It would behave like a top level Part container which serves the only purpose to provide a new universe - or to be more technical: a new coordinate system - and inside everything with all it's references stays as before.

Then the whole AssemblyContainer can be positioned relative to other AssemblyContainers and inside everything could stay as before. That means we have only hierarchical but no cyclic dependencies.