Datum entity vs Body
Forum rules
and Helpful information
and Helpful information
IMPORTANT: Please click here and read this first, before asking for help
Also, be nice to others! Read the FreeCAD code of conduct!
Also, be nice to others! Read the FreeCAD code of conduct!
- Pauvres_honteux
- Posts: 728
- Joined: Sun Feb 16, 2014 12:05 am
- Location: Far side of the moon
Datum entity vs Body
Hi, I'm not sure, but I think this might be a feature request?
When inserting/creating a Datum entity the program forces me to put it in a body:
. .
Now I really do not want it to be in a body, at all. Basically because Datum entities does not belong in a container for solids (Datum entities are by definition not solids).
I would like to have Datum entities in a set outside the Body container, with no connection to the Body container (unless someone really, really have a need for it). Anyhow, I do not want to be forced to have the Body container as a basis/parent of any Datum entity.
The basis/parent of a Datum entity shall, in the normal/standard case be the file (*.fcstd)'s [0,0,0] or a user created coordinate system inside mentioned file (we do not have this option yet, but hopefully it can be implemented in the future. In CATIA this is done by creating a Datum point and attaching a User coordinate system to it.)
The collector for Datum entities, and all other surface related stuff, should probably go into the already implemented collector "Grouping":
.
When inserting/creating a Datum entity the program forces me to put it in a body:
. .
Now I really do not want it to be in a body, at all. Basically because Datum entities does not belong in a container for solids (Datum entities are by definition not solids).
I would like to have Datum entities in a set outside the Body container, with no connection to the Body container (unless someone really, really have a need for it). Anyhow, I do not want to be forced to have the Body container as a basis/parent of any Datum entity.
The basis/parent of a Datum entity shall, in the normal/standard case be the file (*.fcstd)'s [0,0,0] or a user created coordinate system inside mentioned file (we do not have this option yet, but hopefully it can be implemented in the future. In CATIA this is done by creating a Datum point and attaching a User coordinate system to it.)
The collector for Datum entities, and all other surface related stuff, should probably go into the already implemented collector "Grouping":
.
Re: Datum entity vs Body
This is simply because datum entities are PartDesign objects, and PartDesign objects can only be created inside a Body container.Pauvres_honteux wrote: ↑Sun May 20, 2018 12:15 pm Basically because Datum entities does not belong in a container for solids (Datum entities are by definition not solids).
This may be a feature request, but this will probably require some discussion, as I think what you want goes against the developer's original intentions. Besides, he mentioned in the past that he was considering allowing other entities in body containers, not only solids. I've been told that he's apparently agreed to support multiple solids inside a single Body. But he's had no time for FreeCAD development in the past year or so, and recently said he didn't have time either for the foreseeable future. AFAIK nobody else is contributing to PartDesign development, apart maybe for realthunder, but he's doing so in his own separate FreeCAD fork...
Re: Datum entity vs Body
Hi @Pauvres_honteux.
We are more or less in a feedback gathering phase ATM. Determining what works and what could improve in the future. I don't expect anything drastic happening soon but just wanted to point out thanks for providing the feedback. We need much more of that before i guess some sense of a strong direction will emerge again.
We are more or less in a feedback gathering phase ATM. Determining what works and what could improve in the future. I don't expect anything drastic happening soon but just wanted to point out thanks for providing the feedback. We need much more of that before i guess some sense of a strong direction will emerge again.
- Pauvres_honteux
- Posts: 728
- Joined: Sun Feb 16, 2014 12:05 am
- Location: Far side of the moon
Re: Datum entity vs Body
Added this to my feature request issue #2686.
Another thing to fix for this to work is the ability to (easy) link from planes, lines and points outside of a body to an extrusion, revolve or anything else solid related inside a body container. Perhaps a separate feature request?
The goal is to have the resulting solid just like that, a solid to be the result of / child of everything else (points, lines, intersections, 3D curves, planes and surfaces).
I get the feeling that the whole parent child relationship is turned upside down now, with the solid as base and surfaces as children.
It shall be the other way around. Everything CAN end in solids, but must always be preceeded by 2D objects (even double curved surfaces are 2D, thickness make objects 3D [confusing ]).
Would this be a ickby / deepsoic question?
When that is done one can easily switch/replace body containers with the work done by DeepSOIC.
And then my friends everything basic is in place for some real production work (granted some kind of assembly of files, not bodies).
Hmm, I feel I'm diverging from the topic. Perhaps I shall continue this in another thread...?
Another thing to fix for this to work is the ability to (easy) link from planes, lines and points outside of a body to an extrusion, revolve or anything else solid related inside a body container. Perhaps a separate feature request?
The goal is to have the resulting solid just like that, a solid to be the result of / child of everything else (points, lines, intersections, 3D curves, planes and surfaces).
I get the feeling that the whole parent child relationship is turned upside down now, with the solid as base and surfaces as children.
It shall be the other way around. Everything CAN end in solids, but must always be preceeded by 2D objects (even double curved surfaces are 2D, thickness make objects 3D [confusing ]).
Would this be a ickby / deepsoic question?
ickby
A humongous leap forward is microelly2's latest work where one now can use ONE sketch as basis for both adjacent and tangent surfaces (standing ovations @microelly2) so now we "only" need to make thickness on/from them and get the solid into the body container.DeepSOIC
When that is done one can easily switch/replace body containers with the work done by DeepSOIC.
And then my friends everything basic is in place for some real production work (granted some kind of assembly of files, not bodies).
Hmm, I feel I'm diverging from the topic. Perhaps I shall continue this in another thread...?
- HarryGeier
- Veteran
- Posts: 1231
- Joined: Mon Jul 10, 2017 12:36 pm
- Location: Hof Germany
Re: Datum entity vs Body
I guess , what you pledge for, is a complete rewrite of FreeCAD , as it is. Literally, you want to go back in time to 0.16 where each construction was one body one its own, and people hat to create very strange constructions like "Helper Pads" ,mix of Part Desing , Part and a divertimento of additional plugins etc and nearly each change at any place in the tree was leading to a broken construction.
Better LEARN how to use FreeCAD and then come back and bring in valuable proposals...
Better LEARN how to use FreeCAD and then come back and bring in valuable proposals...
Kaum macht man´s richtig , gehts´s
My Video Tutorials on Youtube: https://www.youtube.com/channel/UCoe3B ... p8Q/videos
My FreeCAD Stuff on Hidrive: https://my.hidrive.com/share/qr3l1yddy6#$/
My Video Tutorials on Youtube: https://www.youtube.com/channel/UCoe3B ... p8Q/videos
My FreeCAD Stuff on Hidrive: https://my.hidrive.com/share/qr3l1yddy6#$/
- DeepSOIC
- Veteran
- Posts: 7896
- Joined: Fri Aug 29, 2014 12:45 am
- Location: used to be Saint-Petersburg, Russia
Re: Datum entity vs Body
Your quote is not working, it didn't give me a notification...
Getting Datum Planes outside of body as such is rather trivial (even now, you can just drag it out). The problem is, nothing really supports datum planes yet. They are pretty useless outside of PartDesign.
I also noticed that it cannot be edited by double-click if it's outside of a body. But that should be fairly easy to fix.
You can use Part Plane as a replacement of Datum Plane. Not as convenient, as it is trickier to edit its attachment. You can also use Lattice2 Attached Placement for similar applications. Then you can import those into bodies with shapebinders, and PartDesign allows using faces, edges, verties for I believe everything you can use datum planes, lines and points for.
- Pauvres_honteux
- Posts: 728
- Joined: Sun Feb 16, 2014 12:05 am
- Location: Far side of the moon
Re: Datum entity vs Body
About the quote: Bugger!
And a big thank you DeepSOIC for replying!
The nombero uno thing here is that the "datums" are NOT the child of the Body container.
Having the plane as the child of the file/part coordinate system opens up for the illusive exchange of Bodies without breaking things. When all "datums" are not the child of any container one can use ONE point for all stuff, ONE line for all stuff, ONE plane for all stuff and so on.
That is, a few "datums" / curves / surfaces rules the whole part.
And for you who have not understood it yet, one do not move containers, one moves its content. Doing it the other way around gives horrible consequences, as you all have experienced by now.
How to move the content? Move the points, lines, curves, planes and/or surfaces (which shall not have a solid or Body container as parent) and everything follows without breaking!
As for useless "datums" I have a feeling our friend microelly2 is about to breach that wall any time now.
And a big thank you DeepSOIC for replying!
The nombero uno thing here is that the "datums" are NOT the child of the Body container.
Having the plane as the child of the file/part coordinate system opens up for the illusive exchange of Bodies without breaking things. When all "datums" are not the child of any container one can use ONE point for all stuff, ONE line for all stuff, ONE plane for all stuff and so on.
That is, a few "datums" / curves / surfaces rules the whole part.
And for you who have not understood it yet, one do not move containers, one moves its content. Doing it the other way around gives horrible consequences, as you all have experienced by now.
How to move the content? Move the points, lines, curves, planes and/or surfaces (which shall not have a solid or Body container as parent) and everything follows without breaking!
As for useless "datums" I have a feeling our friend microelly2 is about to breach that wall any time now.
Re: Datum entity vs Body
The trick is not to put the user between the quote tags, but in the start tag:
Code: Select all
[quote=Pauvres_honteux]put anything here[/quote]
Code: Select all
[quote]Pauvres_honteux[/quote]
You can draw sketches on them which can be extruded.Getting Datum Planes outside of body as such is rather trivial (even now, you can just drag it out). The problem is, nothing really supports datum planes yet. They are pretty useless outside of PartDesign.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
- Pauvres_honteux
- Posts: 728
- Joined: Sun Feb 16, 2014 12:05 am
- Location: Far side of the moon
- DeepSOIC
- Veteran
- Posts: 7896
- Joined: Fri Aug 29, 2014 12:45 am
- Location: used to be Saint-Petersburg, Russia
Re: Datum entity vs Body
This cannot work right now. It requires reprogramming of just about every feature of FreeCAD to support this kind of movement. Consider this:Pauvres_honteux wrote: ↑Wed Jul 18, 2018 8:39 pm And for you who have not understood it yet, one do not move containers, one moves its content. Doing it the other way around gives horrible consequences, as you all have experienced by now.
How to move the content? Move the points, lines, curves, planes and/or surfaces (which shall not have a solid or Body container as parent) and everything follows without breaking!
Part contains Part Extrude of a Sketch.
You move Part, that in effect moves Sketch and Extrude. But you can independently move only the Sketch, or only the Extrude to achieve the correct net movement. Moving both results in double the overall movement.
A result of such reprogramming will be a total loss of ability to recompute projects made in older versions. In every workbench, most likely.