Ez csak a gerincvezetékek esetében van így megcsinálva (azaz az a fő- és alelosztók és kisszekrények között), az épület kb 10000m2-er. Bár vártam, hogy ettől megrenccsen majd a gép, de döbbenet, hogy nem tette, pedig ebben nincs külön dedikált VGA és a proci is csak egy 6.gen i7-es

Őskor, Ókor, Középkor, Újkor, DualCore *** Köszönöm, hogy nem vagy megmondóember!

ez azért komoly
konnektorok bekötését is ki kell rajzolni?
Automatikát, könnyűáramot még bele, aztán tapsikolhat a kivitelező.
Amúgy remélem az ilyen szintű kidolgozásnak elkéritek az árát.
Mi max ilyen LOD 350 ig dolgozunk.

*bal felül ütközöl a gépésszel, kerüld ki

[ Szerkesztve ]

Dolgok amiket utálok: 1. fórumaláírások, 2. irónia, 3. listák

áhhh, konnektorokig nem Az azért nagyon kemény lenne. Csak tálca, és az elosztók közötti főbb nyomvonalak és kábelek (50-es, 95-ös keresztmetszet felett). És persze erős, gyenge, automatika, tűz (utóbbi kettőt még ki kell rajzolnom). Amúgy ez csak most először fordult elő, hogy ezt így meg keleltt csinálnom (de igazából annyira tetszik a tervezőtársaknak, hogy már kértek Tőlem egy hotelra is egy ilyen szintű rajzot )

Hát, az árát nem tudom (ahol ezt csináltam ott alkalmazott vagyok), én is remélem, amit most kértek Tőlem hotelt saját vállallásba, arra még nem adtam árat. Azt sem tudom mit lehetne elkérni ezért

* igen, ütközés az van, már tárgyaljuk az idálisabbútvonalat, de kemény mérkőzés van

[ Szerkesztve ]

Őskor, Ókor, Középkor, Újkor, DualCore *** Köszönöm, hogy nem vagy megmondóember!

azért nem reccsent meg, mert csak system family-vel dolgozol.
Ha mondjuk fogsz egy egész épületet, direct shape-el familybe alakítod és leraksz belőle 1000et a projektben egyáltalán nem fog lassulni a revited. Az instance paraméterekkel rendelkező dolgok lassítanak. Függönyfal pl ebből a szempontból nagyon rossz, már egy közepes méretű is lassítja a szoftvert. Minden egyes elem rajta instance.

[ Szerkesztve ]

