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!
User avatar
DeepSOIC
Posts: 7291
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 4:20 pm

realthunder wrote:If you know which instance, which sub element, what more do you want?
The things I think are absolutely necessary to define a selected subelement are:
1. list of instances (nested), through which the element was selected. For array instances, this must also include, which item of array (index).
2. Object the element belongs to
3. element name.
Correspondingly, assembly constraint links must allow storing that information.

For example, if I select Egde1 of a Sketch in a Body in an Instance of Part:
1. [(Instance, 0)] #0 is array index
2. <Sketcher::SketchObject>
3. "Edge1"
To recover the actual placement of selected edge, we need to build a transform(aka Placement), by looking up:
* getting up from Sketch to Part (-> Placement of Body)
* apply Placement of Instance[0]. Done
If instances are nested, we also need to figure out placement relation between them.
realthunder
Posts: 1339
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 5:06 pm

I see what you mean here. When a Coin3D node is picked by selection, it returns a path that leads from the picked node all the way to the root node. With that information, the instance ViewProvider can provide Gui::Selection extra information. So I think it is doable.
DeepSOIC wrote:Correspondingly, assembly constraint links must allow storing that information.
About this assembly constraint, I think we need to be careful, not to make the same mistake as assembly2. 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. If user really wants that, fine, he can use ShapeBinder. But I think assembly constraint object should be simply defined by a concrete Shape object, whether the Shape is linked or not is up to the user. For me, no way I am going to link it. When assemble, we'll have all kinds of space, offset, anyway. I'd use a dedicated shape to define connection base in any day. It is the part author's responsibility to update the constraint base object when he updates the part model. The constraint base in most cases can be much simpler than the actual model surface, and usually stays the same when the model going through various minor changes.
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: 7291
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 5:14 pm

realthunder wrote:About this assembly constraint, I think we need to be careful, not to make the same mistake as assembly2. We should not encourage user to create constraint based on part model sub-element.
That is a more subtle GUI question. No matter if datum geometry is used, or regular geometry, the framework remains the same. And "discouraging" shouldn't be a hard block. Sometimes, linking to elements of solids is perfectly adequate, for example when you want to quickly throw some pieces together to get some quick impression of where it's all going...
realthunder
Posts: 1339
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 5:29 pm

DeepSOIC wrote:That is a more subtle GUI question. No matter if datum geometry is used, or regular geometry, the framework remains the same. And "discouraging" shouldn't be a hard block. Sometimes, linking to elements of solids is perfectly adequate, for example when you want to quickly throw some pieces together to get some quick impression of where it's all going...
No, I don't think that's a GUI problem only. It matters what you store in the constraint object. My argument is that it should be agnostic to the actual type of geometry, datum or regular, and definitely not like assembly2 with the fragile sub element information.
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: 7291
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 5:44 pm

I understand your complaints about our fragile toponaming of style "Edge1". But what do you want now? Do you have a better option? We don't have a better toponaming just yet. If you could roll one out - that would be really awesome! But it's an independent adventure, not really tied all that much to assembly, but to everything!

But If you want to ditch the ability to use subelements in future assembly constraints completely, I am somewhat against that. Because the ability to use subelements implies the ability to use whole object (usually indicated by subelement string being empty, "").

And how does it affect selection-through-instance framework?
User avatar
NormandC
Posts: 18534
Joined: Sat Feb 06, 2010 9:52 pm
Location: Québec, Canada

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

Postby NormandC » Sat Mar 25, 2017 5:48 pm

DeepSOIC wrote:But If you want to ditch the ability to use subelements in future assembly constraints completely, I am somewhat against that.
+1
ickby
Posts: 2936
Joined: Wed Oct 05, 2011 7:36 am

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

Postby ickby » Sat Mar 25, 2017 6:20 pm

Simply tricking freecad in thinking an instance is the base object won't cut it at all. For some things one needs the base object when using the instance, for example when going into edit mode of it, it should be the edit mode of the base object (maybe at the instances location). But for other things like placement calculations, assemblies etc. you need to know that it is a instance of an object and need to treat it special. That is why this must be a first level freecad building block. It must be support by selection, must be handled by the object APIs and the tools need to be aware of it. Doing this right is a huge work, not a simple addition. I think DeepSOICs and my discussion give a very good look into what needs to be done and what needs to be supported.
realthunder
Posts: 1339
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 6:26 pm

DeepSOIC wrote:I understand your complaints about our fragile toponaming of style "Edge1". But what do you want now? Do you have a better option? We don't have a better toponaming just yet. If you could roll one out - that would be really awesome! But it's an independent adventure, not really tied all that much to assembly, but to everything!
Using auto-generated topological names is doomed. I see no way out of it. The user (part model author) should be the one to name it. Take the assemly2 constaint for an example, what I am actually suggesting is to split its constraint object into two.
  • 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. If say you want it to be able to refer to a sub element by simply storing the toponame. It may seem to be a shortcut, in an implementation point of view, but then you need to think about how to show the relationship of this connectable object to its linked shape, how to highlight the subelement once selected, how to show/hide, all that details. You can forget about all this by using a concrete document object to define a connectable. you can easily use linked sub element as usual through ShapeBinder, or other similar objects.
  • The other type of object should stay with the assembly, that defines constraints for connecting all the connectables among its parts. So, constraint objects do not need to use toponame at all. The constraint object refers to the connectable geometries that are effectively named by the part author. The part author on the other hand can still use sub element if he wants to like I mentioned above.
Last edited by realthunder on Sat Mar 25, 2017 6:52 pm, edited 1 time in total.
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
realthunder
Posts: 1339
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 6:49 pm

ickby wrote:Simply tricking freecad in thinking an instance is the base object won't cut it at all. For some things one needs the base object when using the instance, for example when going into edit mode of it, it should be the edit mode of the base object (maybe at the instances location). But for other things like placement calculations, assemblies etc. you need to know that it is a instance of an object and need to treat it special. That is why this must be a first level freecad building block. It must be support by selection, must be handled by the object APIs and the tools need to be aware of it. Doing this right is a huge work, not a simple addition. I think DeepSOICs and my discussion give a very good look into what needs to be done and what needs to be supported.
Yes it is definitely a big one. And I am just exploring here. What I am trying to do is something like this, the normal selection information gives something like DocName.ObjectName.SubElement. The instance object shall set <SubElement> to LinkedObjName.SubElement. The python script must check the Object type and then can get all the information it wants. I don't think selection and object API need to aware of that, only those scripts that are interested need to know. That is, If the instance is more or less for presentation purpose only. If you want to do boolean operation on it like normal part, then that's a different story.
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: 7291
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:00 pm

realthunder wrote:The instance object shall set <SubElement> to LinkedObjName.SubElement.
How does it figure out the Instance object? Its Placement, in particular?

Same things apply to your idea with defining specialty objects for constraints. It's an excellent idea overall, I have been aiming at that with Lattice+Part-o-magic collaboration. But you still need a way to find out instance object, through which the object is to be accessed. And moreover, it may be behind a chain of instances, not just one.