Yes, this thing is complicated by existence of containers like App::Part. It would be a lot easier if DocumentObject has a method to return its own sub element. So the script just call instance.getElement('LinkedObjName.SubElement'), and in turn instance will call LinkedObjName.getElement('SubElement'), it doesn't matter what type of LinkedObjName is. The Placement calculation can be handled nicely as well. For 'instance', it will reverse its linked objects Placement, and apply its own. Anyway, I'll play around and see.DeepSOIC wrote:How does it figure out the Instance object? Its Placement, in particular?
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!
-
- Veteran
- Posts: 2190
- Joined: Tue Jan 03, 2017 10:55 am
Re: Why an object can only be inside one App::Part?
- DeepSOIC
- Veteran
- Posts: 7896
- Joined: Fri Aug 29, 2014 12:45 am
- Location: used to be Saint-Petersburg, Russia
Re: Why an object can only be inside one App::Part?
Let me show you what I have in Lattice. There is "Attached Placement" object, which can be attached to elements of geometry in the same way PartDesign Datum planes can. Then, you can use it to define two "mating points", so to say, and use the tool "Moved object" to bring one object to other using the "mating points". And attachment isn't the only way to define these "mating points". These mating points are simply Placements under the hood, and that's how they are called. And you don't even need an assembly solver to assemble stuff with placements.realthunder wrote:The first type of object shall stay with Part container, to define all the connectable surface. And that surface definition should be agnostic to the type of the geometry to use.
Example. Torus and Box. I attach one placement to torus, and another to Box. Then I create a moved object to bring Torus to be effectively "attached" to Box.
- Attachments
-
- assembly-with-lattice-1.png (398.14 KiB) Viewed 2136 times
-
- assembly-with-lattice-2.png (344.21 KiB) Viewed 2136 times
- DeepSOIC
- Veteran
- Posts: 7896
- Joined: Fri Aug 29, 2014 12:45 am
- Location: used to be Saint-Petersburg, Russia
Re: Why an object can only be inside one App::Part?
Same problem, again. I have to know Instance! If selection doesn't give me Instance, I would instead ask Sketch.getElement("SubElement"), and will end up in a completely irrelevant place.realthunder wrote:instance.getElement('LinkedObjName.SubElement'),
It doesn't matter how, but selection has to provide that three bits of information I outlined a few posts above. It can be in a form like I described, or like you just said (instance object + string "object.subelement"). And as I already said: there can be a list of instances to get through, not just one. For example if I have an instance of a subassembly, which has instances.
- DeepSOIC
- Veteran
- Posts: 7896
- Joined: Fri Aug 29, 2014 12:45 am
- Location: used to be Saint-Petersburg, Russia
Re: Why an object can only be inside one App::Part?
This also means we will have to define Instance in some module dependent of Part. And it effectively rules out the same thing to work with meshes. Or any other custom object, which returns something else then OCC shape. Not that it cannot be solved, but it becomes not much less involved than making some tools in corresponding modules to become aware of instances. So I think the "stupid instance" that doesn't support getElement is the way to go.realthunder wrote:instance.getElement('LinkedObjName.SubElement')
-
- Veteran
- Posts: 2190
- Joined: Tue Jan 03, 2017 10:55 am
Re: Why an object can only be inside one App::Part?
I seem to understand a bit more of your way of thinking now. You put more concern on placement, and probably implicitly thinks that the placement shall be attached to the part model. What I am suggesting is to make this attachment surface explicit. Anyway I can't comment much without trying your module. I'll definitely give it a try later.DeepSOIC wrote:Let me show you what I have in Lattice
- DeepSOIC
- Veteran
- Posts: 7896
- Joined: Fri Aug 29, 2014 12:45 am
- Location: used to be Saint-Petersburg, Russia
Re: Why an object can only be inside one App::Part?
Surface... surface... I want vertex and edge, you betcha! So lets make them explicit.. oh, hello, that's exactly what part/partdesign are aimed to do, why reinvent the wheel?realthunder wrote:What I am suggesting is to make this attachment surface explicit.
- DeepSOIC
- Veteran
- Posts: 7896
- Joined: Fri Aug 29, 2014 12:45 am
- Location: used to be Saint-Petersburg, Russia
Re: Why an object can only be inside one App::Part?
OK, one more opinion. It seems to me, you put too much care for stability of assembly. Sure, it's annoying when things break. But the ultimate important thing is to minimize the time it takes to arrive to the result (or the amount of frustration). And repairing an assembly might not be that big of a deal, depending on situation (probably, on the number of parts in the assembly). While defining all potential "surfaces" for every piece of design, and giving them names might take a lot of time and thinking.
Sometimes, for example, I spent too much time on making my model incredibly parametric.. in the end to realize it doesn't work, and as a result, most of the time and effort I spent on making sure my model was robust and parametric was essentially wasted. (it was 3d-printed ion wind speaker model, for example)
Another example, when I want to reproduce a part that I have in my hands, I absolutely don't care about it being parametric. Then I just use old-workflow partdesign, with its horrible breaking links and vertical dependency structure. Because all I need is to print out a copy of that broken piece, ASAP, and old-workflow PartDesign is excellent because it's quick and easy!
Example here: https://forum.freecadweb.org/viewtopic.php?f=24&t=9974
So I think, it's best to provide maximum freedom, and let the user choose, what he/she wants, a super-robust model generator program, or a one-off hard-to-modify design.
Sometimes, for example, I spent too much time on making my model incredibly parametric.. in the end to realize it doesn't work, and as a result, most of the time and effort I spent on making sure my model was robust and parametric was essentially wasted. (it was 3d-printed ion wind speaker model, for example)
Another example, when I want to reproduce a part that I have in my hands, I absolutely don't care about it being parametric. Then I just use old-workflow partdesign, with its horrible breaking links and vertical dependency structure. Because all I need is to print out a copy of that broken piece, ASAP, and old-workflow PartDesign is excellent because it's quick and easy!
Example here: https://forum.freecadweb.org/viewtopic.php?f=24&t=9974
So I think, it's best to provide maximum freedom, and let the user choose, what he/she wants, a super-robust model generator program, or a one-off hard-to-modify design.
-
- Veteran
- Posts: 2190
- Joined: Tue Jan 03, 2017 10:55 am
Re: Why an object can only be inside one App::Part?
OK, bad word choice, should've said geometry. And I am not saying your lattice approach lacks the possibility that I want. You said it can attach to anything, so user are free to choose. Then, again, I'd have to try it before further comment.DeepSOIC wrote:Surface... surface... I want vertex and edge, you betcha! So lets make them explicit.. oh, hello, that's exactly what part/partdesign are aimed to do, why reinvent the wheel?realthunder wrote:What I am suggesting is to make this attachment surface explicit.
Re: Why an object can only be inside one App::Part?
When you add relations between features you get parent/child relationship. Changing underlying topology of parent feature therefore affects the result (child feature). Assembly constraint or just about anything else works in the same way.realthunder wrote:About this assembly constraint, I think we need to be careful, not to make the same mistake as assembly2.
It's doable. But if done you won't be able to add parent/child relationship anymore. Things like creating drawings with updating dimensions are therefore not doable anymore.We should not encourage user to create constraint based on part model sub-element. It is some what like the old PartDesign, where the user is forced to map sketch onto model, and get burned when updating.
-
- Veteran
- Posts: 2190
- Joined: Tue Jan 03, 2017 10:55 am
Re: Why an object can only be inside one App::Part?
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.triplus wrote:It's doable. But if done you won't be able to add parent/child relationship anymore. Things like creating drawings with updating dimensions are therefore not doable anymore.