App::link of sketch in PD Body

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!
Post Reply
emills2
Posts: 875
Joined: Tue Apr 28, 2015 11:23 pm

App::link of sketch in PD Body

Post by emills2 »

Does an App::link of a sketch not provide the data needed by Part Design Body to use it as a sketch?

Or does the workbench actively track down App::links and prohibit them?

in the rest of the post i say "i" a lot. i don't mean it as a demand. i don't want to say "you", because i can't speak for you. i don't want to say "we", better i have not been deputized to represent others. I can only speak for me, but please try to put yourself in my shoes. pretend the "i" is actually you for a few minutes. try not to picture someone telling you, but imagine it is you yourself saying these things. At the end, if your conclusion is "well that was weird, i don't agree with any of that", so be it. Thank you

I know i can use spreadsheets to share data. I know that Assembly 4 has implemented an absolutely kickass variables system. Both of these things are wonderful, but i feel retarded when i have to use these systems to redo the math for derived dimensions to rebuild matching parts, especially when the derived dimensions are sitting right there in front of me in a sketch...that Part Design refuses to use.

Derived dimensions/geometry is squarely the job of the sketcher. PartDesign should be able to use it directly.

A reference sketch that cannot be used directly, but has to be externally linked and retraced entirely in a new sketch is a wasteful workaround, not a solution. i click the mouse on lines and points for a living, saying "just work 4, 10, 100 times longer for the same result" is not reasonable.

I don't want a linked carbon copy. A linked carbon copy is a wonderful tool, when i want to fork a sketch. I don't want to fork the sketch.

Once again, what i want is right there. The sketch. perfect. finished. exactly where i want it to be in my document, whichever document that may be. I want to use that sketch's output geometry.

App::link is the perfect mechanism for this.

Users won't do it on accident, no legitimate confusion to possibly speak of. This is the sketch i want in my body. i don't want to move it to that body. it could be at the part level, or it could be a the document level, or it could be in another document. App::link take care of that.

If the body wants to own something, to satisfy it's possessive needs, take the link itself. it's all yours. leave my base sketch alone, wherever i choose to keep it. just close your eyes and pretend that the output geometry was defined in a local sketch.

-create link
-drag and drop to Part Design body

done. Changes to the linked sketch are treated as if a local sketch had been edited. Part Design doesn't even know or care about the difference.

life is beautiful, FreeCAD takes over the world, and future textbooks start to replace the term "Mechanical Design" with "Part Design" to avoid confusion.
User avatar
Zolko
Veteran
Posts: 2213
Joined: Mon Dec 17, 2018 10:02 am

Re: App::link of sketch in PD Body

Post by Zolko »

emills2 wrote: Thu Feb 27, 2020 7:26 am If the body wants to own something, to satisfy it's possessive needs, take the link itself. it's all yours. leave my base sketch alone, wherever i choose to keep it. just close your eyes and pretend that the output geometry was defined in a local sketch.
I don't think that App::Link works that way: the linked object is not really there, you only see an image of it, like a hologram of an object is not really there, even though you can see it. FreeCAD works in layers (like onions) and one layer is the OCC layer, one is the 3D-Coin layer. An App::Link is in the 3D-Coin layer while the object you want must be in the OCC layer. You can "import" from one layer to the other, but it's not automatically there.
try the Assembly4 workbench for FreCAD — tutorials here and here
emills2
Posts: 875
Joined: Tue Apr 28, 2015 11:23 pm

Re: App::link of sketch in PD Body

Post by emills2 »

Zolko wrote: Thu Feb 27, 2020 8:34 am I don't think that App::Link works that way: the linked object is not really there, you only see an image of it, like a hologram of an object is not really there, even though you can see it. FreeCAD works in layers (like onions) and one layer is the OCC layer, one is the 3D-Coin layer. An App::Link is in the 3D-Coin layer while the object you want must be in the OCC layer. You can "import" from one layer to the other, but it's not automatically there.
of course, that's the whole beauty of links. but they would be useless if you couldn't get to the data if you want.

