Why an object can only be inside one App::Part?

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!
triplus
Veteran
Posts: 9471
Joined: Mon Dec 12, 2011 4:45 pm

Re: Why an object can only be inside one App::Part?

Post by triplus »

realthunder wrote:For the record, I said "not encourage", I didn't even say "discourage", certainly not forbidden. Of course, you should still be able to use the old way, just like in the new PartDesign. Look, all I am saying is that topological naming is fragile, we have little control of it, and what can we do about it. You get the convenience of auto updating feature if things go right, but there is no guarantee. Surely you have other ways to achieve dependency, using expressions for example. And the user should be able to choose.
If you add parent/child relation expressions are affected by topology changes in the same way Part(Design (NEXT)) or Assembly 2 are. And if you don't add parent/child relation expressions are a lot less useful.
realthunder
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

Re: Why an object can only be inside one App::Part?

Post by realthunder »

triplus wrote:If you add parent/child relation expressions are affected by topology changes in the same way Part(Design (NEXT)) or Assembly 2 are. And if you don't add parent/child relation expressions are a lot less useful.
You lost me here. What do you actually mean by this parent/child relation. Could you explain more, may be with a simple example?
Try Assembly3 with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
triplus
Veteran
Posts: 9471
Joined: Mon Dec 12, 2011 4:45 pm

Re: Why an object can only be inside one App::Part?

Post by triplus »

realthunder wrote:You lost me here. What do you actually mean by this parent/child relation. Could you explain more, may be with a simple example?
When you use expression and take some parameter of parent feature to define geometry of the child feature (through expression). You end up in the same (topology) situation as when using Assembly 2 workbench to add a constraint between 2 features. There is no real difference involved.
realthunder
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

Re: Why an object can only be inside one App::Part?

Post by realthunder »

triplus wrote:When you use expression and take some parameter of parent feature to define geometry of the child feature (through expression). You end up in the same (topology) situation as when using Assembly 2 workbench to add a constraint between 2 features. There is no real difference involved.
I thought that's the main reason of PartDesign Next, no? You have datum plane to map to instead of the actual model shape. Besides, if you really want to have a parent/child relationship. Who should be the parent? The more complex and volatile actual model, or the potentially much simpler constraint base geometry? This decision making is more evident when you build your part using PartDesign. A threaded socket in the model is a simple cylinder pocket in early steps. And that cylinder comes from a sketch on a datum plane. You can either choose that actual cylinder to be the constraint base, or better, the sketch itself, or a dedicated geometry derived from that sketch where you can do all kinds of magic stuff without worrying of topological change of the model. And yet this constraint geometry and the model is linked through the same sketch. So, you get the auto update you want.

I don't think assembly2 is capable of selecting anything but the actual model shape subelement as constraint base.
Try Assembly3 with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
triplus
Veteran
Posts: 9471
Joined: Mon Dec 12, 2011 4:45 pm

Re: Why an object can only be inside one App::Part?

Post by triplus »

Usage of more abstract references as for example plane or part/container center point. That should reduce the changing topology related issues to some extent. But the thing with abstract is it won't in general replace more concrete approach when using the geometry/topology directly. It will supplement it and provide new possibilities. Note that also the ways on how to use the geometry/topology directly improved in PartDesign NEXT.

Think of it as before we had expressions you could assemble a shaft and a pulley but there wasn't a straightforward way to make the diameter equal. For such use case expressions are therefore a perfect fit. The same can be said for abstract references and the same can be said for concrete references. Experienced operator is what is needed in the end anyway to make it all work good. As for Assembly 2 i guess it could work with more abstract references if somebody would implement the support.
Post Reply