Sokkal több infóanyag kellene a programról, mert a napi rutinban nincs idő kísérletezni. A 17-es egyenesen ijesztő 🙂 a maga finomhangolásával, energetikai moduljával.A profilfalat javaslom. Az ütős és hasznos.

Csak tipp ,…ha építész lennék én megpróbálnék konzultálni a nagyobb, homlokzatépítő/nyilászárógyártó profi project cégek műszaki előkészítőivel/kereskedőivel…
Pl: Alukol Kft. ALufe Kft. Alukonstrukt.Fehéralu Kft stb…. Vagy mondjuk felhívnám pár szaktanácadót a profilgyártó cégektől Pl :a Wicona, Reynaers, Aluköenigsthal(schücho) Kft. ésatöbbi…

és miről konzultálnál?
ez általában úgy működik, hogy a kivitelezéskor kiválasztott ablakgyártó (aminek köze sincsen az építészhez azokban a projectekben, amiket az itt kommentelők terveznek) csinál egy saját konszignációt a megrendeléshez, általában teljesen átszámozva, átalakítva a meglévő konszignációt. (pl a toktoldókat összevonva írja ki, nem ablakokhoz rendelve, hogy véletlen se lehessen ellenőrizni, hogy melyik ablaknál felejtette le)
Ezt jó esetben vagy a kivitelező vagy a tervező átnézi, megérti és javítja – vagy nem és akkor kimaradnak dolgok vagy 10centivel nagyobb ablak jön.

Az AC-s konszignak kb három hibája van, amiért én speciel nem használom:
– számomra nem elég vizuális a kontrol, sem az ellenőrzés oldaláról (bár ez ügyben azért történt némi fejlesztés), sem a meghatározások nem elég vizuálisak. én rajzolni szeretném az ablakot, nem legördülő menüben kibogarászni. – persze nem kívánságműsor. de az ellenőrzés az baromi fontos lenne, hogy ne maradjon ki toktoldó meg osztólécek.
– a tervezett ablakok vagy annyira alap típusok, hogy elég egy puszta felsorolás a méretekről, vagy annyira egyediek, hogy nincsen olyan ablak az elemkönyvtárban.
– egy 40 tételes konszigot összemásolok a már meglévőkből egy délután alatt és egyúttal ellenőriztem is az összes ablakot, hogy oda tényleg az a jó-e, nyitásirány ok-e, osztás ideális-e stb… szóval a konszig egy utolsó ellenőrzés is egyben számomra, amikoris minden egyes ablakra külön rászánom azt az „ötpercet”, amit megérdemel.

mondjuk az eco designerrel is ugyanez a hármas a bajom csak energetikára vonatkoztatva. mondjuk ha egy részletterven a kitöltéseket értelmezve tudna pontszerű/vonalmenti hőhidat számolni… – az áldás lenne. Mert ma már nem a nagy koncepciókon múlik egy ház energiafelhasználása szerintem. – de ez egy külön postot is megérne, hogy azt ki és hogy és miért használja.

A darabszám és nyitásirány ellenőrzésen kivül nem használom másra, mert annyi egyéb kiegészitő információt kell még amúgy is a lapokra irni, hogy nincs értelme.
Van egy összerakott sablonom, sokkal gyorsabban haladok azzal, ha az alaprajzból átmásolom az ajtót a falszakasszal, és a metszetből/homlokzatból átmásolom a nézetét.
Anno 10 éve egyik bedolgozói projectnél ebben kérték a konszignációt, vért izzadtunk vele. Gondolom azóta fejlesztették, de nem vagyok hajlandó szőrözni vele…

Való igaz, hogy a konszignáció (mint ahogyan egy sor más is) kb. most tart ott, ahol ~5-6 (8-10) éve kellene tartson.
A téma nem független az egész program működésétől: véleményem szerint az egyik legnagyobb gond a szoftver iszonyatos zártsága (az archicad olyan, mint a playmobil: iszonyatosan jó játék, nem kell bügyörészni a játék elkezdéséhez, azonnal neki lehet kezdeni, és ha az ember kellően sok elemmel és kreativitással rendelkezik, akkor el lehet vele szórakozni – a lego ezzel szemben kicsit darabosabban néz ki, de sokkal nagyobb távlatok vannak benne, s ha nem szedjük szét mindig a már megépített elemeket, akkor pont ugyanolyan gyorsan neki lehet állni a játéknak…)

