We value your input! Please participate in Archicad 28 Home Screen and Tooltips/Quick Tutorials survey
2024-09-09 03:20 PM - edited 2024-09-10 03:49 AM
Hi, I am dipping my toe back into some GDL scripting after years away from it.
I have made a simple 2D object conisting of a bunch of fills copied from plan view into the GDL scropt editor window.
Each fill corresponds to a user selectable aluminium profile, used to support the base of aluminium doors and windows acoss a cladding cavity. These objects are used in nearly all 1:5 door and window details in domestic and much commercal cavity wall construction where I live (New Zealand)
That much works fine.
My next problem is to create a user defined 'stretchy zone' within each placed object version, where fill nodes within this zone can be scaled closer to one another horizontally via stretchy hotspot control, or numeric distance parameter.
The motivation for this is that the part of each aluminium profile that sits within the wall cavity often visually obsures the linework of other items or lines occupying the same area within the cavity (such as the lines representing adjacent membranes or flashings)
By locally distorting the geometry of that part of the aluminium profile object, clear space can be visually opened up beside that part, to allow for other objects within the same confined cavity width to be more clearly depicted, for greater visual clarity.
What I would like is for the user to be able to position two stretchy hotspots, one either side, to define the area to recieve hoszontal distortion, and to use another hotspot to control the amount of stretching/squeezing.
This (to me) seems a crazy hard and time consuming thing to attempt, even for just one fill. (The only approach I can think of is perhaps by mutiplying the x coordinate of each and every node of the fill by an individual scale factor formula, which must be uniquely calulated for every node, each worked out according to its own unique relationship to the stretch boundary hotspots, whether inside or outside them) - but I have something like 10 of these aluminium profile fills of different shapes and sizes to deal with, each with hundreds of nodes - so manual re-coding for each fill node with added formuals and variables seems out of the question.
Maybe some sort of super-clever macro could detect and edit the x cordinate of every coordinate pair in every fill definition, adding in the requiste horizontal repositioning formula - but this is well beyond me!
Any help/suggestions most welcome!
Has anyone attempted anything like this?
In practice what happens currently is I place the object with required profile selected, explode it, clean up the resulting mess of lines (just leaving the fill, but adding an outline) and then manually marquee stretch the resulting exploded geometry as required to improve clarity of the detail drawing - but since this is such a recurring task within and between jobs, it seems like there should be a smarter & cleaner way.
Also, when originally defining the object, I sadly copied each fill (from drawing imported from manufacturer) into the GDL 2D script from a different location on the source plan view - so now if I change the selected profile from one to another within object settings, the placed object jumps sideways to correspond to the position on the original source plan view.
Is there any clever way to eliminate this offsetting effect without defining each fill again, or knowing exactly how far offset each source fill was from the origin?
2024-09-10 04:30 AM
Could you show an image for what your are trying to stretch?
All of the POLY co-ordinates that you want to stretch (move) will have to have a 'move' value added to the co-ordinate value.
For example (this is not the proper code) ...
POLY
x1,y1,
x2+move_distance,y2,
x2+move_distance,y2,
x2+move_distance,y2,
x2,y2,
x2,y2
That is fine if you know exactly what nodes will be moving.
But to have a user define an area to stretch, and then have just those nodes move will be much more difficult.
It could be done (I think) by having a stretchable rectangle (defined with moveable hotspots).
Then compare the X & Y coordinates of every POLY node to determine if it is withing the rectangle X & Y co-ordinates.
If it is inside then 'inside_rect' would be 1, else 'inside_rect' would be 0.
You would then PUT the POLY nodes individually ...
if inside_rect = 1 then
PUT x2+move_distance,y2
else
PUT x2,y2
endif
Do this for each POLY node (you could use a sub-routine to save scripting the same over and over).
The place the POLY ...
POLY NSP/2
GET(NSP)
Of course this is completely untested by me.
Just thinking out loud.
As for the 'jumping', the co-ordinates of the POLY contain the position of the nodes.
So if a profile jumps in the X direction by 600mm, then you need to reduce all of the POLY X co-ordinates by -0.600.
Or use an ADD2 -0.600,0 before using that POLY.
When creating POLY from fills, it is always a good idea to place the fill at the project origin (0,0) before dragging into the script to create the POLY.
Use a common anchor point for all the fills - i.e bottom left corner placed on the project origin.
Barry.
2024-09-10 05:16 AM
Just wondering, what would the advantage be of being able to change the extents of the stretchable zone? Would there not only be one "valid" stretch zone so as not to distort fixings and flanges within each profile? Scripting it to be dynamic sounds like a whole lot more trouble than it is worth...
Ling.
AC22-23 AUS 7000 | Help Those Help You - Add a Signature |
Self-taught, bend it till it breaks | Creating a Thread |
Win11 | i9 10850K | 64GB | RX6600 | Win10 | R5 2600 | 16GB | GTX1660 |
2024-09-10 07:19 AM
The advantage is mostly that I would not need to know ahead of time which bits might be squashed - as different situations require different responses even with same profile, and each profile has quite a different area that might or might not need need squashing. I was hoping for a sort of 'universal' solution that did not involve hand editing every node on every profile, each with a different algorythm based on its own predicted stretch zone,
Hope that makes sense
Arguably what I want is analagous to a marquee stretch function - and of course the simplest solution is to just keep on exploding the object and marquee stretching it as required - but it would be nice not to have the extranaous edge line work and turned off fill edge line in the exploded results.
2024-09-10 07:23 AM - edited 2024-09-10 07:25 AM
Hi Barry - yes what you describe was broadly what I feared would be required. I was hoping that in the years since I last did much of anything in GDL, some new bulk coordinate transform techniques might have arisen to minimse or even avoid individual manual editing of the starting fill node coordinates, since there are so many of them.
2024-09-10 06:39 PM
Hi Paul.
Yes, a picture could tell us more what You are looking after.
I have done lots of door & window detailing so I might be able to help You.
Are You looking for a smart stretchable profile to be used in multiple situations?
Then there must be a polygon that defines the vertices inside the polygon that are movad by hotspot.
Maybe many polygons.
I have some workarounds done for similar cases so I think it is possible .
2024-09-11 02:38 AM - edited 2024-09-11 02:42 AM
Hi Perttri
In the screenshot below I have placed a few of the profile options and indicated the zone where any stretching is most likely to be wanted (basically within that part of each profile that sits within a typical 20mm wall cavity, immediately behind the outer cladding layer. There are a few exceptions where a wider zone is needed to capture both ends of curved edges that straddle the edge of the cavity zone (not including both ends would cause curves to distort too noticably)
Sometimes the inwards stretch needed can be from one or the other side only, or sometimes both, depending on what else needs to be drawn passing beside the profile within the wall cavity.
I have also attached the current version of the object so you can see my starting point.
2024-09-13 01:31 PM
In this case I would create 2d polygons for every alternative so that they have the same coordinate origo.
Too much work with "intelligent" solutions.