body / shape dependency issu

About the development of the Part Design module/workbench. PLEASE DO NOT POST HELP REQUESTS HERE!
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
User avatar
DeepSOIC
Veteran
Posts: 7896
Joined: Fri Aug 29, 2014 12:45 am
Location: used to be Saint-Petersburg, Russia

Re: body / shape dependency issu

Post by DeepSOIC »

ickby wrote: Tue Jul 04, 2017 5:28 pm the problem stays exactly the same:
The problem didn't involve any assembly constraints to begin with, no?

Sure, doing that with assembly constraints won't work, it won't in any case.
freecad-heini-1
Veteran
Posts: 7790
Joined: Tue Jan 07, 2014 11:10 am
Contact:

Re: body / shape dependency issu

Post by freecad-heini-1 »

What about a top down design strategy?
On top a skeleton modell maybe build out from datum-planes and datum-axis and some surfaces.
Further parts can connect via copy geometry (external geometry) to the skeleton modell. If you change skeleton dimensions, maybe a distance between two axis, all connected parts must recompute for the right dimensions. Automatically or manually, that's the question. From my point of view this is the way to go.
ickby
Veteran
Posts: 3116
Joined: Wed Oct 05, 2011 7:36 am

Re: body / shape dependency issu

Post by ickby »

.The problem didn't involve any assembly constraints to begin with, no?

Sure, doing that with assembly constraints won't work, it won't in any case.
No, initially the problem did not involve them, but the issues of all provided approaches come up when considering assembly constraints. Everything proposed up to now would break them, and hence I don't see the proposals as a real solution for the initial use case. It may be my personal prioritisation, but assembly constraints are imho too fundamental to drop, and hence exclude all proposed workarounds.
mlampert
Veteran
Posts: 1772
Joined: Fri Sep 16, 2016 9:28 pm

Re: body / shape dependency issu

Post by mlampert »

ickby wrote: Tue Jul 04, 2017 6:17 pm No, initially the problem did not involve them, but the issues of all provided approaches come up when considering assembly constraints. Everything proposed up to now would break them, and hence I don't see the proposals as a real solution for the initial use case. It may be my personal prioritisation, but assembly constraints are imho too fundamental to drop, and hence exclude all proposed workarounds.
I think you are wrong on this. The placement of a part is not dependent on it's shape. The placement in an assembly constraint is defined by a reference point/edge/face of the part itself - and an anchor point/edge/face of some other part. I can change the shape of the part all day long and it's placement wouldn't change one bit.

If you enter conflicting constraints then obviously an automatic placement algorithm won't converge and we will bring up a red flag and not accept that constraint, same as the sketcher does.
User avatar
DeepSOIC
Veteran
Posts: 7896
Joined: Fri Aug 29, 2014 12:45 am
Location: used to be Saint-Petersburg, Russia

Re: body / shape dependency issu

Post by DeepSOIC »

@mlampert
I think you can achieve what you want by making a dummy object (say, a Part Ellipse), and bind Body's Placement to be equal to Ellipse's Placement with expressions. Then you can just use Ellipse.Placement instead of Body.Plaecment.

I invite you to use Lattice Placement for the purpose :mrgreen:
User avatar
saso
Veteran
Posts: 1924
Joined: Fri May 16, 2014 1:14 pm
Contact:

Re: body / shape dependency issu

Post by saso »

ickby wrote: Mon Jul 03, 2017 5:45 amIf you have your two bodies within a Part, than a feature in the Part can know his own palcement, the placement of the two bodies and also everything inside the bodies, as they are below in the hirachy.
From how I understand (and my understanding of all this does have limits :roll: ), if we look at OnShape, that has a similar "joint" feature available from its FeatureScript examples, it seems like they also work in a similar way as ickby describes / suggests above. That is, if we take for example the "Box Joint" example from https://www.onshape.com/featurescript and if we see our "Part" as onshapes "Part Studio" and our "Body" as onshape "Part" then we can see in this example several "parts" inside the "part studio" and the "box joint" features in the corners between the "parts" but also under the same "part studio" (in our case and as described by ickby that would be several "bodies" inside a "part" and "joint" features in the corners between the "bodies" but also under the same "part"). And, as I understand, they also don't have this on the assembly level.

https://www.onshape.com/cad-blog/whats- ... 05-30-2016

Edit: see this video for the above described "Box Joint" example at 1:20 https://www.onshape.com/videos/furniture-industry , but from how I understand, it is important that we look at onshapes "part" as our "body" and onshapes "part studio" as our "part"
ickby
Veteran
Posts: 3116
Joined: Wed Oct 05, 2011 7:36 am

Re: body / shape dependency issu

Post by ickby »

The placement in an assembly constraint is defined by a reference point/edge/face of the part itself - and an anchor point/edge/face of some other part. I can change the shape of the part all day long and it's placement wouldn't change one bit.
And the point/edge/face anchors or references are what when not user selections on the shapes of the Parts childs (or body childs)? And if you change those child shapes your anchors change. And hence the assembly would need recalculation. And this was now the 4th time I explained this.

I think you are wrong on this. The placement of a part is not dependent on it's shape.
I'm definitely not wrong on this, as this is how I designed it and how I envsioned it to work. This is what I go for. Maybe there are other options to implement assembly constraints, but than you need to put in more effort and a more detailed design layout how you like it to have. A simple "No" is just not enough.

If you enter conflicting constraints then obviously an automatic placement algorithm won't converge and we will bring up a red flag and not accept that constraint, same as the sketcher does.
The whole discussion has nothing to do with the constraint solver itself.
Post Reply