Bár van ez a gdl programozhatóság, de 2013-ban ez inkább vicc:
1) Egyrészt egy kb. 40 évvel ezelőtti programozási paradigma alapján működik még ma is (gyakorlatilag egy egészen alap basic programozási nyelv az alapja); a külső adatkapcsolat gyakorlatilag arra korlátozódik, hogy szöveges fájlt be tud olvasni és megtalálja a vesszőket és a tabulátorokat a fájlban; a paraméterátadás pedig arról szól, hogy ha egy elemnek van 40 paramétere, amiből 1-et akarok változtatni, akkor mind a 40 paramétert meg kell adnom, szép sorban, a megfelelő sorrendben, egyet sem kihagyva. A programozás azért az elmúlt 40 évben fejlődött egy kicsit (egy objektum orientált nyelven pl. ez a paraméterátadás úgy néz ki, hogy megmondom, hogy melyik objektum, melyik paraéterét mire akarom változtatni – és kész). Arról nem is beszélve, hogy ma talán elvárás volna, hogy mondjuk rendes webes adatkapcsolata is legyen a programnak (a bimcomponents.com is egy csillivilli vicc a jelen formájában).
2) És akkor arról még nem is beszéltünk, hogy mindez a programozhatóság be van zárva a ‘tárgy’ elembe, aminek vajmi kevés kapcsolata van a többi elemmel: komoly nehézségek árán ugyan bele lehet zsonglőrködni bizonyos tervi információt (de csak azokat, amikre a program lehetőséget ad, pl.: szint száma, magasság, elem tollszíne stb.), de egy csomó infó megszerezhetetlen, vagy elképesztően nehézkes. A tárgy visszahatásáról (hogy valamely paraméterének változtatása hatással legyen más elemekre), vagy a grafikus szerkeszthetőségról még álmodni sem álmodhatunk.
3) De miért is volna mindez lényeges? Számtalan érvet lehetne hozni. Mindenekelőtt: a versenytársak (autocad, sketchup, rhino3d) már rendelkeznek ilyennel. Az IT szektorból számtalan példát lehetne hozni a különböző nyílt fejlesztésú rendszerek elképesztő sikerére. Ez egy csomó fejlesztési feladatot venne/vehetne le a graphisoft válláról (nem kellene félni: maradna még úgyis elég tennivaló). Kell-e beszélni a parametrikus-, algoritmikus-, nonstandard- építészet térhódításáról? Vagy arról, hogy egy ilyen rendszerben a gyártók maguk tudnák biztosítani a termékeik megfelelő megjelenését a programban.
4) De mi ennek a „késlekedésnek” az oka? Egyrészt az, hogy a graphisoft véleményem szerint nem a legjobb alapstratégiát alkalmazza: bizonyára készíttetett kutatásokat arra vonatkozóan, hogy az építészek körében milyen arányt képviselne a programozással bíbelődők száma; és ennek a kutatásnak valószínűleg az lett az eredménye, hogy ez egy nagyon kicsi arány. A probléma az, hogy erre nem azt a választ adták, hogy: nosza, neveljünk ki egy csomó önkéntes fejlesztőt; ha kevesen vannak, akkor van lehetőség a fejlődésre – hanem azt, hogy: ha kevesen vannak, akkor azzal nem is kell foglalkozni.
5) Persze lehet azt mondani, hogy létezik API developer programja a graphisoftnak is; ami igaz is, de ezt a programot semmiképp sem nevezném sikeresnek. Sem a promócióját, sem az eredményeit tekintve. Lásd pl. hogy milyen a viszony a Cigraph-fal (gond nélkül integrálnak bizonyos funkcióikat, de úgy egyébként nem sokat foglalkoznak velük, nincsenek kihagyhatatlan közös akcióik – még az artlantis-hoz képest is mostohagyereknek tűnnek)

