Discussion on placement

[drmacro]

I'm going start a new thread because this thread got hijacked when I started talking about the placement of objects on a grander scope than the OP:
https://forum.freecadweb.org/viewtopic.php?f=3&t=59212

In the other thread I gave a rather detailed example of moving a step file back to the global origin.

The whole movement conundrum often occurs when the user wants to use a import format such as STEP or STL.
(I must say the concept of moving the origin of a solid in FreeCAD always appears confusing and even a real hassle to new users...even to some old hands.)

So, if a step file is imported and Edit>Placement is selected the Placement dialog will show the Translation: X,Y,Z values. By setting these to 0.0, the component is moved to global origin. (This is a generalized statement and what I've seen with step files...there maybe step files where this is not the case...)

For some reason it is more of a pain with STL files. many (maybe all) stl files. When they are imported, they are assumed at the global origin (as can be seen in the Placement dialog (i.e. Translation: X,Y,Z values are 0.0). I think this is because the mesh coordinates in an STL file are absolute and the file format provides no information for a transform mechanism. It really is a "dumb", really simple, format.

When asked It is typically recommended to look at some value of the mesh when hovered over with the cursor, note those values, and use their inverse values in the Placement dialog.

This is rather clumsy and to a new user (especially someone new coming from something like 3dMax, etc.) seems rather laborious for a modern CAD tool.

Note: the FC_Info macro will provide the coordinates of the center of mass of the imported mesh object. The inverse of these values can be used in the Placement dialog for great accuracy. (Has someone like (maybe @mario?) written a Python script to move an object from it's center of mass to the global origin? If no one knows of such a beast, I'll have a go at it tomorrow...)
Edit: subsequent testing of the FC_Info macro says the mesh has to be converted to a shape and subsequently a solid. The mesh object is not a Shape object therefore has no COM property... Interestingly, the COM of the component after conversion to Shape and the solid after conversion from Shape to Solid, have slightly different COM values...hmm.

So, the gist of this stream of consciousness is that maybe some documentation, tips&tricks, and some tools sort of thing would really add a polish to FC...
I'm happy to collect the info and make a wiki page...

[chrisb]

(Has someone like (maybe @mario?) written a Python script to move an object from it's center of mass to the global origin? If no one knows of such a beast, I'll have a go at it tomorrow...)

If I may add something to the wish list (sorry for not only being unable to contribute, but even asking for more): I would like to see the center of mass or an arbitrary point of the object to become the new origin. Perhaps it would even be possible to select circles or arcs and move their center to zero.

The reason for this is: I can well imagine some machine part where I want to have e.g. a shaft or similar which I want to center.

[drmacro]

I think Manipulator workbench can do the circle centering. Emphasis on the "think"

But, it should be possible to move the component to origin via a vertex or the center of mass.

[edwilliams16]

If I may add something to the wish list (sorry for not only being unable to contribute, but even asking for more): I would like to see the center of mass or an arbitrary point of the object to become the new origin. Perhaps it would even be possible to select circles or arcs and move their center to zero.

The reason for this is: I can well imagine some machine part where I want to have e.g. a shaft or similar which I want to center.

This is easy enough if

• The imported object is at the root level of the document, so you don't have to deal with local vs. global coordinates.

• You only need to translate the object. ( No rotation involved)

• You can pick a vertex, or perhaps an arc to determine a center, to move to the origin.

But isn't this the province of all these assembly workbenches? Although I have little to no experience with them.

[chrisb]

Manipulator can do it, and it is not really difficult to move something under the conditions listed. But it would be ven easier if I have just one import helper tool doing all this, with non root objects included.

[zardozer]

But isn't this the province of all these assembly workbenches? Although I have little to no experience with them.

I don't think it's just for assemblies. There are many times as outlined above where you're just importing a single step part or stl for editing, and it's nowhere near the origin. If you'd like to use Part Design and make it a basefeature, you have to manually move it within the body to get it to where you want in relation to the body's origin. Basically, it just makes it easier to edit if it's centered around the origin (and where it's best "centered" of course is totally dependent on the geometry of the part).

[edwilliams16]

In a PM @drmacro was interested in imported stls. I enclose a file for definiteness in the discussion. I created a pointy object, displaced from the origin, with the pointy end located at (10,0,0), exported as stl and imported into the enclosed. It was converted to shape then solid and made the BaseFeature of a Part Design Body. The pointy end is located at (10,0,0) even if the placement of stl_import001 is modified prior to including in the body.

The BaseFeature has no Placement exposed in the properties view, but it is accessible to a script. For instance

Code: Select all

doc= App.ActiveDocument
bf = doc.getObject('BaseFeature')
bf.Placement.move(App.Vector(-10, 0 ,0))
doc.recompute()

translates the pointy end to the local (of Body) and global (since Body has the Identity placement) origins. Or:

Code: Select all

doc= App.ActiveDocument
bf = doc.getObject('BaseFeature')
bf.Placement.move(-bf.Shape.CenterOfMass)
doc.recompute()
 

moves the CG of the object to the origins.

To avoid having to use scripting, a possible alternative is to set the placement of the Body within the Part container. The Body would then have its origin and orientation within the Part wherever you wish.

Screen Shot 2021-06-09 at 11.47.56 AM.png (15.52 KiB) Viewed 3192 times

It might be good to expose the Placement of the BaseFeature, but there may be complications I have not encountered in this minimal exploration.

[drmacro]

In fact I actually produced a script to do this (I stared at your sandbox write up long enough...)

I see things happen in the code and things get moved...but (you knew it was coming and that's why I was trying to limit the boring back and forth planning to summarize for others, but I guess you don't like that. )

(playing new user, devil's advocate): Why, if I set the placement of the solid, created from an stl, does it not forget that it was every at another location? If I wanted it there I'd have left it there. Once it is moved it is no longer there, it is now here. Why would FreeCAD assume to know better? that when I put it into a container, it thinks I want it where I already moved it from.

[edwilliams16]

Why would FreeCAD assume to know better? that when I put it into a container, it thinks I want it where I already moved it from.

It is at least consistent. If I make a part Cube, translate it somewhere, then make it the BaseFeature of a Body, the cube's translation is ignored.
Choosing whether or not to include the immediate container's placement when creating a BaseFeature seems a legitimate choice. I can live with the consistent one of not including it.
As I said above, barring unknown hazards, exposing the BaseFeature's Placement looks to be a clean way to handle doing something else via the Properties panel.

Choosing a vertex and moving it to the origin using the BaseFeature's Placement is a simple (algorithmically at least) macro. You've probably written one too. Reorienting, not just translating, the BaseFeature through the Gui (picking axes etc.) would be much more complicated, and hard to understand.

[zardozer]

As I said above, barring unknown hazards, exposing the BaseFeature's Placement looks to be a clean way to handle doing something else via the Properties panel.

Choosing a vertex and moving it to the origin using the BaseFeature's Placement is a simple (algorithmically at least) macro. You've probably written one too. Reorienting, not just translating, the BaseFeature through the Gui (picking axes etc.) would be much more complicated, and hard to understand.

Btw, you can expose Placement on a basefeature in a body. You have to right-click on the properties panel and select 'show all'. Why it's not exposed by default, I'm not sure. This is actually how I've gotten around to placing the basefeature inside a body. If it's an imported step, I transform it first and place it where I want it. Then I make a basefeature and copy and paste those numbers for placement. It's super clunky but I guess 'works.'

The main issue with this is that step files (and by extension stl meshes that have been converted to solids) often can't be centered on origins easily. You have to usually move them roughly, then bit-by-bit, and then use decimal places for placement to get them precisely where you want them.

Personally, if it gave me the gui to let me pick where to move the origin, I would like that. If you have an object that looks like a wheel for example, I'd love to be able to select the circle and then place the origin's location in the center with 'concentric'. Sometimes you want origin at center of gravity, sometimes you wanted them centered on some other feature, etc.