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!
realthunder
Posts: 1344
Joined: Tue Jan 03, 2017 10:55 am

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

Postby realthunder » Sat Mar 25, 2017 7:14 pm

DeepSOIC wrote:How does it figure out the Instance object? Its Placement, in particular?
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.
Try Assembly3 (latest version 0.10.2) along 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
User avatar
DeepSOIC
Posts: 7292
Joined: Fri Aug 29, 2014 12:45 am
Location: Saint-Petersburg, Russia

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

Postby DeepSOIC » Sat Mar 25, 2017 7:22 pm

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.
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.

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
assembly-with-lattice-1.png (398.14 KiB) Viewed 993 times
assembly-with-lattice-2.png
assembly-with-lattice-2.png (344.21 KiB) Viewed 993 times
User avatar
DeepSOIC
Posts: 7292
Joined: Fri Aug 29, 2014 12:45 am
Location: Saint-Petersburg, Russia

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

Postby DeepSOIC » Sat Mar 25, 2017 7:32 pm

realthunder wrote:instance.getElement('LinkedObjName.SubElement'),
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.
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.
User avatar
DeepSOIC
Posts: 7292
Joined: Fri Aug 29, 2014 12:45 am
Location: Saint-Petersburg, Russia

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

Postby DeepSOIC » Sat Mar 25, 2017 7:47 pm

realthunder wrote:instance.getElement('LinkedObjName.SubElement')
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
Posts: 1344
Joined: Tue Jan 03, 2017 10:55 am

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

Postby realthunder » Sat Mar 25, 2017 7:51 pm

DeepSOIC wrote:Let me show you what I have in Lattice
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.
Try Assembly3 (latest version 0.10.2) along 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
User avatar
DeepSOIC
Posts: 7292
Joined: Fri Aug 29, 2014 12:45 am
Location: Saint-Petersburg, Russia

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

Postby DeepSOIC » Sat Mar 25, 2017 8:16 pm

realthunder wrote:What I am suggesting is to make this attachment surface explicit.
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?
User avatar
DeepSOIC
Posts: 7292
Joined: Fri Aug 29, 2014 12:45 am
Location: Saint-Petersburg, Russia

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

Postby DeepSOIC » Sat Mar 25, 2017 8:48 pm

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.
realthunder
Posts: 1344
Joined: Tue Jan 03, 2017 10:55 am

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

Postby realthunder » Sat Mar 25, 2017 8:50 pm

DeepSOIC wrote:
realthunder wrote:What I am suggesting is to make this attachment surface explicit.
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?
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.
Try Assembly3 (latest version 0.10.2) along 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
Posts: 9136
Joined: Mon Dec 12, 2011 4:45 pm

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

Postby triplus » Sat Mar 25, 2017 9:27 pm

realthunder wrote:About this assembly constraint, I think we need to be careful, not to make the same mistake as assembly2.
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.
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.
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.
realthunder
Posts: 1344
Joined: Tue Jan 03, 2017 10:55 am

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

Postby realthunder » Sun Mar 26, 2017 2:38 am

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.
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.
Try Assembly3 (latest version 0.10.2) along 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