Visszatérve a konszignáció problémáira: a fő gond az, hogy egy ilyen szoftvertől elvárható volna, hogy koncepcionálisan foglalkozzon a különböző elemek paramétermegadási problémáival.
Pontosabban mivel is?
Hát azzal, hogy a program nem ad lehetőséget arra, hogy valódi építészeti gondolkodás alapján lehessen használni, hogy magában a programban tudjak konkrét anyagokat, szerkezeteket kiválasztani. Merthogy az nagyon nem ugyanaz, hogy egy adott szerkezet minden paraméterét meg tudom adni a programban, minthogy egy konkrét anyagot/szerkezetet választok ki (egyrészt az archicadben rettentő sok paramétert lehet megadni, de ezek jelentős része nem valódi tulajdonság, hanem a program számára értelmezhető paraméter – lásd pl. az anyag renderelési tulajdonságokat).
Merthogy az ArchiCAD-nek (huszon évekkel ezelőtt) éppen az volt a versenyelőnye a többi CAD szoftverrel szemben, hogy „építészesen gondolkodott”, hogy építészetben értelmezhető eszközei voltak, az általános mérnöki szoftverek univerzalitásával szemben.
Éppen pont ilyen lépés lenne ma, ha lehetőséget teremtenének arra, hogy magában a programban tudjak pl. egy konkrét beltéri ajtót, vagy falazóelemet kikeresni és kiválasztani; s ne pedig az legyen a módszer, hogy valamilyen katalógusban kikeresem az adott szerkezetet, majd valahonnan kibányászom a releváns paramétereit, s nekiállok beállítgatni az esetenként 30-40 paramétert.
Vagy például az, hogy tény, hogy a program számára egyszerű lekezelni a falak szinezését úgy, hogy megadhatom a fal két oldalának és a káváinak a színét; de a valóságban egy építész nem ilyen módon szereti meghatározni a falszíneket, hanem mondjuk egybefüggő falfelületekként, amikre mondjuk mintákat is lehet rajzolni, mondjuk szabadon.
Összességében: én valami olyat várnék el a graphisoft-tól, hogy rendszeres időközönként fölülvizsgálja az egész program működését, koncepcionális szempontból. Hogy az adott eszközök még mindig a legmegfelelőbbek-e, nem volna-e egyszerűsítési lehetőség, átdolgozandó működés?

hát ezt megmondtad, Sityu 😉 és bár sokmindenben igazad van, de szerintem nem ennyire fekete és fehér a helyzet – én úgy másfél éve elkezdtem tervezgetni egy webcad-programot (lásd three.js képességei) és bár csak egy gondolatkísérlet volt, többek közt arra jöttem rá, hogy nem egyszerű ez az „építész úgy akarná” dolog.
Igaziból ma már az lenne a nagy durranás ha sokféleképpen meg lehetne csinálni ugyanazt egy AC-ben, nem csak egyféle mechanizmussal. És ugyan a valódi tulajdonságok meglátásod nagyon tetszett és tuti fogom használni ezt a kifejezést eztán, de minél komplexebb dolgokat akarunk létrehozni, annál több paramétert kell megadni. Én szívesen megtanulok pár elvont tulajdonságot, ha cserébe nem 50 csak 30 paramétert kell megadni, de az a baj, hogy a 30 is már sok. Amíg nem változik meg az adatbevitel hatásfoka jelentősen, addig egyikünk sem fog örülni az újabb nyílászárós lehetőségeknek, mert már így is szívás újrakezdeni egy nyílászárót, ha másik tárgyból kellett volna kiindulni.
Az adatbevitel reformja az, ami a fejlődés jelenlegi gátja és aki kitalálja a tutit, az leradírozza talán még az autocadat is, mert szintén ebben a csapdában vergődik.

(mondjuk azért még volna hova javítani addigis a külcsínen – lásd miket tudhat egy egyszerű webboldal is ma már – nálam a videóval textúrázott amőbaforma verte ki a biztosítékot… lightworks…)

[re=86629]Tóth Szilveszter[/re]: Kösz, hogy végigolvastad (pedig nem sikerült túl rövidre). A kommentből kikövetkeztethetően úgy tűnik, hogy sikerült jobbára érthetően megfogalmaznom, amit akartam.

