Forum Replies Created
-
AuthorPosts
-
Heimo Mooslechner
ParticipantWhat i am looking for exactly is this:
I have a given Array of x and y – a closed polygone in the form of:
x[points] and y[points] and the number of points in the Array in an extra integer named “points”.
I want to get a second polygone – with an inner offset to the original one.
As far as i understand the GDL-handbook, i first have to open a channel with the code:
kanal = INITADDONSCOPE ("PolyOperations ", "", "")
Then i have to prepare my source and Target – Polygones:
! --- QUELL- + ZIELCONTAINER ERZEUGEN PREPAREFUNCTION kanal, "CreateContainer", "Eingang", "" PREPAREFUNCTION kanal, "SetSourceContainer", "Eingang", "" PREPAREFUNCTION kanal, "CreateContainer", "Ergebnis", "" PREPAREFUNCTION kanal, "SetDestinationContainer", "Ergebnis", ""
after this, i have to give my extra stored coordinates into one array:
for oft = 1 to points arrayname[oft][1] = x[oft] arrayname[oft][2] = y[oft] arrayname[oft][3] = 0 !! angle? nZug=nZug+1 : zug[nZug]=oft next oft
Then i have to give the array to the function:
PREPAREFUNCTION kanal, "Store", "Polygon", points, 1, arrayname, zug (contourArray)
i have difficulties to understand this:
contourArray: An array which contains the index of the last vertex of the i-th contour. It must have exactly nContours items.
Therefor i would need an Example how to to this correctly!
Then i have to “init” the calculation with: ?? or how exactly?
dim resPolyIDArray[] nPgon = CALLFUNCTION (Kanal, "OffsetEdge", "Polygon", resPolyIDArray)
Then i have to read out the resulting array:
nPgon = CALLFUNCTION (Kanal, "GetDestinationPolygons", "", resPolyIDArray)
after this i can close it:
CLOSEADDONSCOPE (Kanal)
Then i can use put and get for an Poly2-Command to draw the polygone. Im i Right so far? There are a lot of possible mistakes i can make with this very complex command…
Teacher in HTL-Salzburg
AC5-19, Win and Mac
GDL hobby developerHeimo Mooslechner
ParticipantGDL definetly should be a mirror to the existing Drawing-enviroment. But besides that – it should give the same amount of editing-possibilitys to the end-userasit does for normal Archicad-Tools as Wall, Slabs ect.
If i declare a Prism – its basicly a set of coordinates with a functionname. If a User activates this thing – it should be possible to alter the shape of it with the normal drawing enviroment without the usage of editable hotspots. The shape schould react as any other normal shape in Archicad like a slab- with the normal pet-Pal-commands. Such a functionality should be implemented without special commands needet. All the calculation needet for it schould be made by Archicad direct – not with complex GDL-Commands. Such a shape would nott have to be static- it schould be able to grow with new points- all the same as evers other shape in Archicad.
The User wouldnt have to lern new, how to operate the thing. All used commands should work without GDL-Scripting. It should be implemented in the Shape-commands direct on the maximal simplest way for the scripter.
You cant imagine the possibilities and the success for Archicad with such a tool.
Lets think it NEW!
Teacher in HTL-Salzburg
AC5-19, Win and Mac
GDL hobby developerHeimo Mooslechner
ParticipantI like to put independent elevation-views inte the groundfloor, sometimes to write text to it – some datas, some helptext for the User. I did this in many of my elements for a smoother user workflow experience and other reasons.
some of my examples:
blockwall-building wall part with elevation
of a more complex one:
Balanced Stair with elevations
Foundation – stepping with section
and a really complex one:for displaying and editing ducts in groundfloor and sections and 3D
You have to try them by Yourself to understand their functionality – and for the most of them i made Video-Tutorials on Youtube.
For the Duct-Part – normal elevation would not work, because this thing is drawn to flat in the elevation-view with 2 diffrent scales for the same drawing: 1:100/500 (100 for the Hight, 500 for the length) This is normal in length profile in planning for sewer construction.
As i made very good experiences with this kind of usage uf the 2D-GDL, i would like to use that also for complex wall openings. You wuoldnt need this for normal Doors and Windows – but for direct constructing and Editing – its a wonderful possibility.
Did You look at my Video-Link above? Tutorial for the Usage of my MultiWindow1
Teacher in HTL-Salzburg
AC5-19, Win and Mac
GDL hobby developerDecember 9, 2015 at 07:09 in reply to: WALL_COMPS_NAME not being recognised from verion 17 onwards #1995Heimo Mooslechner
ParticipantThanks for Your reply – sorry for my rude writing – but i really was a little upset for loosing hours for looking at any possible error i may have made by myself. I found out the “In 3D you can use WALL_MAT_A and WALL_MAT_B for the wall surfaces.” by myself in the meantime – But thanks.
Maybe i work in the wrong direction with my freeform-multiwindow..
I got an code from “sinseV6” = esteban ramos from Architalk-forum – which made it possible to create 2D+3D polygones with a growing ammount of segments – open and closed.
I tried to use this as background for several GDL-Objects and now, i thougt it would be time to use my collected knowledge about this on a freeform Window-Opening.
I took this Polygone-koordinates to a wallhole-command and it worked fine. My problem here is the tube command.
I used the tube to follow the polygone-path with using a series of put and get-commands. (The tube allows to do this without calculating parallel points to the polygone in GDL-what is to hard for me -i tried it and failed.)
So it was possible, to make the window-frame follow the opening-polygone and that worked also fine…BUT – when i tried to make the outer-wall-plaster and the warming-insulation reach over the window-frame for simulation of a Layer-feed (german “Schichteinzug” – hope its translated correctly) – i had no chance to get the Tube without a line between the Wallhole and the tube. I found out how to supress the wallhole-Line, but the tubeline was too hard for me to supress.
So – there is still a line between my additional plaster-tube and the wallhole – and i thoght – there should be an automatic within Archicad – that same surfaces elliminate lines between elements the same way it does between walls and slabs?
With tube it does not work.
My question – would it be better – instead of using tube for getting a graded wallhole – to use some kind of other usage of wallniche-command or other solution for this kind of wallopening? How are the wallopening-gradings of library-Part – windowopenings made? Its so hard to find the correct script containing these things in the Archicad-Library.
For Your tryout: https://www.dropbox.com/s/afdhmlwoi6td0y3/Multifenster8_12_2015.pln?dl=0
and a Youtube-tutorial in german (just turn the sound off if german is not the right..):
https://www.youtube.com/watch?v=VzkindxTceQ
Teacher in HTL-Salzburg
AC5-19, Win and Mac
GDL hobby developerHeimo Mooslechner
ParticipantThat means – we have to live with this.
The idea of my GDL-behavour was, to have a clean groundfloor – view for placing that into the Layout for plotting – but still there are these drawings of the elevation of the openings somewhere out of plansight. I know that this is not the List-System- which Graphisoft is preferring for wall-openings, but would there be the possibility to edit the shape of it with hotspots?
My system would have some potential – i think – not as replacement but as supplement.
Teacher in HTL-Salzburg
AC5-19, Win and Mac
GDL hobby developerHeimo Mooslechner
ParticipantThank You for Your reply!
May i suggest: Please (Graphisoft) add links to Your above mentioned tutorial page into the GDL-handbook.pdf in the future. This would be most helpful – or put the Text of the pages directly into the handbook.
This would help us users not to spent hours of seeking trough all known knowledge-sources. Because i use GDL since nearly 20 Years – on a low level – i did not know about this site to look for answers – but i Know the book – and there the links to this should be – direct at the topic – not at the end of the book or so..
Other users obviously have the same problem of seeking and finding information – and they built their own knowledge-site: Maybe You know this page: https://www.selfgdl.de
But there is only the things available that they have found out. Please have a look at it too and correct them if possible! Thank You forwarding..I have some other problems with my multiwindow-library-part – but i think i have to open other tasks here for it.
Please understand me right – You program for GDL is wonderful – its just the “looking for information about it” that i criticise here.
Teacher in HTL-Salzburg
AC5-19, Win and Mac
GDL hobby developerHeimo Mooslechner
ParticipantNow i got it finally!! It sometimes (very often) – is very hard to understand the GDL-handbook – because it is so poor in examples. The textal description is right – but very 🙄 😯 😈 🙁 without an minimal amount of examples)
You have to repeat the valuename once again instead of displayParam! – thats all!
Why dont they tell this clear!
Wy not writing simply: repeat parameter name instead of displayParam – so that onyone can simply understand it?
It is written there in a way – my simple mind could not understand it for hours! I had to find out with trial and error – seeking!
Teacher in HTL-Salzburg
AC5-19, Win and Mac
GDL hobby developerHeimo Mooslechner
ParticipantThank You for Your reply. In the meantime – i figured the WALL_MAT_A and WALL_MAT_B out by myself – and took it as a workaround for the limitation of WALL_SKINS_BMAT_NAMES in3D. This should really be changed in further AC-Versions.. i think.
And thanks for the suggestion for using “ii” instead of “i” – i will make it so in future. Do i understand it right – this BBC is limitation for this forum – not for the GDL?
Teacher in HTL-Salzburg
AC5-19, Win and Mac
GDL hobby developerHeimo Mooslechner
ParticipantI have some problems with this parameter and the correct usage..
i wrote:
OFT = WALL_SKINS_NUMBER i=1 for ii = 1 to oft WSP[ii] = WALL_SKINS_PARAMS[ii][1] !Schraffur KernSTR = STR(WALL_SKINS_PARAMS[ii][6], 1,0) Kern = WALL_SKINS_PARAMS[ii][6] WSBN[ii]=WALL_SKINS_BMAT_NAMES[ii][1] !Baumaterial add2 0.15,0.02 style links t = REQUEST{2} ("Building_Material_info", WSBN[ii], "gs_bmat_surface", oberflaechen[ii]) !!S378 r = REQUEST ("Name_of_material", oberflaechen[ii], name[ii]) del 1 if ii = 1 then Aussenputz = oberflaechen[ii] if ii = oft then Innenputz = oberflaechen[ii] s=request("Name_of_fill",WALL_SKINS_PARAMS[ii][1],Schichtnamen[ii]) !Schichtnamen[ii]=WSBN[ii] Schichtdicken[ii]=WALL_SKINS_PARAMS[ii][2] !Dicke if KernSTR="3" then WoKern = ii else Gesamtdicke = Gesamtdicke + Schichtdicken[ss] endif add2 0, -0.015 next ii del oft-1 for ss = 1 to WoKern-1 Dickensumme = Dickensumme + Schichtdicken[ss] next ss
in the 2D-Script – i got correct answers from it.
there i wrote:
for ii = 1 to oft add2 0, 0.05 text2 0,0,oberflaechen[ii] Text2 0.2,0, Aussenputz !! nur als Test - schreibt brav 18 hin next ii del oft-1
BUT – in the 3D-Code – i got Just 0 when i tried the same – and there i would need it so badly…
i wrote in 3D:
DEFINE STYLE test "Arial", 10, 1, 0 style test for ii = 1 to oft addy -0.012 addz 0.1 text 0, 0,oberflaechen[ii] - !!nur als Test - da schreibt er gar nichts hin TEXT 0.01, 0, Aussenputz !! sollte überall 18 stehen - aber macht im 3D 0 draus del 1 next ii del oft
Why is it not functional in 3D?
I personal would need it for self made wall-openings with much more editable hotspots than are used in the normal Archicad-library.. for a much better user-experience..
Teacher in HTL-Salzburg
AC5-19, Win and Mac
GDL hobby developerDecember 1, 2015 at 21:16 in reply to: WALL_COMPS_NAME not being recognised from verion 17 onwards #1958Heimo Mooslechner
ParticipantThe deafening silence what had happend in all the forums i tried – since my post in this topic seems to tell me – no-one at Graphisoft has an answer to my two Questions. Its a little indictment for Graphisoft.. To answer such topics time-near should be everydays buissness – but to keep silence so long…
Maybe they should implement a solution for this in further AC-Versions. rolling eyes..
Teacher in HTL-Salzburg
AC5-19, Win and Mac
GDL hobby developerDecember 1, 2015 at 10:15 in reply to: WALL_COMPS_NAME not being recognised from verion 17 onwards #1955Heimo Mooslechner
ParticipantI have explored similar issues on my new freeform-Window with
WSBN[ii]=WALL_SKINS_BMAT_NAMES[ii][1] !building material
Thats what i am writing about:
Youtube description of the problem
In the meantime, i figured aut, that it seems to be simply locked by Graphisoft, to read out the building materials – but just for 3d. In 2D ist is possible to use the commands and it works perfect but in 3 D – no way!
WSBN[ii]=WALL_SKINS_BMAT_NAMES[ii][1] !building material t = REQUEST{2} ("Building_Material_info", WSBN[ii], "gs_bmat_surface", surface[ii]) !!GDL-manual german S378 r = REQUEST ("Name_of_material", surface[ii], name[ii])
I tried the code above in the masterscript – which works for both 2D and 3D-scripts – but it makes different results.
Very bad! It took me hours to find out and to really belive it!!
Why is this made this way by Graphisoft? Is this one of the intern not really documented “policys” do make it really hard to script good library-Parts?
I hope someone from Graphisoft reads this and feels my …. disappointment… Shocked
Who is the woman or man there -the BOSS of GDL at Graphisoft – who makes such decicions – i really would like to get in contact directly!
Please – if You read this, “GDL-Boss” – Yes – You – write back here “in the open”, come into the discussion – take part – please!
To try – AC19EduAut – grman –
german Vido deeper in this topic:
Teacher in HTL-Salzburg
AC5-19, Win and Mac
GDL hobby developer -
AuthorPosts