sure enough:

select link of sketch, send to console explore, and BAM

Code: Select all

>>> # Gui.Selection.addSelection('PD_WTF','Link')
>>> Gui.Selection.setPreselection(App.getDocument('PD_WTF').getObject('Link'),'',tp=2)
>>> Gui.Selection.setPreselection(App.getDocument('PD_WTF').getObject('Link'),'',tp=2)
>>> obj = App.getDocument("PD_WTF").getObject("Link")
>>> obj
<App::Link object>
>>> obj.LinkedObject
<Sketcher::SketchObject>
>>> obj.LinkedObject.Content
'    <Extensions Count="1">\n        <Extension type="Part::AttachExtension" name="AttachExtension">\n        </Extension>\n    </Extensions>\n    <Properties Count="15" TransientCount="0">\n        <Property name="AttacherType" type="App::PropertyString" status="8">\n            <String value="Attacher::AttachEnginePlane"/>\n        </Property>\n        <Property name="AttachmentOffset" type="App::PropertyPlacement">\n            <PropertyPlacement Px="0" Py="0" Pz="0" Q0="0" Q1="0" Q2="0" Q3="1" A="0" Ox="0" Oy="0" Oz="1"/>\n        </Property>\n        <Property name="Constraints" type="Sketcher::PropertyConstraintList">\n            <ConstraintList count="8">\n                <Constrain Name="" Type="1" Value="0" First="1" FirstPos="2" Second="2" SecondPos="1" Third="-2000" ThirdPos="0" LabelDistance="10" LabelPosition="0" IsDriving="1" IsInVirtualSpace="0" IsActive="1" />\n                <Constrain Name="" Type="1" Value="0" First="2" FirstPos="2" Second="3" SecondPos="1" Third="-2000" ThirdPos="0" LabelDistance="10" LabelPosition="0" IsDriving="1" IsInVirtualSpace="0" IsActive="1" />\n                <Constrain Name="" Type="1" Value="0" First="3" FirstPos="2" Second="0" SecondPos="1" Third="-2000" ThirdPos="0" LabelDistance="10" LabelPosition="0" IsDriving="1" IsInVirtualSpace="0" IsActive="1" />\n                <Constrain Name="" Type="2" Value="0" First="0" FirstPos="0" Second="-2000" SecondPos="0" Third="-2000" ThirdPos="0" LabelDistance="10" LabelPosition="0" IsDriving="1" IsInVirtualSpace="0" IsActive="1" />\n                <Constrain Name="" Type="2" Value="0" First="2" FirstPos="0" Second="-2000" SecondPos="0" Third="-2000" ThirdPos="0" LabelDistance="10" LabelPosition="0" IsDriving="1" IsInVirtualSpace="0" IsActive="1" />\n                <Constrain Name="" Type="3" Value="0" First="1" FirstPos="0" Second="-2000" SecondPos="0" Third="-2000" ThirdPos="0" LabelDistance="10" LabelPosition="0" IsDriving="1" IsInVirtualSpace="0" IsActive="1" />\n                <Constrain Name="" Type="3" Value="0" First="3" FirstPos="0" Second="-2000" SecondPos="0" Third="-2000" ThirdPos="0" LabelDistance="10" LabelPosition="0" IsDriving="1" IsInVirtualSpace="0" IsActive="1" />\n                <Constrain Name="" Type="13" Value="0" First="0" FirstPos="1" Second="-2" SecondPos="0" Third="-2000" ThirdPos="0" LabelDistance="10" LabelPosition="0" IsDriving="1" IsInVirtualSpace="0" IsActive="1" />\n            </ConstraintList>\n        </Property>\n        <Property name="ExpressionEngine" type="App::PropertyExpressionEngine" status="67108864">\n            <ExpressionEngine count="0">\n            </ExpressionEngine>\n        </Property>\n        <Property name="ExternalGeometry" type="App::PropertyLinkSubList">\n            <LinkSubList count="1">\n                <Link obj="Sketch" sub="Edge10"/>\n            </LinkSubList>\n        </Property>\n        <Property name="Geometry" type="Part::PropertyGeometryList" status="8192">\n            <GeometryList count="4">\n                <Geometry  type="Part::GeomLineSegment">\n                    <Construction value="0"/>\n                    <LineSegment StartX="0" StartY="-0.653153" StartZ="0" EndX="49.1075" EndY="-0.653153" EndZ="0"/>\n                </Geometry>\n                <Geometry  type="Part::GeomLineSegment">\n                    <Construction value="0"/>\n                    <LineSegment StartX="49.3159" StartY="0.955414" StartZ="0" EndX="49.3159" EndY="41.3458" EndZ="0"/>\n                </Geometry>\n                <Geometry  type="Part::GeomLineSegment">\n                    <Construction value="0"/>\n                    <LineSegment StartX="49.3159" StartY="41.3458" StartZ="0" EndX="0" EndY="41.3458" EndZ="0"/>\n                </Geometry>\n                <Geometry  type="Part::GeomLineSegment">\n                    <Construction value="0"/>\n                    <LineSegment StartX="0" StartY="41.3458" StartZ="0" EndX="0" EndY="-0.653153" EndZ="0"/>\n                </Geometry>\n            </GeometryList>\n        </Property>\n        <Property name="Label" type="App::PropertyString" status="134217728">\n            <String value="Sketch002"/>\n        </Property>\n        <Property name="Label2" type="App::PropertyString" status="67108992">\n            <String value=""/>\n        </Property>\n        <Property name="MapMode" type="App::PropertyEnumeration">\n            <Integer value="5"/>\n        </Property>\n        <Property name="MapPathParameter" type="App::PropertyFloat" status="8">\n            <Float value="0"/>\n        </Property>\n        <Property name="MapReversed" type="App::PropertyBool">\n            <Bool value="false"/>\n        </Property>\n        <Property name="Placement" type="App::PropertyPlacement" status="8388612">\n            <PropertyPlacement Px="0" Py="0" Pz="0" Q0="0.707107" Q1="0" Q2="0" Q3="0.707107" A="1.5708" Ox="1" Oy="0" Oz="0"/>\n        </Property>\n        <Property name="Shape" type="Part::PropertyPartShape">\n        </Property>\n        <Property name="Support" type="App::PropertyLinkSubList">\n            <LinkSubList count="1">\n                <Link obj="XZ_Plane" sub=""/>\n            </LinkSubList>\n        </Property>\n        <Property name="Visibility" type="App::PropertyBool" status="648">\n            <Bool value="true"/>\n        </Property>\n    </Properties>\n'
the entire sketch is on that last line. [edit] so (oversimplifying) instead of checking if the object i drop into the body is a sketch, check if the linked object of dropped link is a sketch. then accept link.LinkedObject as a sketch, which it is! [edit]