Több mindent vetettél föl (bocs, de megint elég hosszúra sikeredett a válaszom):
-webcad: bár én érdemben nem tudok programozni (csak gdl-ben; meg úgy nagyjából a komolyabb (python, ruby, js, php) nyelvek alapjaival vagyok tisztában), de én is gondolkoztam már egy ilyen webcad-jellegű ötleten. Azon, hogy egy kellően univerzális (valószínűleg ifc alapú), opensource bim rendszert talán nem volna butaság inicializálni. Tudom, hogy rengeteg munka volna és a siker sem garantált, de ha még próbát sem teszünk, akkor soha nem derül ki. S ne felejtsük, hogy hol tartott a IT világ (hardver ill. szoftver fronton), amikor belevágtak az archicad fejlesztésébe… Illetve gondolkoztam még az archicad-api-n is (hogy mondjuk az alábbiak egy részét megcsinálni), de az elég macerás. Szóval, ha újból fölvennéd a webcad-es fonalat, gondolj rám; szerintem tudnék hasznosakat hozzátenni az ügyhöz.
-az “építész úgy akarná” dologról: én azért úgy gondolom, hogy a világ egyik vezető bim szoftver gyártójától nem volna túlzás egy ilyen igény; elvégtére is nem egy garázscégről beszélünk; oldják meg, van elég fejlesztőjük.
-S az archicad működésének alapfilozófiája még mindig nagyon robosztus, de egyre inkább azt érzem, hogy nem igazán mindig jó irányba mennek a fejlesztéseik: olyan dolgokhoz ragaszkodnak, ami már régen idejét múlta (pl.: miért kell az ablakot és az ajtót ilyen szigorúan elkülöníteni? meg miért kell még mindig fal a lehelyezésükre? vagy az összes kitöltés-jellegű eszköz (födém, tető, terepmodell, kitöltés, de még a vonal is) miért nem vonható össze egy eszközbe? metszet-homlokzat elkülönülés?), s olyan újdonságokat hoznak be koppra-hoppra, amik se nem illeszkednek a rendszerbe, se nem kiforrottak (függönyfal, héj, alakzat); s a meglévő eszközökben lévő további potenciálok sincsenek kihasználva (szabadon fölhasználható 3d-s munkalap -> a szigorú szint-struktúra teljes felszabadításával elég komoly távlatok nyílnának).

-valódi tulajdonságok implementálása: meglepően kevés dolog kellene hozzá. Pl. a kedvenc-kezelés internet alapúvá tétele: ha a gyártó cégek webes tárterületein tudnám böngészni (egy kellően intuitív, de lényegében egy fa-struktúrás felületen) a gyártó által megadott alapbeállításokat, annál már nem kéne sokkal több. A gyártó meg ráér elpöcsölni a milliónyi paraméter beállítgatásával.
-Mellesleg a graphisoft már elég korán érezte az internetben rejlő lehetőségeket: már a múlt evezredbeli verziókban is volt ftp és közvetlen internet kapcsolat a publikálóban és a könyvtárkezelőben; csakhogy az még eléggé nehézkes volt, így elenyésző számban használták. Közben viszont jött a web2 forradalma, amiről a graphi gyakorlatilag teljesen lemaradt. Lemaradt arról, hogy a webre való publikálás ugyanolyan 2 kattintásos üggyé vált, mint a winchesterre mentés; hogy a webes alkalmazások korlátai elképesztően intuitív UsereXperience megoldásokat eredményeztek; hogy a web2-es szolgáltatásokon megerősödött UX valódi iparággá fejlődött, s ma már nem csak webmail szolgáltatások polírozgatásáról szól.
-ha egy kicsit korrektebb grafikus szerkesztőfelület kapcsolódna a gdl elemekhez, akkor a jelenlegi (elképesztően buta gdl-lel) is megoldható lenne, hogy kb. 4-4 féle ablak és ajtó elemre volna szükség. Merthogy azért egy ablak nem valami nagy durranás bonyolultságú szerkezet: van egy tok- és egy nyílószárny szerkezete (ami egy térbeli 2d-s vonal mentén körbeküldött zárt poligon), van üvegezése, van egy féltucatnyi féle nyitási módja és nagyjából ennyi (van mondjuk vasalata is, de az a nyitási módból gyakorlatilag következik; stb.)

Összegzésül: olvasgattam egy pár dolgot erről az UX-ről (https://delicious.com/sityu/ux); nekem nagyjából az jött le, hogy ez egy teljesen új szoftverfejlesztési paradigma, teljesen új hozzáállás. Arról szól, hogy nem elmagyarázzuk a felhasználónak, hogy amit akar, azt hogyan tudná valahogy a szoftverünkkel megcsinálni, hanem hogy megpróbálunk olyan szoftvert fejleszteni, amivel azt és úgy lehet megcsinálni, amit szeretne. S ehhez egészen gyakorlatias és kiforrott eszközök, megoldások, módszerek állnak rendelkezésre, nem kell a melegvizet föltalálni. Egyszóval: az archicad jövője a UX-on áll vagy bukik, azon, hogy a UX-et teszik-e a fejlesztés központjába, vagy továbbra is maradnak az évenkénti 1-2 új feature csöpögtetésénél és a programozó-központú fejlesztésnél. (a UX szakember ugyanis se nem grafikus, se nem programozó, se nem ergonómus, se nem formatervező – de egy kicsit midegyik: ez egy új szakma)

Köszönöm a linket, nagyon hasznos volt.

Egy kérdésem maradt a témában:
Lehet-e a megjelenő 2D kép méretarányán változtatni?