Open kaiwas opened 1 month ago
I don't know if I'm doing the test correctly, but if different wall segments have different alignment and different offsets, the windows and doors that are placed are positioned in an incomprehensible way. I tried changing the properties of windows and doors, but the result is always unusual.
I assume that the problem is precisely in the offset (it seems that it is not taken into account if !=0).
Indeed, it seems Offset per edge is not honored, need to have a deeper look at code if this and other relevant properties are considered :)
But it seems to me that if you are creating a few Wall as layer, you should at least have 1 Wall without Offset, and let Window/Door to attach to it; or you should simply adjust the Sketch layout or otherwise the Sketch layout would be 'too off' from the Wall and it would be difficult for other to understand the logic of modelling. Maybe you would find this approach much simpler.
Maybe you would find this approach much simpler.
Yes. I really complicated the logic of construction in this example. But we can't know in advance which method will come to the user's mind )
In general, it is much more important to me that different wall widths are taken into account when installing windows and doors, because in the same house there may be walls with different widths. And alignment is a really specific factor (not so important, I guess).
Tomorrow I will test SketchArch on this topic.
It seems to me that the placement of objects is very broken. On the horizontal part, the offset does not work at all. (update. I apologize. It works. I just forgot to use the placement tool. and simply inserted a window without specifying the sketch edges). On the vertical part, it works, but it seems to me that the sign is mixed up. (update. After placing the window on the horizontal part, the offset works. But the sign is still mixed up) Demonstration on video.
https://github.com/user-attachments/assets/b72e3688-1f5a-40fd-994f-5a80f76adc4c
The file is attached. Remove the zip extension. Placement_object_2.FCStd.zip
I have a proposal for the placement of windows and doors inside the walls. I will make a proposal and post it in this topic a little later.
Thanks for testing.
'Window' has correctly been assigned an edge / wall segment to attach to. You can verify this by checking 'show hidden' in the property and panel, find the 'Master Sketch Subelement Tag' and you see some hex figure.
'Window002' has not been assigned with an edge / wall segment to attach to. There is nothing in the same property. Whenever you find the ArchObject is not following the target edge / wall segment, even when the Host is correctly assigned, just click the Edit Attachment tool and pick the target edge, and it is done.
Edit Attachment tool and pick the target edge, and it is done.
Yes. I've already guessed where I made a mistake. By the way, in this regard, I have a suggestion - why not automatically assign the first segment to the window in the sketch (at the time of installation). I have already encountered such incomprehensible behavior several times and could not understand what was happening. All the same, without assigning the desired segment, the placement does not work - so let it be the first segment right away. It will not be worse.
Here is another example. If I build a wall a little to the side - then the window that is added to the wall appears in zero coordinates until I place it using the tool. If it were immediately tied to the first segment - such a problem would not arise.
https://github.com/user-attachments/assets/d549ff29-8c37-4a36-b3a5-19c84650a26f
I am formalizing the logic for placing windows and doors (I need to do it so that it is clear what I mean. It is not easy)
By the way, in this regard, I have a suggestion - why not automatically assign the first segment to the window in the sketch (at the time of installation). I have already encountered such incomprehensible behavior several times and could not understand what was happening. All the same, without assigning the desired segment, the placement does not work - so let it be the first segment right away. It will not be worse.
Here is another example. If I build a wall a little to the side - then the window that is added to the wall appears in zero coordinates until I place it using the tool. If it were immediately tied to the first segment - such a problem would not arise. vokoscreenNG-2024-10-15_16-50-12.mp4
There is a 'Auto Include in Host Object' in the Window tool, that's why it is included in the Wall.
And yes, I could make the Window tool automatically assign the first segment if the above option is selected. Back in earlier days of the SketchArch development, I try to avoid intervening too much the Arch/BIM tools and those were not priority before the ideas in SketchArch proved workable.
I am formalizing the logic for placing windows and doors (I need to do it so that it is clear what I mean. It is not easy)
And too little time to do documentation, see the forum discussion, SketchArch Addon - Intuitive Automatic Windows/Doors + Equipment Placement, it is almost the development history and document illustrating how tools works and behaves. Hope there is more help available on the development :)
@paullee0 If I understood correctly, then in SketchARCH in the object settings WallLeft and Wallright are responsible for binding the object relative to the wall, taking into account the width and offset.
I'll start with the fact that when changing wallleft to wallright, our window turns out, while the starting point remains unchanged. This is confusing. Demonstration on video.
https://github.com/user-attachments/assets/08554243-fe1c-47ef-be09-5857fc184a06
So. I got approximately such an algorithm. But I intentionally simplified it for a wall of one layer. If there are more layers, you will probably have to bind to the outer one.
Perhaps I could have made a mistake with the signs somewhere. But in any case, now I do not understand what is happening with the windows and doors. They behave unpredictably and the result is very different from what was expected. As if everything is turned inside out.
before the ideas in SketchArch proved workable
You have great ideas! It's just not clear yet how to use all this. Perhaps this is why few people use SketchArch. And it's not about the documentation. Probably, it is necessary to develop algorithms that will be understood without unnecessary explanations.. We just need to figure out how to provide for "stability". If my criticism (advice) will be useful in this - then it is good. However, I can also make mistakes.
You've probably seen how windows work in ArchiCAD. I didn't have to study any documentation to understand how they work. Everything is clear from the icons. I don't even have to go to the window settings. Demonstration on video. Ideally, everything should happen just as easily in SketchArch. Demonstration on video. I change the wall binding and its offset and nothing falls out.
https://github.com/user-attachments/assets/9b45b646-ea01-4485-8544-ab886836db91
https://github.com/user-attachments/assets/4d626ec6-97ac-4e44-a736-8cb878bdae95
I haven't opened ArchiCAD for over 15 years. But when I did, I immediately easily remembered how everything is done.
😁i can see that you haven't opened it over 15yrs, since that's an old Archicad. But i'm just following this thread as it is an interesting development that @paullee0 is implementing. Keep on the good work.
@paullee0 If I understood correctly, then in SketchARCH in the object settings WallLeft and Wallright are responsible for binding the object relative to the wall, taking into account the width and offset.
I'll start with the fact that when changing wallleft to wallright, our window turns out, while the starting point remains unchanged. This is confusing. Demonstration on video.
Correct, the behaviour and convention of Wall Left / Right was a result of discussion in the forum thread :)
You may note the Window / the underlying Sketch has an 'origin' (something like Insertion Point in AutoCad), and then Left and Right just align to the Wall 'Axis' / the Sketch Edges, and Wall Left / Right should take into account of the Width of Wall.
Have a look at the diagrams / youtube below originally contained in the thread. (? anyway to 'embed' youtube video here?)
https://forum.freecad.org/download/file.php?style=4&id=191612
OK, about your diagrams, quick response
EDIT - need a closer look at the diagrams later.
BTW, there is a Property that, without altering the Window's Sketch, change the 'default' 'origin / insertion point'.
EDIT EDIT - It really seem you just have the opposite orientation - Wall Left and Wall Right e.g. for Wall Left, the 'working plane' (window sketch) should goes to the 'Left' side of the Wall. And I set the normal of the window to (0,0,0) to set it automatic - it is another whole discussion for this property.
Use a trapezoid window as I did in the Youtube / diagram and you will find the orientation more easily. Better still, I attached the XYZ object to the window so it immediately show you when window moves.
You've probably seen how windows work in ArchiCAD. I didn't have to study any documentation to understand how they work. Everything is clear from the icons. I don't even have to go to the window settings. Demonstration on video. Ideally, everything should happen just as easily in SketchArch. Demonstration on video. I change the wall binding and its offset and nothing falls out.
Really intuitive for architectural practitioner point of view :) Totally agreeable.
Good on them as it seems they have a bunch of programmers as well as ones who understand how Architect works.
The 'problem' in opensource is there is very scarce people who like Yorik are both serious advanced programmer and Architect, Roy_043 is probably another one ... just a Python beginner for me, time is limited, GUI is the weakest (but there are peoples who helped, like earlier 'escape' problem) ... so bear with it at the moment, probably more help is needed here on GUI/XI :D
Nevertheless, your studies here, diagrams and comments are excellent. The diagrams should goes to the Forum thread.
In the meantime, I would fix the probable bug with offset and align (per edge) here first.
And I think, one of the 'feature' with a large portion of time invested here for example (save the poor GUI/XI) is SketchArch is Toponaming-Tolerant. Readme in github here has a summary of the concepts / features.
Otherwise, it is frustrating if we try to make the model parametric.
The 'problem' in opensource is there is very scarce people who like Yorik are both serious advanced programmer and Architect, Roy_043 is probably another one ... just a Python beginner for me, time is limited, GUI is the weakest (but there are peoples who helped, like earlier 'escape' problem) ... so bear with it at the moment, probably more help is needed here on GUI/XI :D
Oh. I can be patient for as long as I want, and in general, if nothing works out, I won't be upset. In general, I already have everything I need for work. And FreeCAD is more of a hobby at the moment. As for you. I know that you do sketchchart out of "sport interest" and for fun. And I have no complaints if suddenly something is not implemented or does not work correctly. In any case, you have already done a good job. This is impressive.
Regarding the small number of developers. I know. But maybe if we manage to collect a "stable" base - this will interest new (still unknown to us) developers, so that they would join the development of FreeCAD.
EDIT - need a closer look at the diagrams later.
BTW, there is a Property that, without altering the Window's Sketch, change the 'default' 'origin / insertion point'.
EDIT EDIT - It really seem you just have the opposite orientation - Wall Left and Wall Right e.g. for Wall Left, the 'working plane' (window sketch) should goes to the 'Left' side of the Wall. And I set the normal of the window to (0,0,0) to set it automatic - it is another whole discussion for this property.
I expressed my idea as I understood it. I have seen your guides, but it is still better to experiment on some small task. There is also the difficulty of the language barrier. Some things have to be studied independently, because the translation or abbreviations are a bit unclear and there are no icons.
Perhaps some actions should occur automatically. For example, when changing wallelft to wallright, it would be possible to automatically activate a 180 degree flip. Thanks to this, the window itself would not shift along the wall. (And yes - I know about the feature of the window origin)
If we describe the situation briefly, the expected result when changing wallright to wallleft is when the window face binding changes, but the window itself remains in its original place. I don't know how to implement this and how difficult it is to do. But when the window "sticks out" from the wall, it looks strange.
I change the binding to gif, but it seems it is not taken into account, just as the width is not taken into account (window offset = 0). The window position is correct only with Align Wall Center.
OK, checked the code, about parametric placement :
Thanks for reporting.
OK, updated https://github.com/paullee0/FreeCAD_SketchArch for below at the moment
2. Parametric Placement : Align Per Edge Support exposed
Great! This works much better. I'm impressed! But in the case of Walleft it is placed outside by 150 mm. (the thickness of the window frame). Because the window had to be flipped. Can this be taken into account somehow automatically?
Or, as an option (without flipping), additionally shift the window coordinate by its width.
But even if it is impossible to do this - the algorithm looks much more predictable.A little more and it will be almost like in ArchiCAD! :)
If necessary, I can think about what should happen when changing Wallleft to Wallright, so that the user does not have to enter any changes and so that the window is located in the right place. Probably, it will be necessary to change some signs from plus to minus at the software level (invisible to the user)
Note there is another factor in the equation - set the Window Normal to (0,0,0) to make it auto. Maybe this should be automated (like default attach to 1st edge).
Try move 1st or 2nd vertex and make your edge / wall segment inclined. The window placement should follow automatically & parametrically with SketchArch support. Now you may note the window be extruded in awkward direction, following hard-coded normal window creation tool provided - then you need (0,0,0) Auto in the Normal. And with this set (the window should be flush with wall face (if there is no other offset in window parts setup).
then you need (0,0,0) Auto in the Normal.
Yes. If you reset the normal it becomes better. Very good! But i still have to do additional window shifting taking into account its width. (We are already close) It would be great if this happened automatically. The user sees zero (or enters their own number/expressions), but somewhere inside the window offset is added to the window width.
https://github.com/user-attachments/assets/c8e57eb9-4c67-45f6-9544-45bfb1666e39
It looks like there's very little left. Approximately this sequence.
Normal 0.0.0
If WallRight then: AttachmentAlignmentOffset = + (userdata) MSSOffset = window.width_auto + (userdata)
If WallLeft then: AttachmentAlignmentOffset = - (userdata) MSSOffset = (userdata)
https://github.com/user-attachments/assets/728b2c0f-c305-423b-990b-c27aab732eaa
This is a simplified version, since it does not take into account other master sketch settings (I mean the beginning or end of the sketch and other values 1/2, 1/4 and others). But the main thing is to develop a principle.
You can't see it, but I'm dancing on a chair! It looks like we'll soon have predictable windows and doors built into the wall
Try rotate the wall and you may have more fun :)
And try with Opening 100% in your Door / Window, you may understand why Wall Left and Wall Right behaves as it is.
This is related e.g. to defining 'inside' / 'outside' etc. and pave way for more analysis or automation.
Try rotate the wall and you may have more fun :)
And try with Opening 100% in your Door / Window, you may understand why Wall Left and Wall Right behaves as it is.
This is related e.g. to defining 'inside' / 'outside' etc. and pave way for more analysis or automation.
Oh yeah! This is really an inconvenient moment )
But there must be a solution. If you don't use rotation - then you can somehow use offsets. For example, taking into account the thickness of the frame. You just need to think carefully about what to do.
If you choose the lesser of two evils - then I would choose to fix the window position. And openings and rotations are used less often. In addition, you can always change the settings of the window or door.
When windows and doors fall out of the wall, it's more frightening than when they open incorrectly. I haven't been able to get used to this for a whole year )))
We need a brainstorming session. I'll think about these relationships.
To simplify and avoid confusion - perhaps you should create two different tools. One will place windows and doors (or other objects) relative to the wall. And the second will use a different approach and place everything else (as it is now)
In any case, when changing Wallleft to Wallright, we have to manipulate the parameters manually so that the window remains in the same place. There must be a way to automate this. All the parameters that change can be calculated. They just need to be made "invisible" to the user.
Essentially, I change the offsets for the frame thickness and the window width. If this happened automatically, we would just have to change the opening direction.
https://github.com/user-attachments/assets/476936de-11dd-4c5b-89c3-6d52db5497b8
Maybe I showcase with your model ...
Maybe I showcase with your model ...
Yes. Here she is. (delete .zip)
UPD/ You can try to discuss all this on the forum. Or make a discussion here. But I don't like the limitations of the forum engine, because I can't upload videos there. It's much more convenient here.
I just used your previous model file.
EDIT - Model failed to upload ...
This is all parametrically automatic, no Draft tools are used.
EDIT - You may find more of the demonstration on YouTube I made earlier, hope it helps.
So... I'm starting to wonder. Are we not aiming at different things? ))) What is Wallleft and Wallright for me? I consider this as a way to tie a window or door to an outer or inner edge. I would like all other parameters to remain unchanged. That is, priorities of importance: 1) the position of the window along the wall. This is the main thing. It should remain in place (along the wall). 2) The position of the wall relative to the outer edge. Wallright is selected - it means relative to the right edge (outer). Wallleft is selected - it means relative to the left edge (inner). When changing the offset, a shift occurs relative to the specified edge. (+ into the wall. - out of the wall).
Everything else is not so important. Although ideally it should not change when changing wallright and wallleft. It is much easier to change the opening and direction of the doors than to think about how to make sure that the window does not fall out of the wall.
Just found the model file upload was not finished before previous post, uploaded again.
Another model, show 'origin' and 'orientation' of window, demonstrate again how these are considered in placement. Note how 'Flip Offset Origin to Other End' work with WallRight in these cases. So user have same types of window, use Links, and all the orientation should work, imagine user have same type of doors tens of them in a building e.g.
Maybe add properties Wall??Left and Wall??Right which automatically take into account of above tuning?
Note this is all related to 'origin' and 'orientation' of window. Alternatively, user may use 'Origin Offset Xyz and Rotation' to place the origin, just like you use MSSOffset.
Placement_object2 r2.FCStd.zip
Welcome for suggestion :)
Maybe below approach is easier for control by user and more intuitive -
Orientation and handedness are important concept here which are kept :)
But imagine an user would like put a Window at midpoint of wall, symmetrical in layout ... to be continued ...
Con't ...
But imagine an user would like put a Window at midpoint of wall, symmetrical in layout, the window Sketch maybe symmetrical upon creation -
See discussion at https://forum.freecad.org/viewtopic.php?p=600104#p600104
Test ArchSketch 115 ArchWindowl Opposite-Handedness_ r02.FCStd.zip
The window in your file behaves as it should, but only because you changed the window sketch (made it symmetrical relative to the Y axis)? Or is it some kind of setting?
If this is a sketch, then you can consider this a workaround. I doubt that an uninformed user will do such fine-tuning of each window. I think there should be an easier way (automatic).
But in any case, ArchSketch already behaves more predictably. I could say that for external walls, the Wallright binding will be the most used. I would make it the main default for a newly created window. Because windows are usually inserted closer to the outer edge. But in this case, a flip occurs.
https://github.com/user-attachments/assets/8faf2dec-2f7c-4166-8ec7-944ff3eeb642
Although perhaps I am missing something. But at the moment, if I need to place 10 windows relative to the outer edge, I will need to fine-tune each of the 10 windows. Instead of quickly placing them in the right places.
At the very least, you'll have to do a flip at normal [0,1,0] (autoflip180 at wall_right)?
https://github.com/user-attachments/assets/7805bd71-5044-469f-9bb9-5aee394b0aac
Most likely, the user just wants to insert a window, and not constantly fine-tune it. This is interesting, but after 10-20 such fine-tunings, he will get very tired of it.
I changed your code a little bit making Wallright the default. And all that's left for me is to do flip180 (I couldn't find where to set the value to "true")
https://github.com/user-attachments/assets/d6785d27-4d2c-46f2-b858-df1d9727e75f
Perhaps we have different goals. But I will still analyze what and how should change so that everything becomes simple for the average user. Now some settings may work well, but if we change the beginning and end (or wallright to wallleft) - the windows start to fall out of the wall and they have to be fine-tuned. That is, because of changing one setting, we have to make several more fine-tunings to stabilize the situation. But the main thing is that I understood how your component works.
It looks like I will have to start learning Python after all )))
Pay attention to the default Wallleft settings. When a window is placed - it is located behind the wall. (But if you change the normal to 0.-1.0) - then everything becomes normal)
https://github.com/user-attachments/assets/1f2e0f07-0e25-466f-ae82-29b29539c852
UPD/ We should simply analyze what should change when changing wallleft to wallright and vice versa. (I will do this soon).
Indeed there are several options, I will think for a while before further discuss here.
But before that, I suggest you try to alter your ArchSketch layout, e.g. into an irregular angle, recompute the Windows like I showed you earlier in below post - I believe you would have more thoughts on this topic :D
BTW, good to learn Python, looks simple, right?
I just used your previous model file.
EDIT - Model failed to upload ...
This is all parametrically automatic, no Draft tools are used.
EDIT - You may find more of the demonstration on YouTube I made earlier, hope it helps.
BTW, good to learn Python, looks simple, right?
Someone else's code (when it already exists) - I can often understand it, but writing my own is difficult for me. I've already tried )))
into an irregular angle, recompute the Windows like
What does the irregular angle mean? I made a sketch very crooked, recalculated and everything seems to look right.
Now, a few points to note here :)
into an irregular angle, recompute the Windows like
What does the irregular angle mean? I made a sketch very crooked, recalculated and everything seems to look right. !
- The attachment is parametric in the sense that no more Draft move/rotate tool after the layout is changed :)
Yes. I understood that right away. (I understood and accepted it as a given)
2. Even you delete an edge (better be one without window, for demonstration purpose only), the Window's placement would not 'jump' - it is TNP-Tolerant
This is good. But even when deleting a segment with a window, nothing breaks. This is great. Okay. I agree. The windows move a little because the "width" of the wall (the removed segment) is reset. I accept it as logical.
3. Finally, you have to set every window's Normal to (0,0,0). If you have a few Window with user input normal, it would become awkward when you change the wall alignment (even the opening direction would be awkward), try it :D
Okay. Maybe non-zero normal values will be inconvenient. Let's assume that they will be equal to 0,0,0 by default and proceed from there. Will you be able to reset the default normals in the near future?
If not, I will do it manually for each window and try to find the relationships when changing wallleft to wallright (as well as taking into account the beginning/end and middle of the wall). There is also an obvious problem associated with the fact that the window construction starts from the lower left corner. But I think you can include the wall width in the calculations. That is, when we place windows from the beginning or end, the corner origin is taken into account. If we place them in the middle, then a shift of half the width occurs.
The current situation with the middle.
I do not know how to program, but I would like to help with identifying changeable parameters so that the windows do not jump and are located where the user needs without unnecessary fine-tuning.
I think there is no need to reset normals. This causes obvious difficulties when specifying offset. I think that 0.1.0 (or 0.-1.0) are much better. Changing the sign (+/-) of the Y-axis is easier than calculating the thickness of the window/door frame.
There are a few things here :)
- Finally, you have to set every window's Normal to (0,0,0). If you have a few Window with user input normal, it would become awkward when you change the wall alignment (even the opening direction would be awkward), try it :D
Okay. Maybe non-zero normal values will be inconvenient. Let's assume that they will be equal to 0,0,0 by default and proceed from there. Will you be able to reset the default normals in the near future?
Yes, I can do this in SketchArch with Edit Attachment tool
(But now how to alert other user that the 'extrusion' direction changed from BIM's hard-coded one to Auto, and it seems to them in the opposite direction become another problem.)
If not, I will do it manually for each window and try to find the relationships when changing wallleft to wallright (as well as taking into account the beginning/end and middle of the wall). There is also an obvious problem associated with the fact that the window construction starts from the lower left corner. But I think you can include the wall width in the calculations. That is, when we place windows from the beginning or end, the corner origin is taken into account. If we place them in the middle, then a shift of half the width occurs.
This is the issue I reiterate - there is no 'insertion points' concept in the original Window tool. With your workflow, the code need to 'guess' the width of the window and adjust the 'insertion point', not to mention the direction of MSSO.
Alternatively, user do not use 'Flip 180' but the Window move to Wall Right face, then now the code needs to guess the thickness of the Window.
Why ArchiCAD has no similar problem? You are probably using its 'built-in' window type right? They have all these done for you. So maybe we can tweak the Window tool to include this there - but afterall, if the code does not guess it right, user can tweak it.
The current situation with the middle.
For now, you can use the Origin Offset Xyz to set the 'Orgin' to midpoint of the Window/ Sketch - i.e. without user to edit the Window's sketch. You can also use this trick for WallRight at the moment.
I do not know how to program, but I would like to help with identifying changeable parameters so that the windows do not jump and are located where the user needs without unnecessary fine-tuning.
Thanks for the testing and ideas indeed.
I think I would tweak the behaviour of WallRight after all the discussion :D
I think there is no need to reset normals. This causes obvious difficulties when specifying offset. I think that 0.1.0 (or 0.-1.0) are much better. Changing the sign (+/-) of the Y-axis is easier than calculating the thickness of the window/door frame.
It needs to be (0,0,0), or when the 'normal' of a wall segment != window's normal, e.g. wall at oblique alignment, you will have incorrect window shape and opening direction.
It needs to be (0,0,0), or when the 'normal' of a wall segment != window's normal, e.g. wall at oblique alignment, you will have incorrect window shape and opening direction.
Can you make an example file? I probably don't quite understand what you're talking about. It seems like everything is fine with the window, even if the normal is 0,1,0 (or 0,-1,0)
For now, you can use the Origin Offset Xyz
Yes. I think automatic change of parameters of this particular setting will be the most useful for us.
I understand that the width of a window or door can play one of the key roles. Isn't there a way to calculate these values to use in calculations (code)? if not, then this is a huge obstacle to the implementation of convenient work (((
I don't know how it is done in ArchiCAD. I never had to think about how it works there. Windows were simply inserted conveniently and that's it )))
Oops, you are correct, I forgot it is 'half-fixed', just something remains ! :D
Without SketchArch, when user move+rotate the underlying Sketch placement
With SketchArch, but Normal is not (0,0,0) when user move+rotate the underlying Sketch placement
So, I always set it to (0,0,0), extrusion would Not be in awkward direction, it would not move 'unexpectedly'.
Placement_object2 r2.FCStd.zip Placement_object2 r3.FCStd.zip
I understand that the width of a window or door can play one of the key roles. Isn't there a way to calculate these values to use in calculations (code)? if not, then this is a huge obstacle to the implementation of convenient work (((
I don't know how it is done in ArchiCAD. I never had to think about how it works there. Windows were simply inserted conveniently and that's it )))
No problem in fact if it is preset, or say rectangular window e.g., that's how ArchiCad and others probably works, but not user custom made window / door. FreeCAD preset Window/Door always set out from 'lower-left'.
Look at the some of the diagrams I showed in FC forum, I create trapezoid window on elevation, then it would be tricky for code to guess which point user want it be the insertion points.
Imagine, for a symmetrical Renaissance / Gothic windows, you probably want the bottom midpoint be the insertion point, right? Then user needs to layout that on Sketch accordingly.
So to conclude, from ordinary user experience point of view, better add different insertion point in Window tools for presets, and allow that in creation panel. Or at least, SketchArch guess the width or thickness, and allow that in WallRight (or vice versa).
Without SketchArch
For our task, this is no longer important. If we cannot move windows using DRAFT tools, then why should we worry about normals? In ideal conditions, the user should not think about normals at all (like in Archicad).
No problem in fact if it is preset, or say rectangular window
This is actually cool because it can be used in window position calculations.
FreeCAD preset Window/Door always set out from 'lower-left'.
I agree. It would be a good change at the core level of the program. But until it is - we have to use workarounds.
For example, I developed a multisketch with different profiles and change the binding there using sreadsheet $ expressions. You can see the details in the forum thread. https://forum.freecad.org/viewtopic.php?t=88781
https://github.com/user-attachments/assets/35163067-1f80-4c93-a316-a545670e192e
By and large, to switch the window left/center/right - we just need to add one parameter to the window sketch. But I don't know how to do this.
Imagine, for a symmetrical Renaissance / Gothic windows, you probably want the bottom midpoint be the insertion point, right? Then user needs to layout that on Sketch accordingly.
Yes. This is a possible problem. But in this case there are two ways: 1) The user can add his own property and it will be used in further calculations. 2) If there is no property, then the width value in calculations is zero and the current approach works.
I think that in most cases users will use presets. Curved windows are needed, but they are used less often.
And the best thing would be to simply increase the number of preset windows and doors. But now preset windows are generated by code. I do not know how to change this so that there are more presets.
A few diagrams for ease of discussion. So below are the behaviour you expected as WallLeft and WallRight, correct?
Test ArchSketch 116_ ArchWindow_Attachment-Origins_r0.FCStd.zip
WallLeft
WallRight
WallLeft
WallRight
Window / Base Sketch
WallRight, correct?
Not much wrong for Wallright
In general, your component already works as it should. I just have to do flip180 for Wallright
Walleft and Wallright are something like indicating which side our outer edge of the window is on. (in addition to the fact that the window sticks to the corresponding edge of the wall)
About the window width. It is useful for us to make the central window strictly in the center of the line (midpoint 1/2). That is, the left window binding is useful when the dimensions are specified on the left side of it, the central one - when in the center and the right one when from the end of the segment.
I will now record a video of how this happens in ArchiCAD. I think everything will become clear right away. In fact, you can make such an option in FreeCAD.
I don't know if I'm doing the test correctly, but if different wall segments have different alignment and different offsets, the windows and doors that are placed are positioned in an incomprehensible way. I tried changing the properties of windows and doors, but the result is always unusual.
I assume that the problem is precisely in the offset (it seems that it is not taken into account if !=0).
The test file is attached (remove the zip extension). Placement_object.FCStd.zip