The critical question is whether the Part Design devs would allow Part Design to be made to handle accessing sketch data from a link. and if they prefer not to do so directly, would they blockade workarounds.

I seem to recall without specific examples at hand that several useful workarounds were actively hunted down and foiled to prevent data reuse between Part Design bodies in the past. So if link was tailored to provide the right data to the body, would that be a wasted effort as well?

right now, i cannot even drag a sketch link into a part design body.

simple use example: i want a library of profile sketches. i don't want to redraw a 2" X 2" X .125" wall metal tube profile every time i want to extrude one or revolve one. and as i said above, i don't want to trace a reference sketch, or a carbon copy, or sketch it again with spreadsheet or variable data in the dimensions. those strategies are fine, but link covers a very specific and common scenario. i want a link. i want a single source of truth in the data.

more general use case: i want an assembly 4 model document, and i want several stacked master layout sketches of multiple components, built on top of the skeleton sketch. then i want to painlessly pull the relevant sketch info into individual Part>Bodies to model the actual parts.

variable swill have their place, spreadsheet will have their place, but i don't want to type long formulas to recalculate derived dimensions, just because Part Design insists on assigning data to one and only one Body. Link would allow that without breaking the Part Design development strategy...just allow the link interface. let the body own the link, and let the link do it's business.
emills2
Posts: 875
Joined: Tue Apr 28, 2015 11:23 pm

