App::Part question
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
App::Part question
What is the reason to keep Part around in the PartDesign WB? It seems to be pure assembly abstraction, isn't it?
Are there any reasons but just to have associated origin for a body?
Are there any reasons but just to have associated origin for a body?
Re: App::Part question
It is a abstraction for assembly, yes. It needs something non Workbench specific to work with. So alone for the fact that your creation should be easily to use in assembly it is worth keeping the body in a part (this means for moving via constraints and making reference copies). Another point are the local coordinate systems. When allowing to use the origin axis/planes in body features you need to ensure that the body is always aligned to the origin. If not, moving the body would change its shape, as the origin stays and all features get recalculated. So you have two choices: giving any body a own local coordinate system or aligning the body with an external origin so that they always move together. We then decided to go with the external alignment in the part, as this is less cluttered and in the assembly context also more consistant.
Re: App::Part question
Hmm... the problem is that the part should be able to handle any object (not just PartDesign's), isn't it(?)... Unless it's so it seems to be incomplete...
In that case for consistency all workbenches should be Part-aware, the only sane way for that I see is to add all new objects to the current part, which may be undesired in several cases I suspect...
I see the arguments for keep origins inside a part but not in a body... may be it could be resolved by the proposal in neighboring thread if that one work out...
In that case for consistency all workbenches should be Part-aware, the only sane way for that I see is to add all new objects to the current part, which may be undesired in several cases I suspect...
I see the arguments for keep origins inside a part but not in a body... may be it could be resolved by the proposal in neighboring thread if that one work out...
Re: App::Part question
Yes, but it can do that. Why shouldn't it work likel that in the current configuration? I already ported Part workbench to add everything to the active Part. Other workbenches like draft or arch can decide for themself if they prefer adding stuff to the active part or not. It may be not desired for every workbench, arch for example, but they can also derive a new document group type and make some ActiveArchitecture" object, or stay at document level. Depends on their preferences.Hmm... the problem is that the part should be able to handle any object (not just PartDesign's), isn't it(?)... Unless it's so it seems to be incomplete...
But currently it is not in a body but in the part. I do not see the problem right now, what is the issue with the current desing? A Part has a local coordinate system, one can use that (like PartDesign) or not and then add everything to the document space global coordinate system if wanted.I see the arguments for keep origins inside a part but not in a body... may be it could be resolved by the proposal in neighboring thread if that one work out...
Re: App::Part question
I have in mind a bit different workflow: user designs everything in the global space, and when he needs assembly or when he just want to structure the work he adds parts... May be I'm wrong here and it's not very good idea...ickby wrote:But currently it is not in a body but in the part. I do not see the problem right now, what is the issue with the current desing? A Part has a local coordinate system, one can use that (like PartDesign) or not and then add everything to the document space global coordinate system if wanted.
But the main Idea is that I'd love to see bodies movable... The lack of current design is that it's impossible to align bodies designed in the origin for boolean operations...
Re: App::Part question
But this would also be impossible if the bodies would be in the global coordinate system. As a body uses the coordinate system in his features it must always stay fixed to the used coordinate system. So the only way to make the body movable is to give a body a own local coordinate system. But this is also not trival, as then you need to make every tool aware of bodies and that they have a local coordinate system. For example booleans need to take the tip shape AND the body placement into account, and that in a different way than for normal Part::Feature's.But the main Idea is that I'd love to see bodies movable... The lack of current design is that it's impossible to align bodies designed in the origin for boolean operations...
For your use case, the alinging of bodies, one can think of adding a "Transform Feature" which moves the bodies shape within the local coordinate system. This would work like any other part design features by getting added in the body like everything else and which does nothing but transforming the shape.
Re: App::Part question
I don't really see a problem here... In my branch the body is a normal Part::Feature object with all the stuff...ickby wrote:But this is also not trival, as then you need to make every tool aware of bodies and that they have a local coordinate system. For example booleans need to take the tip shape AND the body placement into account, and that in a different way than for normal Part::Feature's.
The non trivial thing to do is to get rid of gazillion plane/axis objects and to draw all the stuff properly in the 3dView...
PS, I've just tried to move a body around inside a Cut with RigtClick->Transform and it worked just smooth =)
PPS, I haven't pushed some recent changes yet, so the github's version is a bit out of date.
Re: App::Part question
and then you edit a feature and wonder why the hell the rotational pattern does not rotate around the choosen axis anymore I do not have a working copy at hand rirght now, so can't check this.PS, I've just tried to move a body around inside a Cut with RigtClick->Transform and it worked just smooth =)
Re: App::Part question
Ah I see, I forgot that you do not use the tip shape but have a own shape for the body. But then, when you are moving the body, the features do not move, right? Does this than not imply that the cutout is at a different position than the body visalisation? Not sure, again I do not have a working copy at hand.I don't really see a problem here... In my branch the body is a normal Part::Feature object with all the stuff...
Re: App::Part question
They does! All bodies sub objects are displayed right there they supposed to be... I suppose it's due to ViewProviderBody::claimChildren3d(), I don't know how it works inside, but it does... The only regression I noticed so far is that on a sketch edit the view settled to be to the original sketch plane, but the sketch itself is drawn in the correct plane, so it's quite minor thing...ickby wrote: Ah I see, I forgot that you do not use the tip shape but have a own shape for the body. But then, when you are moving the body, the features do not move, right? Does this than not imply that the cutout is at a different position than the body visalisation? Not sure, again I do not have a working copy at hand.
Just tried: as far as axis is base axis or a datum in the body everything is fine... Heven't yet tried what will happen if user will rotate around an external axis, but it seems not possible yet and it's user's problem IMHO...ickby wrote:and then you edit a feature and wonder why the hell the rotational pattern does not rotate around the choosen axis anymore I do not have a working copy at hand rirght now, so can't check this.
Last edited by Fat-Zer on Mon Aug 17, 2015 12:18 pm, edited 1 time in total.