Miért vegyem meg, ha 3x annyiért, 3x annyi idő alatt megépíthetem? ´¯`·.¸¸.·´¯`·.¸><(((º>

Mérnök napidíjat vedd alapul, egy ilyen szintű kirajzolás nagyban megdobja a munkára fordítandó időt. Nekünk sok idő volt míg be lett építve a céges árszabásba az a min. 1.5x több időráfordítás ami egy BIMes tervezés igényel egy ACadossal szemben.

Egy dolog, hogy eyecandy (én nagyon bírom az ilyeneket, ventilátor lapátját kirajzoltam amikor familyket gyárottam) de ezt meg kell fizetnie valakinek, és ne te legyél az aki az időddel fizeted az extra melót.

Ütközés : Tűzállót gépész kerüli minden mást elektromos vagy ad az építész nagyobb teret szerelni /csak viccelek, de igen nálunk is mindig nagy a harc/

Dolgok amiket utálok: 1. fórumaláírások, 2. irónia, 3. listák

Sziasztok!
Lehet, hogy pofonegyszerű a megoldás... A user azt szeretné, ha egy sheeten lévő nézetre rálógó Legend kitakarná a nézetet magát mindenestül.
A Sheetre helyezés sorrendje úgy van, ahogy kell lennie. A nézeten lévő elemek egy részét - itt most pl. a szaggatott vonallal látható Gridek - a Legenden lévő semmilyen maszk nem képes hideolni... Egyedül a szövegeknél működik, ha azok hátterét Opaque-ra veszem, de az is csak ott, ahol tényleges karakter van. Van ötletetek?

(Olyan bohóckodás persze eszembe juttott, hogy csinálok egy baromi nagy szöveget teleírva majdnem fehér betűkkel, ezzel megkapom a kívánt végeredményt, csak nem valami elegáns.:-)

Legend mögé egy fehér hátterű nem átlátszó fill?

A MÁV-nak öt ellensége van: a négy évszak, meg az utasok.

Az annotation kategória kerül utoljára rajzolásra, így az mindig felül lesz. Ha megfelelő sorrendben rakod le a nézeteket a 3D elemeket ki tudod takarni, de az annotation mindig elől lesz. Ennak gyanítom ahhoz van köze, hogy semmi ne tudja a titleblock-ot kitakarni amit leraksz, mivel az is annotation. A kitöltés pedig ugye Detail Item ami a model kategóriák között van. Lényegében egy nézet specifikus 2D model elem.
Szóval igen, annotation kell, ugyhogy csinálj egy Generic Annotation family-t, abba tegyél egy fehér fill-t instance paraméter a méretezéséhez, és utána azzal tudsz takarni. Utána már csak megfelelő sorrendben kell a nézeteket letenni

[ Szerkesztve ]

Miért vegyem meg, ha 3x annyiért, 3x annyi idő alatt megépíthetem? ´¯`·.¸¸.·´¯`·.¸><(((º>

Ez sajnos nagy nyomor, de API-val ezt is lehet kezelni, mi a Scope Box és Propagate Extents kiváltására csináltunk saját Tool-t pyrevit alá, egy nézeten kézzel beállítjuk, és minden párhuzamos nézetre átklónozza a 2D extenteket (többek között).
Erre érdemes indulni:
DatumPlane.SetCurveInView()
[link]

most agyalok hogy mennyire használnám ezt, de nem látok benne annyit hogy ezért egy plugint csináljunk. Alaprajzhoz meg tökéletes a scope box.
Én dynamoval csináltam olyan scriptet ami ugyan oda pozícionálja a nézeteket a tervlapon így ha Bluebeam-ben lapozod nem mozognak a nézetek.
Azóta lett erre valami ingyenes plugin is.

Miért vegyem meg, ha 3x annyiért, 3x annyi idő alatt megépíthetem? ´¯`·.¸¸.·´¯`·.¸><(((º>

Én meg egy ideje szeretnék a Dynamo-val foglalkozni hasonló témákban, de még nem volt rá kapacitásom.

A MÁV-nak öt ellensége van: a négy évszak, meg az utasok.

Ez a legjobb dolog revitben. Teljesen más szemléletű szoftver mert közösségileg fejlesztett volt eredetileg.
A legjobb egyedül végigrágni magad rajta, de ha kell segítség akkor engem kérdezhetsz.

Miért vegyem meg, ha 3x annyiért, 3x annyi idő alatt megépíthetem? ´¯`·.¸¸.·´¯`·.¸><(((º>

Rhino-Grasshoper és PARAMO megjelenésével ArchiCAD-ben is remek dolognak tartom. Dynamo-nak mondjuk a felülete az ami nem túl baráti, de ugyanez Revitnél is.
Ha lesz kérdésem, majd kereslek és előre is köszönöm.

[ Szerkesztve ]

A MÁV-nak öt ellensége van: a négy évszak, meg az utasok.

a grasshopper tényleg szép, de lényegesen többet tud dynamo a grasshopper archicad kapcsolatnál. Illetve nem kell Rhino licenszet venned (1000eur). Ott ugye modell elemeket tudsz piszkálni, itt pedig mindent amit a revitben elérsz: tervlapokat, nézeteket, ezek összes beállítását, paramétereket, linkeket, 2d elemeket stb.
Nyithatsz vele egy új revitet és kinyomtathatod belőle az összes PDF-et automatikusan, majd bezárhatod. Mindezt mondjuk naponta időzítve. A grasshoppert az archicad api limitálja ami revithez képest sajnos limitált. Ez talán az egyetlen dolog amiben revit nálam sokkal jobb. Bár ez pont sokakat nem érdekel

Miért vegyem meg, ha 3x annyiért, 3x annyi idő alatt megépíthetem? ´¯`·.¸¸.·´¯`·.¸><(((º>

Accepted assolution. :-P

Illetve nem kell Rhino licenszet venned (1000eur).

Cserébe az Autodesk licensz ami léptékkel drágább mint az AC+Rhino szerintem...

Ott ugye modell elemeket tudsz piszkálni, itt pedig mindent amit a revitben elérsz: tervlapokat, nézeteket, ezek összes beállítását, paramétereket, linkeket, 2d elemeket stb.

Szerintem ez csak letölthető kiegészítő mennyiség kérdése mindkét platformon...

Nyithatsz vele egy új revitet és kinyomtathatod belőle az összes PDF-et automatikusan, majd bezárhatod. Mindezt mondjuk naponta időzítve.

Erre külön Add-in-t fejlesztettünk. Mondjuk eleve felháborítónak tartom hogy nincs egy nyomorult publikáló Revit-ben.

A grasshoppert az archicad api limitálja ami revithez képest sajnos limitált.

Szerintem ez hamarosan meg fog változni, addig meg simán átlépünk rajta vagy megkerüljük.

A MÁV-nak öt ellensége van: a négy évszak, meg az utasok.

Az a gond, hogy Scope Box csak 3D Extentet tud fogni, és amikor alaprajzilag darabolnod kell egy épületet akkor cseszheted, mert a Crop úgyis átdobja 2D-re, szóval lefutottuk a köröket, és bőven ki van használva az eszköz.

A legtöbb Viewport pozícionáló az csak a viewportok középpontját alignolja, nagyon sokszor nem jól működik, mert pl hiába van 2 alaprajzon ugyanaz a Scope Box, hag az egyikből jobban kilóg valami annotation, akkor máris más lesz a Viewport mérete, ergo az alignolás is szar lesz. Mi pont ezért fejlesztettünk egyet erre is, ami a viewportokat a bennük lévő nézet koordinátarendszere alapján alignolja, áttranszformálva azt a papírtérbe.
Továbbá az OCD-m sikítva rohan ki az irodából, ha Scope Boxozni kell, mert az a nyomorult olyan mint a gyurma, esélytelen pontosan beállítani a méreteit, és ha két modell között kell azonos Scope Boxokat beállítani, akkor jön az eyeballing amitől meg a falat verem. Ilyen az élet

Hát én nézegettem az Archicad API-t de elég gyorsan elengedtem, nem vagyok hajlandó megtanulni a C-t, nem ér annyit. A nemrég bemutatott python wrapper ígéretes, de nagyon gyerekcipőben jár még, ezen a területen (API) a Revit szerintem fényévekkel előrébb jár.

Szerintem ez csak letölthető kiegészítő mennyiség kérdése mindkét platformon...
Nem. Revit API konkrétan enged minden gombot megnyomni, minden hibaüzenetet kilőni. Ezért lehet automatizálni, mert (szinte) minden felugró szart kinyomhatsz API-val (egy-két kivétel van pl a revit első indításánál az a csatlakozz a felhasználói élmény javításához ablak). Amire kattinthatsz a UI-n azt APIval is lehívhatod beleértve az összes menüpont összes gombját. Ez sajnos AC esetében közel sincs így, ott gyakorlatilag a szerkesztőablakon belülre vagy korlátozva.

Erre külön Add-in-t fejlesztettünk. Mondjuk eleve felháborítónak tartom hogy nincs egy nyomorult publikáló Revit-ben.
Van ingyenes publikáló plugin, ProSheets a neve, szerintem elég jó. Automatizáláshoz is van kész megoldás, nem biztos, hogy megéri fejleszteni. Imaginit Clarity a neve, fut szerver-kliens módban, tehát lehet egy külön PC amire az egész iroda küldi az export feladatokat.

Miért vegyem meg, ha 3x annyiért, 3x annyi idő alatt megépíthetem? ´¯`·.¸¸.·´¯`·.¸><(((º>

Az ugye megvan, hogy azért enged minden gombot megnyomni a Revit mert alapból egy erősen félkész "törzsprogram", ami előző életében táblázatkezelő volt és teljesen más célú a fejlesztése mint az ArchiCAD-nek?
Jelenleg mindkét platformra vannak saját kiegészítők fejlesztés alatt, mindezt azért mert inkább saját fejlesztést készítünk mintsem kifizessünk további helyenként súlyos pénzeket az Autodesk eleve borsos árán túl...szép ez az amcsi modell csak nem a felhasználónak származik belőle előnye.

Röviden: a két szoftver teljesen eltérő múltal és más szándékkal íródott, így mindkettőnek más és más "öröksége" van. Mindkét oldalt van bőven hova fejleszteni meglátásom szerint.
Építészeknek tervkészítéshez sajnos jelenlegi kialakításában a Revit önmagában kevés és drága platform belföldön.

A MÁV-nak öt ellensége van: a négy évszak, meg az utasok.

Koszonom, hogy ilyen jol megfogalmaztad, az en problemam is hasonlo. Nalunk egy revit fileban van egy teljes lakopark kirajzolva negyzetracs halon, egymastol nem tul messze igy neha a scope box is problema.
Ha jol ertem ti sajat magatoknak irtatok programot pyRevit-ban? Nekem a dynamonal megall a tudasom sajnos, a cegunk pedig kicsi hogy legyen kapacitasunk komolyabb programok fejlesztesere, de ezek szerint van ra mod.
Kerestem fizetos plugint, de meg nem talaltam, ha valaki ugyesebb es talalt az kuldhet nyugodtan egy linket, elore is koszonom!

[ Szerkesztve ]

A bugyi nem a legjobb dolog a világon. De közel áll hozzá

Értem a problémát. De ehhez se kell nagy fejlesztés pythonnal meg átszámolt koordináta rendszerekkel.
Kell egy view template amin nincs annotation. Nézeteid scope boxxal határoltak.
Dynamoval:
1) átállítod a view template-et az annotation nélkülire
2) align box centerrel
3) visszaállítod az eredeti view template-et

10 max 15 node az egész és teljesen automatizált, dynamo playerből 1.0 user is használhatja

[ Szerkesztve ]

Miért vegyem meg, ha 3x annyiért, 3x annyi idő alatt megépíthetem? ´¯`·.¸¸.·´¯`·.¸><(((º>

Kozben talaltam is, ami szamunkra jelen pillanatban elegendo.

[link]

A bugyi nem a legjobb dolog a világon. De közel áll hozzá

Igen, ideális esetben elég lehet, de viszonylag gyakori helyzet, hogy a földszint cropja nagyobb mint a többi szint, a csatlakozások miatt, mégis szükséges az ilyen egyedibb rajzokat is az általánoshoz igazítani. Igazából mi nem nagyon használunk Scope Box-ot a 0 API támogatása miatt, hanem a Crop Boundarykat is API-val klónozzuk szét egy forrásnézetről, így nem vagyunk rákényszerítve a téglalap formájú crop-ra se pl. Mi is bejártuk az ilyen "egyszerűbb" utakat, de mindig volt olyan eset, amikor az épp nem volt elég jó.

Tulajdonképpen mi a kisebb QualityOfLife fejlesztéseket csináljuk pyRevit alá, és a nagyobb, komplexebb Addinokat pedig ahogy illik C# ExternalApplication-ként, de ezek jellemzően külső DB kapcsolatokkal bírnak, integrálódnak valamennyire a vállalatirányítási rendszerbe is, és azon természetesen nagyobb, kevésbé Revit specialista csapat dolgozik. Dynamot mi teljesen elengedtük. Ekkora irodában managelhetetlen, teljesítmény terén is komoly hátrányban van, nem lehet debugolni, rendes hibakezelés sincs benne, a Dynamos python szerkesztő is kritikán aluli egy rendes IDE-hez képest, stb... Egyébként szeretek az ilyen dolgokkal pöcsölni, ha úgy van szívesen tudok segíteni ilyen téren.

[ Szerkesztve ]

Ez oké, de azt azért te is elismered, hogy nem tipikus, hogy van fejlesztő/programozó egy mérnök irodában. Vagy csak egy mérnök aki tud 1-2 programnyelvet. Lehet a dynamót elengedni, meg nem szeretni, de a feladatok nagy részére tökéletesen elég, jellemzően csak nagy geometrikus feladatoknál fekszik meg. Ha tudod használni egy csomó egyszerű nagyon gyors összerakni benne főleg adat managementhez. Nálunk is van fejlesztő, most már kettő is, de nem terheljük őket ilyen kis dolgokkal. Ha a dynamo lassú is, de lefut mondjuk 10 perc alatt akkor sem érdemes terhelni őket.

Miért vegyem meg, ha 3x annyiért, 3x annyi idő alatt megépíthetem? ´¯`·.¸¸.·´¯`·.¸><(((º>

Ne értsd félre, nem akarlak én semmiről sem meggyőzni, csak elmeséltem a személyes tapasztalataimat. Általában mindig úgy indul, a hogy a mérnöknek kevés a kapott funkció, és elkezd kiegészítő megoldásokat, automatizálási lehetőségeket keresni, aminek kvázi első lépése a dynamo. Valóban kis, pár személyes irodákban ennél tovább nem is érdemes menni, esetleg komplexebb igényeket kiszervezni külső fejlesztőnek, ha megtérül. Mi is dynamoval kezdtük, csak hamar kevés lett. Ettől függetlenül a tervező mérnököknek tartunk dynamo oktatást, és bátorítjuk őket, hogy a saját munkafolyamataikba építsék be, hiszen sokkal hatékonyabbak tudnak lenni vele. Akinek nincs efféle affinitása, az lepattan róla, aki meg rápörög, az viszonylag hamar tovább is lép. Nálam úgy nézett ki, hogy először dynamo, de hamar meguntam a millió+1 package keresgetését letöltését updatelését, pláne, hogy a dynamo keresője híresen lassú, és frusztrált elég sokat, így már azon kaptam magam, hogy arra használom a dynamot, hogy berakjak 1-2 alap node-ot, és python blockba megírom amit szeretnék. Aztán amint megtaláltam a Revit Python Shellt elég hamar el is engedtem, aztán már csak a másoknak készített dolgokat csináltam dynamoba, mert azt viszonylag egyszerű volt már másnál is futtatni, pláne custom packagek nélkül. Aztán ahogy kitapasztaltam a pyRevitet már gyerekjáték volt egyedi megoldásokat disztributálni soksok munkaállomás között.
Nálunk a fejlesztő csapat főleg adatelemzésekkel, adatbázis építéssel foglalkozik ami pl az ajánlatadást segíti, illetve teljesen saját költségvetés készítő programot fejlesztenek ami natív Revit alapú, beépülő, de ezek komplex megoldások. Az egységsugarú Revit felhasználónak készülő apró kis toolok jó részét én csinálom, de nem fejlesztőként, csak sima építészmérnöki végzettség van a hátam mögött, de érdekel a programozás, így mindenki jól jár a végén.

Én a dynamo után C#-ban kezdtem el fejlesztgetni céges toolbart. Azon kívül, hogy érdekelt, egyelőre túl sok hasznát nem látom a mi szintünkön. Ugyanazt a feladatot dynamóval vagy pythonban sokkal gyorsabban össze lehetne rakni.
Visual Studióban debuggolni mondjuk nagyobb élmény, mint a dynamóban találgatni, hogy mi nem megy a python kreálmányodban.

Sziasztok!
Egy újabb gondolkodós kérdés. A Windows category ugyebár úgy működik, hogy a View Range-en belül a Cut Plane fölött is látszik, egészen a Topig. Ezt azonban úgy szeretnénk, hogy ezek az ablakok elmetszett állapotban látszódjanak. A kevésbé szerencsés, bár célravezető megoldás eddig az volt, hogy Plan Regionöket rajzolgatunk az ablakok köré. Gondoltam arra, hogy az ablak familyt tele kellene tolni symbolic line-okkal, amelyek nem-elmetszett állapotban is a metszet vonalait jelenítik meg, de ez veszélyes. További kókány ötleteim lennének meg, de biztos van erre valami intelligens megoldás...

Jól értem, hogy azt szeretnéd, ha egy ablak a cut plane felett van, akkor csak a fal látszódjon, az ablak ne?

[ Szerkesztve ]

Miért vegyem meg, ha 3x annyiért, 3x annyi idő alatt megépíthetem? ´¯`·.¸¸.·´¯`·.¸><(((º>

Lehet, nem fogalmaztam pontosan. Szeretném az ablakot látni, de úgy nézzen ki, mintha a Cut Plane keresztezné.

Ez alaprajzon így működik most is. A jobb oldali ablak cut plane felett van, de úgy néz ki, mint ami el van metszve. Piros vonal a cut plane-em.

[ Szerkesztve ]

Miért vegyem meg, ha 3x annyiért, 3x annyi idő alatt megépíthetem? ´¯`·.¸¸.·´¯`·.¸><(((º>

Fel tudnal rakni egy képet pontosan, hogy is néz ki a plan regionos trukk utan? Szóval az érdekel, hogy mi lenne a cél?
Az ablakok a saját modelljeitek? Van mód csak az ablakokat (mehet az egész de akkor sok lesz a sallang) egy külön familybe tenni, ott egy plan viewet késziteni azt úgy beállitani ahogy azt szeretnéd láttatni és aztán belinkelni az eredeti revit fileba, ott pedig ki tudod válsztani hogy azt a plan viewt használja.
Lehet, baromág amit mondok, itt daninet a guru

[ Szerkesztve ]

A bugyi nem a legjobb dolog a világon. De közel áll hozzá

"egy külön familybe tenni"

egy külön revit fileba gondoltam nem familybe!

A bugyi nem a legjobb dolog a világon. De közel áll hozzá

Saját ablakunk van, de kipróbáltam egy gyárival is. A pirossal jelölt lenne a cél.
A Plan Region csak annyit tenne hozzá, hogy a Cut Plane vonalát feljebb emelem az ablak körül.
(A különálló rvt file-os megoldással kapcs ugyanaz a megérzésem, mint a Plan Regionnel. Valahogy egyszerűbben jobb lenne.)

Itt valami nem jó, vagy a family-vel vagy a revit fájllal. Fentebb mutattam ez hogy működik. Megtennéd, hogy valahova felrakod, és megnézem

[ Szerkesztve ]

Miért vegyem meg, ha 3x annyiért, 3x annyi idő alatt megépíthetem? ´¯`·.¸¸.·´¯`·.¸><(((º>

https://easyupload.io/eypc77
Szűz template-be raktam be. A vizualitás kedvéért raktam rá egy Visibility override-ot, hogy átszínezze az ablakok "Cut"-nak minősített alkotórészeit.

Megnéztem, több gond is van a családdal. Egyébként elég profi, csak az ablak family alapvető szabályait nem követi
A fő gond az, hogy parapet nélkül a referencia szintre lett modellezve az egész. Próbáltam elmozdítani, de annyi paraméter van ami egymásra épül, hogy nem erőlködtem a dologgal.
Ha megnyitsz bármilyen OOTB ablak family-t revitből, látod majd, hogy van egy fal, abban egy opening, és az opening alján egy Reference Plane ami "Bottom"-ként van hivatkozva. Ez a ref plane egy "Default Sill Height" nevű paraméterrel van a referencia szinttől beállítva. Ez nálatok nincs meg, az ablak a nulla referencia szinten van és a beállított alacsony cut plane ehhez képest lett értelmezve.
Hogy tiszta legyen, egy ablak akkor számít elmetszettnek alaprajzon, ha a referencia szint és a felső "Top" reference plane között megy át a cut plane.
Az alábbi képen a zöld vonal az egyes family instance-ok referencia szintje, a kék terület pedig a ref szint és a top közötti terület ahol az ablak elmetszettként van értelmezve. Ez jól mutatja mi a probléma.

Továbbá void cut-ot használtatok a family-ben nem opening-et ahogyan az OOTB family-k használják. Ebben nem vagyok biztos, de gyanítom ennek is van valami nyűgje, kerülni kellene.
Egy kicsit több nested family-t kellene használnotok, sokkal egyszerűbb lenne ilyen ablakokat/ajtókat csinálni. Ugye a revit family hierarchikus felépítésű kellene legyen, szóval megmodellezel egy keretet, egy ajtó lapot, egy kilincset, majd ez a 3at összerakod egy ajtó family-be. Ha mindent egy helyen modellezel nagyon küzdelmes, szerintem ezt észrevettétek. Ráadásul a végén már átláthatatlan is.
Az egész lényege, hogy csinálsz pl egy ablakkeretet adott paraméterekkel majd azt minden ablaknál használjátok, így biztosított az adott paraméter készlet egységes legyen.
Kicsit túl van bonyolítva.
Ezt gondoljátok át.

[ Szerkesztve ]

Miért vegyem meg, ha 3x annyiért, 3x annyi idő alatt megépíthetem? ´¯`·.¸¸.·´¯`·.¸><(((º>

Aha, nagyjából értem. Mentségemre legyen mondva, hogy ezt én "így örököltem", és mostanában olyan projektek voltak, ahol az ablakoknak viszonylag kevés jelentőségük volt.

Most én is egy 2016-os modellen dolgozok amit akkori kezdők csinálta mindenféle koncepció nélkül. Vannak érdekességek

Miért vegyem meg, ha 3x annyiért, 3x annyi idő alatt megépíthetem? ´¯`·.¸¸.·´¯`·.¸><(((º>

A Default Sill Height résszel egyet értek, bár sajnos tökre semmi értelme ezt így megtekerni, dehát Revit. A teljes family visibility logika egy őskáosz, nem tudom melyik okos találta ki, hogy ezt category függővé kell tenni, hogy melyik category metszhető, melyik nem, melyik generálja dinamikusan a project cut plane magasság alapján az elmetszet grafikát, melyik nem, illetve ott a harmadik kupac, ahol a familyben megadhatod, hogy a cut megjelítést familyből vagy projektből vegye (structural column, framing) Annyit módosítanék csak az ábrádon, hogy a jobboldali esetben a kék zóna kiterjedése nem a host levelig tart, hanem az ablak alatt "Default Sill Height" magasságban ér véget, szóval statikus, de kb ez történik.
Az openinges résszel viszont tökre nem értek egyet, ha bármilyen komplexebb nyíláskáva kialakításra van szükség, akkor kénytelen vagy voidokkal vágni a hostot, hiszen a gyári opening elem az csak egy kvázi végtelen void extrusion, de sima voidokkal nem engedi kombinálni

apropó korlátok, nálunk most véglegesedik egy új workflow, kis sneakpeak: https://www.youtube.com/watch?v=pcH3iYI4mV0

[ Szerkesztve ]

Ez elsőre nem teljesen állt össze, de a másik videód nagyon tetszik.

Ez Dynamo-ban készült?

A MÁV-nak öt ellensége van: a négy évszak, meg az utasok.

Az oszlopok és panelok adaptive family, a handrailt egy pyRevit alá írt saját script manageli. Olyan mintha egy in-place sweepet csinálnál 'Pick Path'-el, megadható neki a profil, offset, material, és az alatta lévő line based familyben lévő referenciára generálódik. Mindjárt csinálok egy hosszabb videót a workflowról.

Az hamarosan elérhető lesz az Autodesk Storeban

Kicsit kapkodósan, de ilyesmi: https://www.youtube.com/watch?v=WDoW6iU761c

Sziasztok!

Ha egy megbízó kéri a revit file-t is a projekthez, és a tervezés hajlandóságot mutat ennek megosztására, milyen pénzben kifejezhető értéke van egy ilyen kész, feltöltött proejtfile-nak?
Komplett épületgépészet: Hűtés-fűtés, légtechnika, sűrítettlevegő, gázellátás.

Mert nekem konkrétan halvány lila fingom sincs, én azt mondtam, hogy két mérnök két hónapot dolgozott a mi revites munkakörnyezetünk kialakításán, de ez már lehet elavult.
Mi ragaszkodtunk mindig is a nyers file ki nem adásához.

Dolgok amiket utálok: 1. fórumaláírások, 2. irónia, 3. listák

Az ilyesmit a projekt elején szokták tisztázni, ha közben jön fel ez az igény, akkor lenyeli az iroda első alkalommal további megrendelés és jó viszony reményében, vagy mert elég magas a tervezési díj.
Ugye ilyenkor a kiadott fájlt azért illik kipucolni és akkor nem megy vele minden irodai standard.

A MÁV-nak öt ellensége van: a négy évszak, meg az utasok.