App::Part question

Discussion about the development of the Assembly workbench.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Fat-Zer
Posts: 176
Joined: Thu Oct 30, 2014 10:38 pm

App::Part question

Post by Fat-Zer »

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?
ickby
Veteran
Posts: 3116
Joined: Wed Oct 05, 2011 7:36 am

Re: App::Part question

Post by ickby »

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.
Fat-Zer
Posts: 176
Joined: Thu Oct 30, 2014 10:38 pm

Re: App::Part question

Post by Fat-Zer »

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...
ickby
Veteran
Posts: 3116
Joined: Wed Oct 05, 2011 7:36 am

Re: App::Part question

Post by ickby »

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...
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.
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...
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.
Fat-Zer
Posts: 176
Joined: Thu Oct 30, 2014 10:38 pm

Re: App::Part question

Post by Fat-Zer »

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.
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...

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...
ickby
Veteran
Posts: 3116
Joined: Wed Oct 05, 2011 7:36 am

Re: App::Part question

Post by ickby »

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...
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.

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.
Fat-Zer
Posts: 176
Joined: Thu Oct 30, 2014 10:38 pm

Re: App::Part question

Post by Fat-Zer »

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.
I don't really see a problem here... In my branch the body is a normal Part::Feature object with all the stuff...
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.
ickby
Veteran
Posts: 3116
Joined: Wed Oct 05, 2011 7:36 am

Re: App::Part question

Post by ickby »

PS, I've just tried to move a body around inside a Cut with RigtClick->Transform and it worked just smooth =)
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.
ickby
Veteran
Posts: 3116
Joined: Wed Oct 05, 2011 7:36 am

Re: App::Part question

Post by ickby »

I don't really see a problem here... In my branch the body is a normal Part::Feature object with all the stuff...
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.
Fat-Zer
Posts: 176
Joined: Thu Oct 30, 2014 10:38 pm

Re: App::Part question

Post by Fat-Zer »

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.
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: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.
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...
Last edited by Fat-Zer on Mon Aug 17, 2015 12:18 pm, edited 1 time in total.
Post Reply