Milyen újdonságok jelentek meg az AC11 óta?
Roppant érdekes táblázat jelent meg a Graphisoft honlapján, az ArchiCAD 11-es verziójától kezdve a most megjelenő 16-os verzióig láthatóak az egyes verziókban felbukkant újdonságok. Ki-ki eldöntheti, hogy az egyes verziók között sok vagy kevés volt a fejlődés. A magam részéről úgy tartom, hogy voltak nagyon fontos verziók és voltak kevésbé fontosak
A nyitókép a táblázatnak csak egy kis részét mutatja. A teljes táblázat innen tölthető le
[poll id=”58″]
Hozzászólások (6): megnézem
sityu
2012. május 4. péntek 06:39
Lehet azon vitatkozni, hogy mik voltak a változtatások; meg hogy fontosak voltak-e. Én is írtam már ezekről. S többször írtam már arról, hogy milyen koncepcionális ügyeket hiányolok már régóta. Megteszem újra:
1) van egy sor fölösleges kötöttség, korlátozás, amiknek megszüntetése sok problémát megelőzhetne:
1.1) hasonló tipusú elemek egységesítése (és ebből következően egymásba alakíthatósága – az elem beállításain belül lehetne kiválasztani, hogy az adott elem melyik típus legyen – megmaradhatnak a külön ikonok az eszköztárban):
1.1.1) pl.: poligon típusú elemek: a 2d kitöltéstől (vonallánctól, helyiségcimkétől)), a födémen át, a terepmodellen keresztül a tetőig (sőt akár a héj elem is bevonható volna)
1.1.2) pl.: a metszet-homlokzat éles szétválasztásnak se sok értelme van (bár ez nem kritikus kérdés, de elegáns volna, ha átalakíthatók volna egymásba) – apropo, metszet: ferde síkú metszet…
1.1.3.) ablak-ajtó-tárgy-lámpa szétválasztás ellen is több érvet tudnék fölhozni, mint mellette; ne adj isten: ablak-ajtó lehelyezés fal nélkül…
1.1.4) 3d-s tartalmak a munkalapon -> munkalapokat a szintek helyett: szabadon szervezhető munkalapok (szinteknek kinevezhető munkalapok), épületmodulként használható munkalapok (mint a kapcsolt modulokat, a 3d-s munkalapot is több példányban lehessen elhelyezni egy másik munkalapon)
1.2) eleve macerás, hogy egy külső rajzot el lehet helyezni az alaprajzon, de munkalapot nem;
2.) régi eszközök működésének felülvizsgálata:
2.0) kattintásszám csökkenthetősége: seregnyi esetet tudnék sorolni, ahol kis átalakítással csökkenthető volna a kattintásszám
2.1) kottázás: az asszociatív kottázás utólagos szerkeszthetősége, tehát ne csak felvillanjon, az asszociatív pont, hanem nyugodtan fixen megjelenhet, szerkeszthető pontként, a kotta kijelölésével (természetesen ez a működés egy globális kapcsolóval kikapcsolható volna, s ezáltal maradhatna a régi működés is). Ne adj isten: a kottázás vissza is hathatna az elemre, megadva a kotta értékeknél a fix, vagy képlettel kiszámolt értékeket. Tehát a kottázás egy alapvető szerkesztő eszköz lehetne, ezáltal a méretek megadásával automatikusan a végleges kották is fölkerülhetnének a rajzokra.
2.2) fóliák: jó dolog a szabad fóliakezelés, de egy idő után kezelhetetlenné is válhat, célszerű lenne valamiféle dedikált fóliakezelés: bizonyos elemek csak bizonyos fóliákra helyezhetők lennének (vagy, ha nem a dedikált fóliára akarjuk tenni, akkor egy plusz rákérdezés). Standardizált fóliák, fóliatipusok (más irodák terveivel történő együttműködés óriási kavarodásokat tud jelenteni).
2.3) anyag-, kitöltéskezelés: a mátrixos megjelenítés fölött is eljárt már az idő, sok anyag, ill. kitöltés esetén nehézkes; fa-struktúrás megjelenítés hasznosabb lenne;
2.4) Terv térkép fa struktúra kibővítése az elhelyezett elemek fa-struktúrás megjelenítésével (kibontható-becsukható csoportokkal, esetleg fóliákkal)
3.) Új eszközök finomítása (a működési részletekben is megbújik némi csiszolgatni való):
3.1) A különböző nézetekhez használt virtuális pauszok kezelése nem konzekvens: van, hogy a pausz docker-ben megmarad a korábban használt pausz, de nem mind, ill. sok fölösleges is megjelenik. (nekem volt olyan tervem, ahol százas nagyságrendű dwg-s géprajzot kellett használnom pauszként a gépalapok tervezése során, és pár hetes kihagyás után elég nehéz visszaidézni, hogy az adott esetben 4-5 verziójú rajz közül épp melyiket kell használni).
3.2) alaprajzi metszősík: szerkeszthetőség 3d-ben (természetesen törésvonallal; természetesen alaprajzi szerkeszthetőséggel).
4. Javasolt új eszközök: a Morph-fal már az utolsó komoly rajz- ill. modellező-eszköz hiány is megszűnik, ezért én inkább a „productivity”, „usability” tipusú eszközökben látnám a fejlődés irányát. Mint pl.:
4.1) tervadat- és verzió-kezelés: ügyfelek, fejléc-adatok, tervből származtatható adatok kezelésére célszerű volna egy kezelő eszköz.
4.2) beállítás-kezelés: nem csak a programbeállítások xml-es kezelése (bár azon is volna mit fejleszteni), hanem a kedvenc-kezelés. Korábbi tervekben használt beállítások fa-struktúrás, automatikus kezelése, interneten elmenthetősége. Engem rettenetesen frusztrál, hogy pl. az ablakok alap-beállítása semmiféle magyar méretrendszernek nem felel meg, ezért minden ablaknál 10-15 paramétert kell egyesével beálligatni (pl. a különböző osztású kapcsolt gerébtokos ablakoknál), pedig tudom, hogy ezt már korábban egyszer-kétszer beállítottam, de az adott tervájl előkeresése és a beállítások átvitele sem gyorsabb, mint a manuális beállítgatás.
Hirtelenjében ennyi. Azt gondolom, hogy ezek jó némelyike egyszerűbben megoldható változtatás lenne, mint pl. a Morph bevezetése, s jó néhány verzióváltásra elegendő muníciót biztosíthatna a Garphisoftnak. Amire szerintem szükség is lenne, mert ez a 16-os fícsörlista elég haloványnak tűnik. Egyedül talán az ecodesigner implementálás tűnik komoly, napi gyakorlatban is hasznos újításnak (nekem legalábbis nem a szabadformálású modellezés hiánya volt a legnagyobb gondom).
RobinHood
2012. május 4. péntek 09:01
AC16-al lehet energetikia számítást is végezni végül, ez az ECO designer itt benne?
Táskai Zsolt
2012. május 4. péntek 09:02
Két apró dolgot szeretnék kiemelni.
Miklós újra értékes anyagra hívta fel a figyelmet, viszont a szöveg és a kép együtt arra enged következtetni, hogy ennyi a táblázat, pedig ez csak a _modelezési_ rész fejlődését mutató részábra. Amúgy feltehetően sokaknak tényleg ez a legfontosabb, ez is az első a doksiban…
A linkelt dokumentumban „Library” rész utolsó három sora ebben a formában tárgytalan, illetve külön csoportba tartozna talán. Ezt már jeleztem a megfelelő ügyosztálynál, később valószínűleg javítják.
Koós Miklós
2012. május 4. péntek 10:39
[re=84076]Táskai Zsolt[/re]: Zsolt, köszönöm az észrevételedet!. Teljesen jogos, javitottam, mert a megfogalmazásom így valóban félreérthető volt.
RobinHood
2012. május 5. szombat 20:53
AC12 után most érzem azt hogy volna értelme 16-ra átmenni. Előremutató. Grtaulálok. Uppgrade 2- (3) évente elegendő.
Táskai Zsolt
2012. május 9. szerda 10:03
[re=84076]Táskai Zsolt[/re]: Javították a PDF-et, már jó a Library rész is. A fenti megjegyzésem vége így már figyelmen kívül hagyható.