Wall Placement should be necessarily relative to walltrace placement?

[yorik]

That is how most FreeCAD objects work... But there are pretty complex things regarding placements in FreeCAD (ex. app parts), maybe what we need here is better documenting?

[carlopav]

That is how most FreeCAD objects work... But there are pretty complex things regarding placements in FreeCAD (ex. app parts), maybe what we need here is better documenting?

Documentation is always good, my concern was to find a good way to solve all the problems we have with wall, its base and window when trying to move them with draft modifiers, and to semplify the general approach...

[yorik]

Yeah, let's brain storm, of course, it's always the best thing to do.

It's a complex dependency problem... I'm not sure the "Move base" property we added is not making things worse actually.

Maybe walls need to have their inner base shape removed completely and become implicit? However this seems a step back to me, in terms of power.

Really no good idea here...

[carlopav]

Yeah, let's brain storm, of course, it's always the best thing to do.

Maybe walls need to have their inner base shape removed completely and become implicit? However this seems a step back to me, in terms of power.

I agree, the explicit base shape is something really FreeCADish, really honest, and since i got used to it I just love it. The problem is mainly that we never know what to move: if we move the wall, the base is no more in place, if we move the base the wall doesn't know that it's been moved. (is it?)

Probably if we fix draft modifiers everything will be ok, but i don't like that so much: if we use a modifier of another wb, the things will mess up instantly (is it?). I'd prefer instead that draft modifiers are applied right to the wall, and the wall itself knows how to handle the transformation. But trying to implement it (I experimented a bit with placement propagation for windows and it works fine), i stopped at a circular dependency: if the wall moves the base, then the wall is moved! That's the point of this topic.

Then I discovered that @paulee proposed to attach windows sketch to the base, and not to the wall. That's another interesting thing. We then will just have to move the base if we want to move the wall (but two walls can have the same base, and we maybe just want to move one of them, with its windows).

I think we now have another weapon: App::Link. We could link a base object, so its placement could always be in place with the wall, and what is linked is just the shape, not the placement. (It could be used whenever a wall is created from a preselected object, instead a wall by two points will remain walltrace based).

Quite a lot of confusions as you can see...

[yorik]

Yes.

One concept I feel is important: The way we design the internal workings of the object, should not necessarily be the way user interface with the object. Ex, we can keep the internal base object, but users should be able to manipulate it as if there wasn't.

Ideally new users should be able to not see that a wall has no underlying baseline and still work well with it. Then, you discover and possibilities grow...

The underlying shape and the respective placements are indeed a problem when moving objects. But there is a fundamental impossible question:

If two walls are based on a same baseline, or, maybe a much better case: Two columns on a same profile.

If we want the profile to move together with the column, we have a problem.

Still not sure how to solve this either...

About app links, yeah, we must DEFINITELY play with that more.

[paullee]

If two walls are based on a same baseline, or, maybe a much better case: Two columns on a same profile.

If we want the profile to move together with the column, we have a problem.

Arch Structure
For a column/Arch Structure with a profile, IMO the column should not move when the profile move.

This can be done with similar concept as Transform in Link.

Arch Wall
For a basline for Wall, IMO there are options:

1. As Wall currently behaves, Wall just follow base: Fine for most scenario, if Wall do no move away from its base, no much confusion
2. As @carlopav prefer, Wall should not move when base move:
   • This can be done likewise with concept of Transform in Link as above
   • The Wall can still 'follow' the Base if Wall has Attachment capability, and just MapMode to the Base's origin - for advance user only, as probably more confusion

[carlopav]

Thanks both for the response...

So, if we assume that the wall should not necessairly be in place with its base, everything could be simpler for new created walls from 2 points (default command behaviour):
- WallTrace could be created parallel to x Axis, so also at the moment of the creation it is not in place with the wall (so this dont generate confusion), and the wall placement could be determined "entirely" by the wall placement;
- Children position could be relative to the wall (mapping the sketch to the wall faces, since topology is quite stable), or wall Placement can easily be propagated to children onChanged;
- MoveBase property could be no more necessary;
- Draft Edit could calcolate the position of editpoints to match the wall and edit the base sketch;
- Also wall could have a special Tracker to show the baseline in place eventually if needed;
- We could also have a special method inside the wall object to return the position of the base in place to the wall (kinda getWallBaseLine());
- I was experimenting a JoinEnd, JoinStart Property: Is a string with the name of another wall. The WallTrace is modified so the subelement is extended or trimmed to the baseline of the other wall. The meaning is not to affect placement, but just the inner sketch geometry, so if the wall is trimmed or extended, children stay in place. If two walls are circular referenced, it means we have a corner joint, else we have a T joint. The loop can be prevented if the intersection point is coincident with the current endpoint/startpoint position I think.

A different behaviour could be thought for the wall with a preselected object...
here I'd like to find the time to experiment with link:
-if the wall Base is a link to the base object, moving the base should not result in moving the wall.

@paulee do you need to keep the wall in position with its base, for ArchSketch based walls, is it? Instead you have to attach windows sketches to the wall itself, and this will be subject to toponaming. is it?

[paullee]

Seem complicated mechanism This should be hidden away from general user.

BTW, i once ask for the feature the an object (base of Wall in this case) be hidden from the document tree.

@paulee do you need to keep the wall in position with its base, for ArchSketch based walls, is it? Instead you have to attach windows sketches to the wall itself, and this will be subject to toponaming. is it?

Not sure I am following you... I haven't implemented this in the 'ArchSketch' ... (While you are thinking about using Link to achieve the desirable result, I had used Clone of Wall to mimic similar behaviour)

And I avoided mapping Sketch to face of Wall - have potential toponaming problem.

In my experiment, I can 'attach' to an edge of the sketch - i.e. how the Door move when the Base Sketch for a Wall have the dimensions constraints edited.

Maybe we wait a little while to see the result you achieve later.

[Roy_043]

As paullee mentioned: walls typically do suffer from topological problems. Every window, addition or subtraction will change the number of faces.

[carlopav]

I confess I did just a couple of test, but face 1, in single segment based wall, seems to remain quite stable...
Anyway placement propagation seems a better option to me for this kind of wall...