Re: App::link of sketch in PD Body

Post by emills2 »

link is amazing.

if you send a link to console,

Code: Select all

>>> # Gui.Selection.addSelection('link_amazeballs','Part','Link.')
>>> ### Begin command Std_SendToPythonConsole
>>> obj = App.getDocument("link_amazeballs").getObject("Link")
>>> ### End command Std_SendToPythonConsole
>>> obj
<App::Link object>
>>> 
it says it's a link. sure enough. you browse it's properties in the console, and there is no shape. understandable, it's just a link...

Code: Select all

>>> obj.Shape
<Wire object at 0000013251185BA0>
>>> 
what the? but? there was no listed property, and it still returns a wire!

Code: Select all

>>> # Gui.Selection.clearSelection()
>>> Part.show(obj.Shape)
>>> 
it spat back the wire of my original sketch to the document...exactly what you need to extrude or revolve. so there's no shape...unless you want one...because you want one? pretty handy!
emills2
Posts: 875
Joined: Tue Apr 28, 2015 11:23 pm

Re: App::link of sketch in PD Body

Post by emills2 »

so if the Part Design devs are not interested in taking advantage of link for their own purposes here's what a workaround might look like:

a "contraband" container for links. if he had the time and we could agree on a price, i would gladly pay Realthunder to make something look like a sketch but is really a link. just good enough to fool Part Design validation and pass along the sketch data.

Part Design would think it's a sketch, it would get all the data it expects, and when the link updates, it just looks like the sketch was edited, so it triggers the relevant recompute. that's the end goal here: i want to edit my Part Design Body sketches by using links. which ought to be my business.

But if Part Design devs choose to, they could actively hunt down the "contraband" containers, and make the whole effort pointless. or they could ignore it. or they could embrace links and adapt their validation procedures?
chrisb
Veteran
Posts: 53945
Joined: Tue Mar 17, 2015 9:14 am

Re: App::link of sketch in PD Body

Post by chrisb »

Realthunder said he was going to include the Link stuff in PartDesign as well, but he is not there yet.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
vocx
Veteran
Posts: 5197
Joined: Thu Oct 18, 2018 9:18 pm

Re: App::link of sketch in PD Body

Post by vocx »

emills2 wrote: Thu Feb 27, 2020 9:35 am so if the Part Design devs are not interested in taking advantage of link...
This entire thread sounds like you are having a stroke. Yes, App Link inside PartDesign Body and with sketches is a good idea, and was already mentioned a few times. But it is not trivial, otherwise it would have been done already. You talk about it as if there were lots of PartDesign developers and they refused to implement this. There is currently no dedicated PartDesign developer. Realthunder has done a lot lately, Werner fixes the code whenever he has time, but that's basically it. It's not a conspiracy against App Link, it's just hard work, and nobody to do it.

Why Link should be available in PartDesign
realthunder wrote: Mon Aug 26, 2019 9:33 am Yes, I'll add the Link support to PartDesign for sure. I just need some time to think a bit thorough about this, because I have other bigger ideas to try out. For the feature you wanted, it boils down to modify the attacher engine to work with Link, but then it still involves modification all over PD to make it accept Link as base.
Always add the important information to your posts if you need help. Also see Tutorials and Video tutorials.
To support the documentation effort, and code development, your donation is appreciated: liberapay.com/FreeCAD.
User avatar
adrianinsaval
Veteran
Posts: 5541
Joined: Thu Apr 05, 2018 5:15 pm

