Hirdetés
- Egy tucat Galaxy vált One UI 6.1.1-re
- Fillérekért hazavihető a CMF Phone 1
- Redmi Note 9 Pro [joyeuse]
- MIUI / HyperOS topik
- Vodafone mobilszolgáltatások
- Xiaomi 14 - párátlanul jó lehetne
- Xiaomi 14 Ultra - Leica hercegnő
- Drágább lesz a Galaxy S24 FE
- Redmi Note 11 és 11S - biztos alapra jobb építeni
- Android szakmai topik
Hirdetés
-
Csokornyi S25 Ultra renderkép érkezett
ma Impozánsan tiszta a vékony keretes dizájn.
-
Akciófigyelő 2024: PlayStation - Bolygónyi kedvezmények
gp Számos játék szerezhető be az eredeti áránál olcsóbban, érdemes lehet a teljes listát átböngészni.
-
A cégek zöme már AI-t használ
it 200 millió heti szinten aktív felhasználója van már a ChatGPT-nek, miközben a 100 milliárd dollárosra értékelt OpenAI-ba az Apple és az NVIDIA is befektetne. Az OpenAI és az Anthropic aláírt az amerikai kormánnyal az AI-kutatás kapcsán, míg a Meta modelljeit bankok és tech cégek vezették be.
Új hozzászólás Aktív témák
-
Ranger^41
aktív tag
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] -
Ranger^41
aktív tag
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
-
Ranger^41
aktív tag
-
Ranger^41
aktív tag
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ó.
-
Ranger^41
aktív tag
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 ]
-
Ranger^41
aktív tag
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. -
Ranger^41
aktív tag
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 -
Ranger^41
aktív tag
válasz
Raysen623
#345
üzenetére
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.
-
Ranger^41
aktív tag
Ezt igazából lehetetlen beárazni. Én azt gondolom, hogy más nem fogja tudni elég hatékonyan felhasználni az így szerzett elemeket "as-is", anélkül ,hogy a saját standardjébe illesztené, az meg sokszor nagyobb effort, mint rendesen megcsinálni. Én annak a híve vagyok, hogy az ilyen contentet nem érdemes védeni, igazából nem is lehet, szerzői jogi keretek közé sem lehet behúzni, mert az Autodesknek több joga van a te általad készített dolgokhoz mint saját magadnak, szóval terjedjen csak a jó content a piacon, és legalább az általános színvonalat tudja húzni felfele, ha igazán jó. Ami szar, az meg úgyis kikopik.
-
Ranger^41
aktív tag
Revit server katasztrófa, nem véletlenül állítottak le az egész szarkupac fejlesztését, ezerszer inkább egy dedikált fileserveren lévő central file alapú worksharing a javasolt. VPN-el viszont óvatosan, még site-2-site VPN esetén is simán beszakadhatnak a fileok, nagyon érzékeny a kapcsolat minőségére. FunFact: a teljes bim360, ma már acc worksharing alapjaiban ugyanazt a revit server backendet használja, csak el tudják adni az embernek sokezer dollárokért a Reviten felül.
Szerintem, ha projektkövetelmény az acc(bim360) akkor be kell árazni az ajánlatba pofátlanul.[ Szerkesztve ]
-
Ranger^41
aktív tag
van a forge ökoszisztéma ami felhasználóként bim360/ACC-ben realizalodik, fejlesztokent meg tucatnyi api-ban, de az egész mögött a cloud worksharing "modul" az kvazi egy webre ültetett oskovulet revit server. Ha megnezel egy revit journalt láthatod a skyscraper urlt amivel kommunikal, na az volt az első webesitett revit server projekt neve, csak ele húzták az egész forge alapú vilag megváltást.
bim360 már jo ideje ACC, de az is egy szép story, volt a bim360, meg a plan grid, egy újabb third party service amit megvasarolt az autodesk, hogy aztán teljesen rebrandelje és eladja kis arculat valtas után mint új bim360, de sikerült belőle orbitális adminisztrációs káoszt teremteni, redundáns, nem működő adminisztrációs funkciókkal. gyász -
Ranger^41
aktív tag
válasz
Raysen623
#408
üzenetére
Nem teljesen értelek most, ACC-n ugye opcionális a naming standard alapján kiolvasott atttribútumok használata, ott is megadhatóak (igaz csak utólag) hozzáadott paraméterek (attributes). Azt szerintem fontos kiemelni, hogy az ACC verziózása, meg a dokumentum revíziók az két teljesen független dolog, ami egyébként sok embert összezavar.
-
Ranger^41
aktív tag
Folyóméter sajna ebből sem lesz. Mármint a dynamo tudni fogja, de directshape-hez nem tudsz paramétert adni, nincs hova beírni. Továbbá, ha lejtésben van a terep, akkor a profilt is szépen meg fogja csavarni. Én szívem szerint nem kezdenék el Revitben környezetet modellezni.
-
#490
Ranger^41
aktív tag
vidékiürge
#488
Ranger^41
aktív tag
-
Ranger^41
aktív tag
Ó. 2014-et nagyon gyorsan engedjétek el. Csak szívni fogtok vele. Ahhoz rendes Ifc exporter sincs, a beépített szutyok hulladék. A külön telepíthető, ami a legfrissebb 3-hoz van aktívan fejlesztés alatt valamivel jobb, de az is sok sebből vérzik.
Ráadásul 2014ben a széttákolt koordinátarendszert se tudod rendesen a helyére húzni, mert se reset coordinates funkció nincs, se az internal origin megjelenítését nem lehet felkapcsolni. API-val helyrerángatható, de ultra nyomor.[ Szerkesztve ]
-
Ranger^41
aktív tag
2. BCF nyílt adatcsere formátum: lehetővé teszi az építményinformációs modell (BIM) IFC fájlformátumban való megjelenítéséhez kapcsolódóan geometriai, illetve alfanumerikus információk hozzárendelését a térbeli modellhez
Tessék?
És mi a helyzet azzal az állami építési tételrenddel, amire az egész épülne? Gondolom még a kanyarban sincs, bár Lázár Miniszter Úr biztos nagyban dolgozik már rajta
Új hozzászólás Aktív témák
Hirdetés
Állásajánlatok
Cég: Ozeki Kft
Város: Debrecen
Cég: Ozeki Kft
Város: Debrecen