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 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.
Why an object can only be inside one App::Part?
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Re: Why an object can only be inside one App::Part?
-
- Veteran
- Posts: 2190
- Joined: Tue Jan 03, 2017 10:55 am
Re: Why an object can only be inside one App::Part?
You lost me here. What do you actually mean by this parent/child relation. Could you explain more, may be with a simple example?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.
Re: Why an object can only be inside one App::Part?
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 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?
-
- Veteran
- Posts: 2190
- Joined: Tue Jan 03, 2017 10:55 am
Re: Why an object can only be inside one App::Part?
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.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 don't think assembly2 is capable of selecting anything but the actual model shape subelement as constraint base.
Re: Why an object can only be inside one App::Part?
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.
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.