Re: App::link of sketch in PD Body

Post by adrianinsaval »

emills2 wrote: Thu Feb 27, 2020 9:35 am so if the Part Design devs are not interested in taking advantage of link for their own purposes
My understanding is that there currently isn't any dedicated Part Design developers so I think it's more a case of not implemented yet rather than someone being against it.

How about using a subshapebinder? Attached a minimal example, it works linking external documents too. If you absolutely need a linked sketch to be used in Part Design better talk with realthunder I guess, I think he would like to get a comission.
Attachments
subshapebinder-example.FCStd
(11.4 KiB) Downloaded 76 times
realthunder
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

Re: App::link of sketch in PD Body

Post by realthunder »

emills2 wrote: Thu Feb 27, 2020 7:26 am Does an App::link of a sketch not provide the data needed by Part Design Body to use it as a sketch?
I hope you realize that there are many variations of Link. The normal Link overrides the linked object's Placement, which obviously does not work in Part Design use case. The sub Link works to some extent, as it tracks the linked object's placement, or accumulated placement if linked through some hierarchy. However, it does not track its own hierarchy. So if you put a sub link into a body, and the body itself moved, the link will be out of the place, which may be a desirable behavior in some use cases, but apparently not in Part Design. What Part Design wants is to have this cross coordinate system linking capability that can seamlessly transformed the linked object's placement to the link's current coordinate system, in other word, the geometry appeared in 3D view shall stay with the linked object no matter what. That's exactly what 'SubShapeBinder' provides.

It is possible for me to add the cross coordinate linking logic to Link as well, making yet another variation of the Link. The real reason of why I haven't done so is because of sketch editing. Link allows to edit the linked object in-place, which means if Link is allowed, the user can edit the sketch inside the linking body, and he will be tempted to try to include external geometry from the same body, only to find that it won't work, because Sketch cannot handle cross coordinate linking. Do you see the potential mess it can create if Link is allowed now?

What about just disable editing then? Well, if you got a linked sketch that can't be edited, then what's the difference does it make to use the binder instead? You can think of binder as Python import. For now, to reference any geometry outside of the body, you have to import it first. There are many ways to do it, and the best of which is to use SubShapeBinder. It is not a dumb copy. It works just like a Link, and more. For example, there is the 'BindMode' property to let you dynamically switch the linking role, i.e. the link can be the linked, and vise versa. Say you bind to a face, and later on switch the 'BindMode' to 'Detached', then the binder becomes a datum. The original face owner can then be attached to this datum if you want (through another binder if they belong to different bodies).

There is no one really against the idea of using Link in Part Design. It is just complicated to handle it right. In the future, when this 'geometry import' process is more developed, maybe we can make it work automatic and behind the scene. So we can truly edit the sketch in any context, and it'll just auto import the geometry on demand.
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
emills2
Posts: 875
Joined: Tue Apr 28, 2015 11:23 pm

Re: App::link of sketch in PD Body

Post by emills2 »

vocx wrote: Thu Feb 27, 2020 5:52 pm This entire thread sounds like you are having a stroke
I already knew you consider yourself a mind reader, good to know you're a doctor as well.
vocx wrote: Thu Feb 27, 2020 5:52 pm It's not a conspiracy against App Link
I never alleged any conspiracy.

There is a long history behind Part Design, Part Design Next, etc. Going a long way back, there was a design choice to completely isolate each Part Design object from other Part Design object. Even though Part Design Next resolved many issues, to this day, restrictions remain that make data sharing between Part Design bodies very difficult in practice.

App::Link is just one possibility to ease data sharing and avoid duplicate data entry. Glad to know there no objections from the current devs active in Part Design, because in the past, there sure as hell were. And they were entitled to their opinion, and to direct their work the way they saw fit.

As a user i wanted confirmation before i invest myself in a workflow, again, only to find it is intentionally being blocked. no conspiracy here. stated intentions.
Post Reply