Tak takhle to bude s tím open source CADem

14.3.2013 14:34 | Přečteno: 3796× | apps

Bude se jmenovat Cadus. Latinsky to slovo značí džbán, což jest nádoba sloužící k jímání a dopravě obtížně uchopitelných -- sypkých a tekutých -- látek. Stejně tak program Cadus slouží k jímání a předávání obtížně uchopitelných myšlenek a představ. Taky se dá odvodit akronym: Computer Aided Design - Universal System.

Latinsky lze pojmenovat vývojových větví:

• testing/unstable: Cadus caducus -- džbán padavý zkrátka vývojová verze.
• stable: Cadus tenax -- džbán drživý. Držák do produkčního prostředí.

Pokud vývoj selže, přejmenujeme ho na Cadus Cadaverus, džbán mrtvolný.

Nebudeme šetřit ambicemi, chceme pokrýt stavařinu, strojařinu i elektrotechniku.

V zásadě děláme GUI a další aplikace kolem BRL-CADu, který chápeme jako jádro. Podpoře více jader se meze nekladou.

Bude tam správa projektů, 3d modelování a 2D výkresy.

Vývojáře motivujeme finančně, systémem bobříků-reputací a referencemi pro komerční sw vývojáře.

Vydavatel: obecně prospěšná společnost, jejímž smyslem existence je vývoj tohoto programu. Spravuje autorská práva programátorů a vydává kód pod svobodnou licencí. Sbírá dary na transparentní účet a z nich vyplácí programátory.

Nyní něco úplně jiného a sice, co jsem schopen udělat:

• Vyrobit a spravovat web na Drupalu se všemi náležitostmi projektu
• Navrhnout uživatelské rozhraní
• Na základě diskuse udržovat Roadmap a síťový diagram projektu

Z diskuse pod tímto článkem vyplynulo několik vcelku konkrétních problémů. Jsouto:

• Vytvoření interaktivního okna pro 3D editaci těles
• Vytvoření aplikace pro vyýkresy

Prosím někoho ze zasvěcených od odhad časové a finančí náročnosti těchto úkolů, je to stěžejní pro odhad životaschopnosti celého projektu.

Nadpis se tváří, že takhle to bude, ale samozřejmě jsem přístupný diskusi.        

Komentáře

[Karel]

Životaschopnost: úmrtí v prenatálním stádiu

[smazáno]

Asi tak - ale aspon ze jsou nazvy promysleny

[Ondra]

ale v kazdem spravnem opensource projektu se jeste pred nazvem projektu prece nejdriv stanovi programovaci jazyk. A to nikde v blogu nevidim?

[pawleeq]

Relevantní připomínka, děkuji.

[Josef Kufner]

Programovací jazyk se nestanovuje na začátku, ale až po sesbírání požadavků a jejich analýze. Je zcela v pořádku, že to v blogu ještě není.

[JS]

To bych rad vedel, co na tom chces stanovovat. V nicem jinem nez v C++ si to nedokazu predstavit, jakkoli ten jazyk zrovna v oblibe nemam (a neni to muj salek kavy).

[Dreit]

Assembler

[pawleeq]

Fortran!

[Bystroushaak]

Plankalkül!

[w4rr10r]

Lisp, bitches.

[JS]

Common Lisp by IMHO byla realna alternativa (pro psani takove aplikace) pokud by platily dva predpoklady:

- Psal by se rok 1993 a ne 2013.

- Investovalo by se do nakupu komercniho vyvojoveho prostredi.

Oba body jsou pro free SW projekt problem.

[frEon]

proc v roce 1993 a ne v roce 2013?

[JS]

Myslim, ze to od te doby proste zastaralo, nebo lepe receno, ztratilo krok.. Ja vim, ze dneska existuje urcite "nove hnuti" v Common Lispu, ale vetsina velkych aplikaci v nem se delala nekdy koncem 80. let. Z toho take vychazi, ze nesezenes moc lidi, kteri to znaji, neexistuji prakticky knihovny. Takze bych se toho trochu bal, delat v tom velkou a moderni desktopovou aplikaci - je to do znacne miry nepoznany teren.

[frEon]

diky, takhle receno mi to uz dava smysl

[Josef Kufner]

Otázkou je, zda C++ bude jediný jazyk. Nic to ale nemění na tom, že je na to ještě brzy.

[transistor]

Co takle java? Sice ji nemám rád, ale jen proto, že snad všechno napsané v jave, s čím jsem se setkal bylo nenažrané na hw zdroje a když jsem kouk do kódu, tak byl neuvěřitlně rozplyzlý (t.j. na každou drobnost tam byla třída). Považuji to ovšem za statickou chybu, nikoli vlastnost jazyka a platformy a proto bych ji na takovýto projekt klidně navrhl. Oproti C++ má totiž jednu zásadní výhodu - garbage collector, což je věc, která úžasně šetří programátorův čas (a nervy) a jak je známo, tak čas programátora je dražší než čas CPU.

[JS]

Javu na tohle nelze brat vazne. CAD je aplikace, ktera vyzaduje praci s miliony objektu. Kdyz se kazdy zvetsi i jen o 50%, tak to znamena, ze si uzivatel bude muset koupit o 50% vic pameti na to, aby mohl navrhovat stejne veci, jako u konkurence. A veci, ktere budou vyzadovat soucasny limit pameti u desktopu, navrhovat nebo pocitat nebude moct vubec. Proste v realnem svete hraji konstanty, nejen asymptoty, roli, a nelze vzdy jen "koupit vetsi zelezo", protoze takovy pristup znamena, ze konkurence toho dokaze vic.

Dalsi vec je, ze to ma samozrejme kaskadovy efekt na CPU cache. Vice objektu (ktere navic nejsou nutne ulozene blizko sebe) znamena vetsi vytizeni cache a nizsi rychlost.

Transakcni servery, tam se to zabirani pameti snese (a proto se pisou v Jave). Protoze tam je aplikace stejne jenom prutokovym ohrivacem dat mezi siti a databazi (ktera je - hint - typicky napsana v C++). Ale u desktopove aplikace, ktera neco velkeho pocita, ani nahodou. Tam je pamet podstatna, a proto ji nelze sverit obecnemu garbage collectoru (muzete si samozrejme v C++ napsat vlastni, takze to neni zadna vyhoda Javy navic, a typicky takove velke aplikace maji ruzne alokacni strategie - jednou z nich muze byt napr. ze se objekty pro vypocet alokuji v blocich a na konci se uvolni jen ty bloky a na individualni objekty se kasle).

Jinak to co pise Josef o progamovacim jazyce, skriptovaci jazyk je uzitecna vec. Ale na to se taky Java nehodi, spis neco jako Lua, Python nebo Scheme, nebo idealne je tam nejake API, ktere muze ohackovat cokoliv prostrednictvim veci jako SWIG apod.

[Franta]

To, co píšeš, se týká jádra – s tím souhlasím a taky mi přijde C++ jako jasná volba.

Na druhou stranu by bylo fajn mít možnost psát pluginy v Javě. Oproti různým skriptovacím jazykům to má výhodu typové kontroly a pracovalo by se s tím mnohem pohodlněji (člověk hned ví, jaké má co metody a vlastnosti, jaké typy to vrací a přijímá a není potřeba to dlouze hledat v dokumentaci nebo pracovat metodou pokus omyl – ten kód/API je z velké části zdokumentován sám sebou, což je obrovská výhoda).

[JS]

No, nevim, prijde mi, ze Java neni jazyk ktery je zrovna snadne nekam embeddovat. Nevim, co by sis predstavoval pod tim pluginem.

Problem je, ze pokud ten plugin bude tak velky, ze se ta staticka typova kontrola zacne hodit (IMHO duvod proc skriptovaci jazyky typicky maji dynamickou typovou kontrolu je, ze se v nich pise relativne maly, lepici kod), pak zacne narustat i overhead ve vymene dat mezi tim pluginem a jadrem. Takze je otazka, jestli v takovem pripade neni lepsi to zkousnout a proste napsat ten plugin v C++.

[Josef Kufner]

Hm, pokud se to bude psát v Qt, tak se prostě použije QtScript. Ta integrace s Qt je zcela zásadní výhodou.

[JS]

Proc ne? Javascript je taky OK jako skriptovaci jazyk. I kdyz me by v nem asi nektere veci chybely.

[Josef Kufner]

Které?

[JS]

Treba nejaky normalni slovnik, ne object, ktery muze mit i jine klice nez stringy, treba jine objekty. JS jako jazyk je takovy trochu nedomysleny gulas, i kdyz z velke casti se to da snest.

[Josef Kufner]

V podstatě můžeš vzít jakýkoliv QObject v C++ a poslat ho do QtScriptu. Takže není problém si potřebné struktury dodělat dle potřeby. V základu to je celkem chudé, ale nemyslím si, že by to bylo néjak na škodu.

[JS]

Ano, to muzes. Nebo muzes zaembeddovat Python, ktery ma nejen lepsi celkovy navrh, ale i bohatou knihovnu, ktera takove veci uz obsahuje. (A v C++ to lze taky udelat pomerne snadno - viz SWIG.)

[JS]

Ha, trochu jsem googlil, a zda se, ze Qt a SWIG jsou dohromady problem. Hm, asi se pri pouziti Qt QScriptu nevyhnes, i kdyz pro Python by se mozna dalo pouzit PySide. Asi je jasne, co chci rict - Javascript je na skriptovani snesitelna volba ale vim o lepsich.

[Josef Kufner]

A jsi si jistý, že PySide je pro skriptování uvnitř C++ aplikace a nikoliv jen biding pro psaní samostatných skriptů?

[JS]

Tohle se pak resi embeddovanim interpretru. V Pythonu se typicky nejdriv udela binding na API a pak se ten interpretr, ktery to API vidi, embedduje do te aplikace (a tudiz lze z jejiho vnitrku poustet skript). Jaky je v tom technicky rozdil od toho, co dela QtScript? (A ted jsem se schvalne koukal - Python taky umoznuje provest treba jen jeden vyraz - neni to tak, ze by se musel pokazde znovu inicializovat interpretr.)

Ja QtScript ani PySide neznam, jen si myslim, ze podobna technologie existuje i u Pythonu.

[Agent]

"Kdyz se kazdy zvetsi i jen o 50%, tak to znamena, ze si uzivatel bude muset koupit o 50% vic pameti na to, aby mohl navrhovat stejne veci, jako u konkurence."

1. Můžu mít profi CAD který sežere méně paměti, ale stojí desítky tisíc (nevím přesně, ale asi nejsem daleko od pravdy)

2. Můžu mít free CAD zadara, nebo symbolickou cenu, který vyžaduje více paměti v ceně pár stovek (4 GB za cca 600 kč)

Který si jako chudý student/pracující zvolim?

[Josef Kufner]

Otázkou je, zda ty 4GB za 600 ještě máš kam strčit.

[JS]

Ano, jako student/pracujici zvolis nejakou free alternativu, ktera holt neni profesionalni. Takove zjevne uz existuji. Ale cilem tohoto blogu bylo uvazovat nad tou profesionalni.

[Dreit]

Co takhle D? Staví na C++ a má garbage collector

(i když jinak je pravda, že programování rozumím jak poník hamburgeru)

[smazáno]

D by imho byla _hodne_ zajimava a slibna volba!

[pawleeq]

Já se taky mám k programování jako Eskymák ke sklizni banánů, ale držel bych se trochu okolního světa. Třeba budeme kanibalizovat a forkovat existující projekty a tam už tu volbu udělal někdo za nás.

[qwubla]

také bych se držel zaběhnutého C++,C a k tomu skriptovací engine případně nějaké moduly přímo v Pythonu

[smazáno]

Kdyz se snazis prorazit na zabehnutym trhu, tak se drzet toho, jak to delaji ostatni neni dobre. D by ti dalo opravdu konkurencni vyhodu v rychlosti vyvoje a zajimavosti pro programatory (jak rikaji ostatni je radost v tom programovat). Na druhou stranu, pokud vychazite z forku jineho projektu, tak si jazyk vybrat nemuzete

[JS]

To ze lide rikaji, ze je radost v tom programovat, neznamena, ze ty programatory najdes. Ze je v tom radost programovat se rika o spouste veci. Mozna je to urcita forma selekcniho biasu, protoze v tech jazycich, ktere jsou minoritni (a ta rozsirenost je, az na nejake historicke endemity, jako treba COBOL nebo REXX, predmetem zakona mocnin), obvykle programuji jen ti, co se jim ten jazyk libi. Zatimco ti, kterym se zvoleny jazyk nelibi nekde delaji realnou praci.

Existuje taky riziko. Nevim o tom, ze by v D nekdo kdy napsal velkou aplikaci typu CAD. Muze to byt cokoliv - kancelarsky balik, graficky program, EDA, IDE, vetsi pocitacova hra. Proste neco, kde ten program uz neni jen program, ale dal by se prirovnat k mestu - potrebuje proste urcitou infrastrukturu (ktera je u vsech techto programu podobneho typu - kazdy resi skriptovani, format souboru, verzovani, knihovny komponent, konfigurovatelne UI...) a potrebuje resit nakladani se zdroji (pameti). Tady pro to plati to same co jsem vyse uvedl pro Lisp (akorat u Lispu to u nekterych aplikaci historicky vime, treba Macsyma; nevime to dneska) - nikdo to nikdy nezkousel a nikdo nezna ty problemy.

To znamena, sice to bude zajimave, ale budes prvni, a budes resit problemy, ktere konkurence, ktera pouzila C++, resit nemusi. Protoze tam se to reseni uz zna a jsou na nej knihovny.

[JS]

A samozrejme, pokud v urcitem jazyce programuji jen ti sikovnejsi, co se jim jazyk libi, tak to opravdu pak vypada, ze se v tom vyviji efektivneji. V praxi je ale dost tezke to posoudit. Tady vlastne neprinasis zadny dukaz, ze to je lepsi, jen viru.

A ani moderni C++ podle me neni tak strasne. Je to "good enough".

Jinak, pro zaznam, nejsem zadny priznivec C++, a pociny jako Common Lisp nebo D nebo Haskell jsou mi velmi sympaticke. Jen je dobre se na to divat realisticky v sirsi perspektive, ze cilem toho projektu ma byt napsat CAD a ne zjistit, jestli lze v jazyce X napsat CAD a jestli je jazyk X pro takovou aplikaci vhodnejsi nez konkurence.

[xkucf03]

C++ mi přijde jako dobrá volba mj. díky Qt.

Ale když už se tu mluví o alternativě D, co takhle Objective-C nebo Objective-C++? (což by asi znamenalo použití GNUStepu a nutnost jeho vylepšení, aby to nevypadalo jako z doby kamenné…) Ale vzato čistě jako jazyk – je to zajímavé nebo ne?

[JS]

Qt je fajn, ja bych C++ projekt nechtel delat bez toho, ale je fakt, ze existuje spousta obrich C++ aplikaci, ktere ho nepouzivaji. Takze to neni sam o sobe duvod, proc volit C++. Objective-C/C++ neznam, ale zase, polozil bych si stejnou otazku - kdo v tom uz co napsal, kdy, jak je to velke?

[Dreit]

Co jsem slyšel, tak je radost v tom psát

[Bystroushaak]

Radost v tom psát je, ale pokud je to co s tím chceš spojit napsáno v C++, můžeš prakticky zapomenout na použití ABI. Jinak řečeno, D a C++ spolu slepíš leda skrz C rozhranní, a to je solidní opruz.

[Agent]

Mě se teď líbí Haskell. Na skriptování by nemusel být špatný.

[JS]

Mozna, pokud by teoreticti informatici (computer scientists) a strojni inzenyri tvorili stejnou skupinu lidi.

[GeoRW]

on to myslel IMHO ironicky

[Bc.]

hele, na Slováka docela dobrej postřeh

[lacik]

Cadus abortus...

[Agent]

hlavně aby z toho nebyl anus

[qwubla]

než se do toho opravdu pustíme, co kdyby každý, kdo pracoval s nějakým CAD programem na Linuxu napsal co si o tom programu myslel, co mu vadilo a co bylo dobré... ještě bych k tomu přihodil, že by bylo vhodné udělat průzkum formátu a více promyslet to použité jádro, tedy zjistit proč jo proč ne. Co může být špatné a dobré...

tedy klasickou SWOT analýzu.

[Josef Kufner]

+1

[jkb]

napsal co si o tom programu myslel

kam napsal. Sem, do diskuze, nebo az na te zamyslene strance projektu?

[qwubla]

Pro začátek by asi stačilo sem, nebo udělat tabulku kam by se data k programům zapisovala?

[Franta]

FreeCAD

• vůbec jsem nevěděl, co tam dělat a jaké panely/režim si zapnout
• napoprvé dost šílené ovládání
• v jiných CADech (ArchiCAD, AutoCAD, Microstation) jsem byl schopný prakticky hned něco tvořit a učit se postupně

OpenSCAD

• sympatický styl práce – sice to není WYSIWYG/WYSIWYM editace a připomíná to spíš psaní LaTeXu a generování výstupu, ale to se mi právě líbilo
• editor je ale naprosto nedostatečný – chybí zvýraznění syntaxe, napovídání, kontrola chyb, online/kontextová dokumentace
• kvalita 3D výstupu je špatná, moje (levná a stará) grafická karta zvládá mnohem lepší věci
• ze 3D se nejde prokliknout do kódu, který danou část definuje – nemusí to jít ve 3D editovat a popotahovat myší, ale mělo by se jít odtamtud dostat zpět do kódu, aby to člověk mohl upravit tam
• GUI by taky zasloužilo překopat a modernizovat

[anonym]

Zkompiloval jsem si poslední vývojovou verzi OpenSCADu a některé moje připomínky už neplatí Např. to zvýrazňování syntaxe. 3D mi taky přijde lepší. Nicméně stále je co vylepšovat – např. online nápověda/dokumentace nebo knihovna prvků.

[pawleeq]

LibreCAD/QCAD

• +Pohodlné kreslení, snapping
• +Stabilní
• +Dobrá práce s předpřivanými bloky a značkami
• -Není to modelovací CAD, je to kreslicí CAD

PTC Pro/E WF 3

• +Rychlý postup v modelování
• +Návrhy pomocí skeletonu
• +Provázání modelu a výkresu
• -Hrozná klikárna*
• -Obtížné přejmenování částí v jednom projektu
• -Ukládá data pouze v binárním formátu

*: příčina může být mezi monitorem a židlí

BRL-CAD

• -Až moc nízkoúrovňový -- většinu času zabere navržení těles
• -Koncepčně zastaralá a nepružná editace skrze GUI
• -Neumí výkresy
• -Nativně ukládá data do binárního formátu
• +Robustní raytracing
• +Široká škála shaderů, možnost napsat vlastní
• +Široká škála základních těles
• +Vlastní textový formát

[lucorp]

QCAD tusim 2.nieco - aktualna verzia kupena v roku 2009, cize nie zadarmova verzia - spravena bakalarka na stavarine - 4 podlazny bytovy dom (iba 2d vykresy - od pohladov cez podorysy, POVcka, vykresy vystuze). Najvacsi format tlace tusim A0++ ak si dobre pamatam.

+ pohodlne kreslenie

+ strma krivka ucenia

+ zo zaciatku vykresu velmi rychly

+ system exportu do pdf

+ klavesove skratky bez nutnosti enteru

- malo automatizacie (koty, srafy etc.)

- nedostupne kniznice prvkov, srafovania a ciar (vsetko som si musel robit sam)

- debilny system srafovania, ktory zacinal pokladat srafu od globalnej suradnice 0,0 a nie od relativnej suradnice objektu

- pri 1000 a viac ciarach uz ocividne nestihal ani na dvojjadre, 4gb ram a nvidii m9600gt

- nemoznost importu vykresov a blokov z autocadu (nova verzia to tusim uz ma) - ked vyriesis toto, tak mas postarane o obrovsku kniznicu objektov, ciar a blokov vseho druhu

[...]

FreeCAD:

po shlédnutí pár tutorialů v něm teď kreslím dost rychle. Pohybuji se pouze v Part Design a Part. Zkoušel jsem si v tom nakreslit pár blbostí jako příruby nebo různá ozubená kola, víčka..., zkoušel jsem to pak i složit do nějakého celku a je to docelai intuitivní. Problém je, když člověk narazí na nějakou nedodělanou funkci (např. Utility to apply thickness) nebo když po změně nějakých kót program zamrzne a spadne. V tomhle byl dobrý Microstation, který ukládal po každém kroku a měl v podstatě nekonečné undo (snad si to dobře pamatuju, dlouho jsem v něm nedělal).

[qwubla]

Doplním i ostatní CAD aplikace z jiných platforem

FreeCAD

• +opravdu zvládne otevřít většinu důležitých formátů - DXF/IGES/STEP
• +pokud člověk pochopí záložky Part a Part Design, tak lze opravdu i používat a něco vymodelovat
• +je možné ho skriptovat Pythonem a funguje to docela obstojně - tedy vytvořit modely dopředu
• -+Záložka Arch se dá použít na nějaké základy budov, ale použitelnost je hodně podivná..
• -+Parametrické jádro, stále má ale nějaké chyby a při složitějším modelu, nemusí dojít ke správné rekonstrukci
• -výkresový modul je opravdu špatně navržený, jeho použitelnost by se měla dramaticky vylepšit
• -sestavy nejdou dělat, jedině fixní pozicí nebo skupi

MEDUSA4

• +zvláštní systém kreslení 3D parametrických modelů
• +podpora pro velké množství formátů
• -+netradiční ovládání, výkres kde se modeluje
• -

AutoCAD

• +pokud se kreslí přímo výkres nebo vektorová data, velice dobrá použitelnost
• +velká možnost pro přizpůsobení a skriptovatelnost
• +-vysoká roztříštěnost platformy, velké množství podobných reprezentací objektů
• +-DWG formát je hodně používaný
• -horší reprezentace 3D dat z parametrických modelářů
• Používá se hlavně ve stavebnictví a např. pro interiéry

BricsCAD

• +-Klon AutoCADu
• +-Podobné ovládání jako AutoCAD,
• +Nová verze má lepší parametrický modelář
• +Prohlížeč souboru > DrawingExplorer

Pro/E

• +Velký CAD modelář navázaný na další aplikace
• +Velmi dobré provázání modelu a výkresu
• +Na složitější modely se hodí výrazně lépe
• Používá se hlavně ve strojnictví a navázaných odvětvích

SolidWorks

• +Velký CAD modelář navázaný na další aplikace
• +Ještě jednodušší než Pro/E
• +-Výkresy nejsou na tak vyspělé úrovni např. jak v Pro/E, ale vizualizace a napojení na další aplikace je lepší
• +Jednoduché ovládání i na složité modely

[qwubla]

ještě sem přihodím ukázku, co se minulý týden objevila na fóru.. Budou vidět nějaké současné vlastnosti.

zajímavá část je ke konci stránky http://sourceforge.net/apps/phpbb/free-cad/viewtopic.php?f=8&t=1222&start=260

[pawleeq]

To vypadá velmi dobře.

[manasekp]

Planujete nejakou podobnost UI s Autocadem? Nejaky linuxovy cad jsem videl docela davno a prvni co me odradilo bylo o dost jine rozhrani, kdyz uz jsem si zvykl na autocad tak se me nechce zase ucit neco jineho. Myslim ze podobne bude uvazovat dost lidi zvyklych na acad.

[mycz]

Autocad je koncepcne zastaraly CAD ktery nema budoucnost... Mimo to pod linuxem jsou pouzitelne nahrady jako Draftsight

[jkb]

Draftsight

myslim neni free ??

[pawleeq]

Je k mání zadara, ale nemá otevřený zdroják a ještě otravují s registrací.

[manasekp]

proc je autocad zastaraly? Ja tu mam nekde 2013 verzi a je perfektni

[Bedňa]

Pretože vie akurát tak kresliť :)

[manasekp]

no ale vie kreslit dost dobre, mnohem lip nez ty linuxove free zmetky

[Bedňa]

linuxove free zmetky

Maňas ja ti asi rozbijem hubu Ide o tie veci čo sú uvedené v komentároch, ktoré dokážu napríklad CATIA a ProE.

[mycz]

je koncepcne zastaraly... je to jenom takove elektronicke rysovaci prkno. V podstate tam jenom tahas cary

[pawleeq]

Zatím jde návrh UI vlastní cestou, třeba časem bude konvergovat k některému z masově používaných programů, ale zatím to nedovedu předjímat.

[gtz]

Tak ať se daří.

[JS]

Taky tak.

[xkucf03]

Myšlenka nadace (o.p.s.) je pěkná i to odměňování za jednotlivé kousky práce… časem to takhle může fungovat. Ale v první řadě je potřeba silná osobnost, programátor a architekt v jedné osobě, který navrhne a vytvoří ten základ a později se bude starat o koordinaci práce ostatních. Bez toho to nejde – nestačí sbírat nějaké malé patche od jednotlivců – nejdřív je potřeba mít co patchovat – ze samotných patchů se hotový produkt neposkládá. Ten člověk to může dělat buď ve vlastním zájmu, zadarmo a z nadšení případně za nějaký slíbený zisk v budoucnu – nebo jako profesionál za peníze, ale ty je potřeba shromáždit předem a nebude to zrovna málo.

Obojí je dost trnitá cesta, ale spíš bych sázel na to první – spíš se najde blázen, který bude dělat zadarmo, ale bude to mít pod kontrolou, než aby někdo dal svoje peníze úplně cizím lidem, kteří mu slibují světlé zítřky (i když i to se třeba může stát).

Ten architekt/programátor, případně malý tým kolem něj, si musí projít základním kolečkem analýza-vývoj-testování. V dalších iteracích se pak dají přijímat příspěvky od širší komunity a zapojit víc vývojářů – přijímat ty patche – protože už bude co patchovat.

Pak je ještě možnost vyzkoušet si práci na něčem menším. Co takhle vzít OpenSCAD a předělat ho? Viz ty věci, co jsou v #8: lepší GUI, lepší 3D výstup… Navíc když se tohle udělá a bude za námi vidět kus práce, tak se snáz sežene sponzor na samotný Cadus.

Vyrobit a spravovat web na Drupalu se všemi náležitostmi projektu

Drupal mám rád, ale tady bych ho doporučoval jen na web pro zákazníky/investory. Vedle toho je potřeba infrastruktura pro vývojáře – např. Trac + verzovací systém (Mercurial, Git, Bazaar atd.). Ve Tracu se dají evidovat úkoly a vést základní dokumentaci a taky koukat na zdrojáky přes web (+ je to celé propojené a dá se odkazovat z jednoho na druhé).

[Dreit]

Ale v první řadě je potřeba silná osobnost, programátor a architekt v jedné osobě, který navrhne a vytvoří ten základ a později se bude starat o koordinaci práce ostatních. Bez toho to nejde – nestačí sbírat nějaké malé patche od jednotlivců – nejdřív je potřeba mít co patchovat – ze samotných patchů se hotový produkt neposkládá.

Má pravdu Ostatně Linus to takhle praktikuje už nějakou dobu a jak mu to krásně šlape

[Dreit]

Nevzpomínám si jak je to jinde (před dvěma lety jsme ve škole prostřídali 4 CADy za půl roku), ale mají všechny CADy sjednoceny příkazy zadávané klávesnicí, nebo ne? Nějakým slovem se třeba dal vytvořit válec - existuje na to univerzální slovo, nebo se v různých CADech používají jiná (třeba i počeštěná) slova? Pokud se to liší, možná by nebyla na škodu možnost vybrat si vlastní "jazyk", jakousi keymapu. Když už by někdo migroval, tak ať si vybere ovládání co mu vyhovuje a případně si ho upraví na míru

 

Ad Cadus - džbán, hned mi to připomnělo http://en.wikipedia.org/wiki/Utah_Teapot

Ad elektrotechnika - co si pod tím mám představit? Konkurence Eagle?

[xxxxxxxxxxx]

Jsem schopen vymyslet logiku programu. Teda co všechno s čím má souvislost princip fungování uvnitř programu.

Jinak teďka pár bodu co je potřeba si říct.

1) Je potřeba udělat 3D parametrickej modelář, universální. tak aby ho mohl využívat kdokoli (strojař stavař, atd...) takže něco co bude schopno vytvářet 3 typy souboru: součást, sestava, výkres. tyto soubory budou provázaný mezi sebou. V podstatě jde o to vytvořit virtuální popis reality ve 3D. Stavět tedka 2D CAD je na nic protože se dá uživatelsky přívětivě kreslit na linuxu v uzavřeném ale zadarmo programu DRAFTSIGHT.

2) Je potřeba dát dohromady lidi který to zajímá a nebo lid kteří touží si vydělat nějakou korunu.(něco pustim)

3) je potřeba si zvolit člověka který to bude řídit.

4) je potřeba aby se programátoři seznámily s jedním ze 3D parametrických CAD. (mohu zajistit.)

5) je potřeba zjitit na jaké úrovni použitelnosti je BRL-CAD a nebo nějakej jinej základ a zjistit jak to pudje přiohnout pro naše učely.

6) Začít tvořit plátek po plátku každej z lidí by mohl udělat dle toho co umí svoji část.

7) Zvážit formu sdružení, nastavit pravidla. Já totiž nejsem moc příznivec stavění struktury když není ověřené že to vůbec pujde. nejdřív bych zkusi ldát lidi nezávazně dohromady, zkusil vyplodit nějaký anarchisticky kod a pak zvážil formu když se osvědčí schopnost spolupráce mezi lidmi.

[xmdude00]

Dobrý den, pořád ve všech příspěvcích postrádám jednu důležitou myšlenku: Všichni si pod pojmem 3D CAD představujete něco co vytváří prostorová tělesa, v praxi je ale neméně důležité umět vytvářet kvalitní plochy v 3D prostoru a z nich potom vytvářet objemová tělesa. V idelálním případě tedy 3D CAD zvládá jak 3D plochy (surfaces) tak 3D tělesa (solids) v rámci jednoho dílu (part), viz všechny CAD, které za něco stojí: CATIA, UNIGRAPHICS. Tedy BRL-CAD rozhodně ne! Pokud to má za něco stát, bylo by dobré používat ke všemu od začátku objektový přístup, např. jako CATIA

[pawleeq]

Pokud pracujete ve 3D, tak prostě pracujete s tělesy. Jestli s nimi děláte od začátku, nebo začínáte od nějakého rovinného útvaru, které mu posléze dodáte třetí rozměr už je marginální záležitost.

[jkb]

ja si myslim, ze tak jednoduche to neni. Napr. konstrukteri, kteri pouzivaji VariCAD byli zacatkem roku nadseni, protoze nova verze umi nacitat STEP data i tehdy, kdyz chybi nektere plochy teles. Drive VariCAD nacitani ukoncil a konstrukteri, kteri rozpracovavali nejake sestavy od generalniho dodavatele nemohli s takovymi podklady pracovat.

Vetsina velkych systemu totiz umoznuje vyskladnit model za pomoci ploch - to se dela z duvodu utajeni - aby subdodavatel nemel detailni predstavu o celekovem modelu, ale presto znal zahladni rozmery a mohl "konstruovat takrikajic okolo". A kvuli tomu je napr dulezite, aby v tom systemu existovala moznost nejakeho efektivniho zpracovani ploch.

To jen na okraj, povazuji to v tomto okamziku vlastne za naprosto nepodstatne.

[xxxxxxxxxxx]

nejdřív A a potom B...

[stativ]

To je snad samozřejmé, ne? Myslím, že jsem něco takového zmiňoval už dříve, ale dělat něco, co je schopné pracovat jen s primitivy a pak se snažit dobastlit věci jako plochy je nesmysl, protože aby vše dobře šlapalo, potřebuješ pokud možno jednotnou reprezentaci (obvykle NURBS).

[xmdude00]

Z vyjadreni autora jsem to tak nepochopil. V CATII je to takto: SolidShapeFactory? pro telesa, ShapeFactory pro plochy a HybridShapeFactory pro telesa + plochy, viz dokumentace ve V5.chm Jen namatkou tenkostene plechove konstrukce, laminatove konstrukce.. pouzivaji se jen plosne modely.

[stativ]

Jak to je v Catii nevím, ale HybridShapeFactory napovídá, že je schopná reprezentovat tělesa i pomocí ploch, i když SolidShapeFactory plochy používat nemusí (otázka je, proč to tak je, možná výkon).

[Franta]

Je potřeba udělat 3D parametrickej modelář, universální. tak aby ho mohl využívat kdokoli (strojař stavař, atd...) takže něco co bude schopno vytvářet 3 typy souboru: součást, sestava, výkres.

BTW: jak vlastně funguje spojování součástí? Dejme tomu, že mám součást „zeď“ složenou z pár kvádrů (cihly, izolace, omítky…), která se dá parametrizovat (výška, délka…). Zvládne ten CAD spojení dvou zdí v rohu tak, aby na sebe vrstvy navazovaly? Architektonické CADy tohle zvládají, tam je to běžná vlastnost. Tak se chci zeptat jestli je to v souladu s tím, co si pod parametričností představují strojaři.

[pawleeq]

Přesně takovýhle featury potřebujeme shromáždit. Strojař zase někde zesílí desku a potřebuje posunout spojovací materiál, kterej tu desku někde drží.

[Jimmy]

Strojařské CADy umí vazby i mezi různými díly v sestavě. Takže lze např. nastavit vazbu, že díl stěny bude až po konkrétní plochu jiného dílu, díra bude končit x mm pod vnější plochou a bude umístěna v polovině vzdálenosti a podobné hračičky. V praxi je to ale nutné používat opatrně, otevírání dílu s vazbou na mnoho okolních dílů se mohou docela protáhnout, protože otevření dílu pak znamená natažení skoro celé sestavy. Také revize není dobré dělat úplně automaticky, protože je nutné výrobě popsat co všechno se má upravit.

Obecně ale v parametrizaci CADů pro různé směry nebude velký rozdíl. Prostě všechno se musí dá zavazbit na všechno.

[Bedňa]

Rozhodne by som rozdelil projekt na sebe nezávyslé celky ako parametrické jadro, výkresová dokumentácia, renderer a GUI. Komunikáciu spraviť cez API a pokiaľ na to existuje nejaké RFC atď. dodržať ho.

[Luboš Doležel (Doli)]

Plánovat projekt, který zjevně nemůžete sami realizovat a nemáte na to ani lidi, je marné. To nevyjde. Vaše jediná šance je, že se najde programátor, co trochu CAD zná a má osobní zájem na tom dělat a vy mu budete radit.

Druhá varianta je, že nashromáždíte stovky tisíc až miliony Kč a pak bude libovolný programátor dostatečně motivovaný na tom s vámi dělat.

[xxxxxxxxxxx]

Jseš připosranej. Aneb teplíčko a smrádeček na tebe nejlíp sedí.

[pawleeq]

Argumentujeme k věci, neprudíme do osoby mluvčího.

[xxxxxxxxxxx]

oooki.

[pesspi]

Suhlasim. Videl som projekty s jednym programatorom ktore boli neohrabane ale realne, a potom som vydel projekty s niekolkymi "manazermi" a 0 programatormi a ich vysledok bol vzdy uplna nula.

[pesspi]

Tiez by som chcel zdoraznit ze ak nemate kvalitneho veduceho programatora tak to nedozeniete vyssim poctom priemernych programatorov. (Osobne sa radim medzi priemernych).

[pawleeq]

Proto taky vedeme tuto debatu. Pomalu tu krystalizuje skupina lidí, kteří mají poměrně přesnou představu, jak by měl CAD vypadat, rýsuje se jakýsi návrh porogramu a dá-li pánbůh, najdou se tu i jeden nebo dva programátoři, kteří budou ochotní se tomu dlouhodobě, leč po chvilkách věnovat a kód udržovat.

[jkb]

skupina lidí, kteří mají poměrně přesnou představu, jak by měl CAD vypadat

ja jsem pro kazdou srandu a povazuji komentar pana Dolezala za prehnane negativisticky, ale zastavam take nazor, ze je treba diskutovat otevrene a nic si nenamlouvat. A ta vase veta nahore je, myslim si, velmi nepresna.

Me tu chybi jeste rada podstatnych momentu, ktere bych _ja_ diskutoval.

Prvni okruh problematiky jsou otazky, co se vlastne chce, komu jsou vysledky urceny. CAD je system pro podporu _konstruovani_. Ty vsechny raytracingy jsou ale spise podpora marketingu. Konstrukter neprotrebuje videt virtualni realitu s neohrabanymi texturami - kontrukter to ma v hlave - protoze je konstrukter. je tedy cilem 25. CAD system jako CATIA? Nebo se zamyslime , co vlastne konstrukter potrebuje, jak vlastne konstrukter pracuje?

Dalsi otazka je, na ktere konstruktery je cileno. Na ty v nastrojarnach a nebo na konstruktery ve velkych automobilkach.

Proste me je tady nazacatku prilis tech NURBS ploch a malo tech vseobecnych myslenek.

[pawleeq]

Prvni okruh problematiky jsou otazky, co se vlastne chce, komu jsou vysledky urceny.

Cílem je udělat CAD použitelný pro profesionály. Primárně tedy vycházíme z toho, co konstruktér potřebuje a jak pracuje.

Dalsi otazka je, na ktere konstruktery je cileno. Na ty v nastrojarnach a nebo na konstruktery ve velkych automobilkach.

Tady bych hledal rozdíly v uživatelském rozhraní, než ve funkcích. Pokud jsou nějaké zásadní rozdíly, popište je prosím.

Ty vsechny raytracingy jsou ale spise podpora marketingu.

Ano, jako kontruktér se musíte nějak prodat. Jinak pomocí raytracingu můžete získat i další užitečné info, v BRL-CADU se přes raytracing dá dělat objem a hmotnost těles, což oceníte ve statice.

Proste me je tady nazacatku prilis tech NURBS ploch a malo tech vseobecnych myslenek.

Věcné diskusi se meze nekladou:)

[Franta]

Konstrukter neprotrebuje videt virtualni realitu s neohrabanymi texturami - kontrukter to ma v hlave - protoze je konstrukter.

Tohle platilo možná v době rýsovacích prken – nejdřív to mít komplet rozmyšlené a pak to jen přenést na papír. Ale i tehdy se dělaly skicy nebo se to několikrát předělávalo než se došlo ke konečné verzi. Současné IT umožňuje pracovat kvalitativně jinak. Je to asi jako srovnávat psaní na stroji nebo rukou vs. psaní na počítači, kde můžeš mnohokrát přepisovat, vracet se a nemusíš to napsat na jeden zátah.

Ten kreativní proces probíhá u počítače (nebo skicáku) a současně modeluješ i vymýšlíš – není to jen kopírování hotové představy z hlavy do počítače (to bychom ty počítače nepotřebovali a mohli jsme to dělat na papír).

Takže ten kvalitní a dobře ovladatelný 3D model, virtuální realita, má význam pro konstruktéra/architekta, protože na základě něj si může ujasnit myšlenky, přeformulovat, přijít na něco lepšího…

[pawleeq]

Čím přesněji je myšlenka formulována v hlavě, tím lépe se potom převádí do vnějšího světa. Je jedno jestli tam máte papír nebo kompl. Osobní počítače narozdíl od psacích strojů umožňují přerývanou editaci textu a tím likvidují jednu zásadu, totiž, že větu musím nejprve v hlavě sestavit a teprve potom ji mohu zapsat. A mjsím vědět, na co navazuji a jak budu pokračovat. To je dvojsečnost moderních technologií, zatímco při modelování nějakého artefaktu se to hodí, pro vytváření jazykových celků to není zrovna požehnání.

Konstruktér/spisovatel/muzikant to má vždycky nejdřív v hlavě a teprve potom tu myšlenku realizuje. Čím lepší k tomu má nástroje a čím lépe je ovládá, tím lepší je i výsledek.

[xxxxxxxxxxx]

tak tak. S tím naprosto souhlasím. Osobně se mi ten přístup v modelování tisíckrát vyplatil. Nejdřív to vymyslet v hlavě, čárat na papír, kecat s kámošema o problemu, opít se, spát a pořád myslet na problém v každém stavu. Výsledek takovéhoto 2deního bloumání předčí týden modelování...

[Aleš Kapica]

Není-li COKOLIV předem rozmyšleno v hlavě, tak z toho vždy vyleze - dříve, nebo později - prasečina!

[xkucf03]

A ty sis nikdy nenakreslil třeba obrázek na papír a pak ti nedošlo, že ta představa byla špatná nebo že by se dala vylepšit?

(nemluvě o tom, když se na procesu „rozmýšlení“ má podílet několik lidí a je potřeba si svoje představy nějak sdělovat)

[Franta]

…programátoři, kteří budou ochotní se tomu dlouhodobě, leč po chvilkách věnovat a kód udržovat.

To nikam nepovede. Je potřeba tomu věnovat alespoň tak půl roku intenzivní práce jednoho člověka (na plný úvazek). Až pak se dá uvažovat o nějakém rozvolnění a rozdělení práce mezi víc lidí. Samozřejmě by bylo fajn, kdyby měl už od začátku nějaké pomocníky-programátory, ale to je možná až příliš optimistické.

[lacik]

Jsem strojní konstruktér, pracuji v programu SolidEdge, v debatě o CAD mi chybí:

- plně automatická tvorba kusovníku včetně pozic na výkrese. V případě změn přegenerování jak pozic, tak kusovníku. To je naprosto klíčové a zmiňuji to na prvním místě;

- podpora tvorby výkresů podle EN ISO, v luxusním případě i ANSI a JIS, v plném rozsahu (řezy, pohledy včetně axonometrických, značky drsnosti a opracování, svarů, lepení, tolerance a úchylky...)

- podpora změnového řízení;

- návaznost na podnikový systém (skladová čísla plechů, trubek, profilů, spojovacího materiálu,... s tím, že se mi při vkládání dílů do sestav nabízí především to, co už je vedené na skladu. Pokud chci něco jiného, musím to napřed do skladu zavést);

- výpočty: statika, kinematika (řešení kolizí při pohybu mechanismů), dimenzování nosníků, hřídelí, zdroj všech informací pro FEM (bývá to většinou externí program, nebo alespoň program na vlastním CAD nezávislý), výpočty: poloha těžiště, plochy (důležité pro spotřebu barvy při lakování nebo lázní pro pokovování), hmotnosti dílů a potažmo sestav, a to jak čistá (kolik to opravdu váží) tak i hrubá (spotřeba materiálu při výrobě), občas momenty setrvačnosti a jiné podklady pro další výpočty;

- podpora strojních výpočtů, a to včetně přímého výstupu do CAD (např. si spočítám ozubená kola s tím, že mi do CADu vyběhnou modely spočítaného páru kol. Stejně tak řetězové převody, šroubové spoje, pera a drážky a další);

- firemní TPV (výpalky a rozviny plechů, konstrukce odlitků, export pro NC stroje, podpora konstrukce forem pro lisování, lití atp.);

- export pro další firemní databáze (požadavky na nákup dílů, kooperace, subdodávky, kusovníky pro TPV a plánování výroby, sklad, podklady pro OTK);

- import z jiných CAD programů - často dostaneme od našich dodavatelů např. elektromotorů a převodovek, pneumatických prvků, koncových spínačů a podobně, modely jejich produkce v jiných formátech než solidovských. Je potřeba tyto modely umět načíst a vložit nebo importovat včetně zachování atributů (parametry, objednací čísla, hmotnost, těžiště ...) a přidat vlastní atributy (skladová čísla, informace pro nákupčí);

- export grafiky z obrazovky ve formátu JPEG, a to včetně perspektivy, hezkého pozadí a obarvení a případně zprůhlednění, vyleštění... jednotlivých součástí. Vsadím se, že to marketingové oddělení bude chtít pro své prezentace; tomu se nevyhnete, protože marketing je přece prý základem úspěchu a váš šéf nebo zadavatel projektu bude markeťáky podporovat.

Toto jsou věci, které CAD pro reálné nasazení ve středních a větších firmách musí zvládat. Podotýkám, že programy zmiňované v diskusi (FreeCad, BRL-CAD) neznám, třeba to už umí. Stejně tak neznám to, co pan Zima tvoří; třeba bude umět klíčové věci taky. Nezmiňuji i jiné věci v diskusi již zamíněné (parametrické modely aj.)

[pawleeq]

Díky za velmi podnětný příspěvek. Níže připojuji komentář k některým bodům.

Výkresy: Naprosto souhlasím s Vašimi požadavky, ale v tomto bodě začínáme od nuly. Dá-li pánbůh, dostaneme se k tomu.

Návaznost na podnikové systémy a skladovou evidenci: Není to nereálné, ale znamená to další API mezi CADUSem a skladovými systémy, kterým se také musí někdo podívat na zoubek. Pokud skladové systémy žerou XML, není problém.

Výpočty: BRL-CAD umí: objem, hmotnost*, povrch, těžiště a rozpozná kolidující tělesa. Ohledně FEM už výojáři BRL-CADu také čenichají.

*: BRL-CAD počítá reálnou hmotnost na základě objemu a hustoty materiálu, s hrubou hmotností by to asi také šlo (objem odvrtaného a frézovaného maetriálu zjistíme úplně stejně, jen se to musí hlídat při modelování, úprva povrchů přes nějaký koeficient... Velmi důležitá poznámka, děkuji za ni.

Strojní výpočty: Není to nic nereálného, jakmile budeme mít fungující UI, můžeme se do toho pustit.

Export pro firemní databáze: záleží do jakých formátů.

Import: To může být oříšek. Dělám s Pro/E a marně se pokouším o import do BRL-CADu. Binární formáty bez přístupné dokumentace jsou svinstvo.

Export grafiky: tady nemáme problém.

[xkucf03]

Přílohy:

• cadus.svg (3284 bytů)
• cadus.dot (288 bytů)

Návaznost na podnikové systémy a skladovou evidenci: Není to nereálné, ale znamená to další API mezi CADUSem a skladovými systémy, kterým se také musí někdo podívat na zoubek. Pokud skladové systémy žerou XML, není problém.

Cadus by měl podporovat moduly/pluginy (psané třeba v té Javě) a ty můžou řešit tohle napojení na podnikové IS, na to je to ideální. Stejně se přes moduly dají řešit importy a exporty.

Připojuji se k díkům za předchozí komentář, ale myslím si, že většina z toho jsou moduly/nadstavba (tím neříkám, že to není důležité, naopak) a z toho plyne, že to jde implementovat až po tom ostatním. Viz příloha – nejdřív potřebujeme mít jádro CADu, jádro Cadusu, GUI a systém modulů – pak půjde všechno ostatní.

[pawleeq]

Díky!

[lacik]

Ne, to se neřeší XML nebo exportem; v SolidEdge tomu říkáme u nás ve firmě customizace.

Customizační programy jsou samostatné prográmky mimo prostředí SolidEdge ve Visual Basicu, které nám píše dodavatel CADu (tedy nikoliv pluginy). Je to windows okno s prostředky pro komunikaci uživatele s CADem. Na straně Solidu jsou definovány nikoli formáty souborů, ale protokoly komunikace mezi CADem a okolím, se kterým specializované API Visual Basicu komunikuje přímo; to pak má i prostředky pro komunikace s databázemi (se všemi, ve kterých podnikové systémy ERP bývají vytvořené), Adobe Acrobatem a určitě i dalšími programy. Na počítači ani na síti se tak nehromadí mraky pomocných exportních/importních souborů; běh customizačního programu pak vyžaduje spuštěný SolidEdge, protože s ním komunikuje.

Customizační programy se u nás starají například o:

- vytvoření pdf výkresů (omezení formátu, nastavení tisku, např. barev, tlouštěk čar, písma, to vše natvrdo zadrátované do customizace, protože jednou definované nastavení se pak už nemění);

- export do jiných formátů (dxf a další) s kompletním nastavením parametrů exportu zadrátovaným do customizace jako výše;

- vyplňování hlaviček v dílech a kusovníků v sestavách, a následně pak rohových razítek a kusovníků na výkresech. Tady se to právě baví s podnikovým systémem;

- změnové řízení. Změnované díly zkopíruje do pracovních souborů a pokud se mění i sestava, pak ji zkopíruje taky a v kopii odkazy na platné díly změní na odkazy na změnované díly. Autor změny se pa do změněného souboru podepíše a popíše změnu. Při schvalování to pak uloží záznam o schválení. Další postup je už mimo CAD (ERP, Lotus Notes - jak kde);

- tvorba katalogů ND. To jsou samostatné výkresy s jiným razítkem, ale používají stejný model sestavy. Umožňují vypnout některé pozice sestav (ty, které nemá smysl nebo nechceme dodávat jako samostatný náhradní díl);

- jiné firmy pak budou mít ještě další požadavky.

Můj názor: ne hned, ale nejpozději před uvedením beta verze vašeho CAD k testům by měla existovat definice protokolu obousměrné komunikace mezi CADem a okolím, a mělo by existovat příslušné API ve zvoleném jazyce, který je dostatečně rozšířený a u kterého je dobrý předpoklad, že ho budou prodejci znát, nebo že se ho snadno naučí (Java, Visual Basic, snad Python). Zároveň je nutné si uvědomit, že support CADu u uživatelů není jednoduchá věc.

[xkucf03]

Tohle je taky možnost. Moduly se mi líbí, proto, že je to takové integrovanější a jednotnější. Ale je fakt, že API pro napojení externích programů by bylo taky potřeba. Na to se dá použít D-Bus. Nicméně ani ten modul nepotřebuje vytvářet pomocné soubory – jde o volání metod v rámci téhož procesu.

Customizační programy se u nás starají například o

Tady je otázka, zde je žádoucí, aby to byl externí program, nebo jestli je to jen důsledek toho, že to jinak nejde. Zrovna ty exporty nebo výkresy můžou být integrované do CADu, jako modul, a nemusí to být samostatný program – prostě v nabídce vyberu „Uložit jako“ nebo „Export“ a díky modulu tam budu mít víc možností/formátů.

ne hned, ale nejpozději před uvedením beta verze vašeho CAD k testům by měla existovat definice protokolu obousměrné komunikace mezi CADem a okolím, a mělo by existovat příslušné API

S tím souhlas – rozhraní by mělo být co nejdřív, ale ty moduly/programy poskytující ty různé funkce se budou psát až časem a hned to nebude. A tady už bude prostor pro ten distribuovaný vývoj a placení za konkrétní funkcionalitu – např. napíšeš, že potřebuješ to a to a kolik za to jsi ochotný dát a někdo to naprogramuje. K tomu by byla na stránkách projektu burza, kde by se střetávaly požadavky na funkcionalitu od zákazníků a nabídky programátorů.

[lacik]

Tady je otázka, zde je žádoucí, aby to byl externí program, nebo jestli je to jen důsledek toho, že to jinak nejde. Zrovna ty exporty nebo výkresy můžou být integrované do CADu, jako modul, a nemusí to být samostatný program – prostě v nabídce vyberu „Uložit jako“ nebo „Export“ a díky modulu tam budu mít víc možností/formátů.

Tohle jako externí program preferuji; u nás se konstruktér o generování pdf nestará, to je zařízeno jako hromadné generování všech nových věcí pomocí dávky v noci. A podobně v jiných firmách může být požadavek, aby se výkresy generovaly do pdf nebo tiskly až při kompletaci zakázky, o což se stará TPV a je to už mimo konstrukci, a může to být až za měsíc.

Parametry tisku nebo exportu by měly být někde bokem konfigurovatelné, ale pro TPV nebo konstrukci neměnné; velikosti výkresů, barvy a tloušťky čar a podobně by měly být stejné, ať to tisknu teď nebo za dva roky; změny by měly být plánované a provedené hromadně.

[Josef Kufner]

V podstatě není problém udělat API a pak postupně přidávat konektory na různé cizí systémy. Takový konektor nebude nijak komplexní nástroj, takže pokud API bude slušně udělané, bude vcelku snadné napojovat okolní systémy.

Stejným stylem bych řešil i různé exporty, importy a podobné věci. Zjednoduší se tím základ, kde tak nebude mnoho bordelu. Také se tím usnadní distribuovanost vývoje, kdy konektor může vzniknout nezávisle na vývoji Cadusu. V důsledku pak ale bude potřeba udržovat repositář/adresář, na kterém se konektory budou shromažďovat (nebo alespoň linkovat), aby se omezilo duplikování vývoje.

Pro usnadnění vývoje konektorů to bude chtít vytvořit různé proxy, které budou přeposílat API na různá rozhraní, např. TCP socket, D-Bus, unixový socket, HTTP REST, XML-RPC a další. Základní API by vlastně bylo definováno vrámci skriptovacího kontejneru v Cadusu a tyhle proxy by ho zpřístupnily vnějšímu světu. Výhodou je, že proxy bude možné vygenerovat podle specifikace API a když se API změní, automaticky se upraví i proxy (pokud to vůbec bude potřeba). Tedy nebudeme muset řešit, jakým protokolem se bude k API přistupovat a přidání dalšího protokolu nepřidá mnoho práce.

[xkucf03]

Základní API by vlastně bylo definováno vrámci skriptovacího kontejneru v Cadusu a tyhle proxy by ho zpřístupnily vnějšímu světu.

Spíš bych to viděl takhle: Jádro Cadusu → C++ API → všechno ostatní: tzn. skriptovací kontejner/y (časem by mohlo být víc jazyků), importní/exportní moduly, externí API (D-Bus – na něj by se dalo napojit i ostatní, např. TCP, SOAP, REST, nebo je postavit vedle D-Busu na stejnou úroveň) jakékoli ostatní moduly.

Skriptování mi přijde rozumné použít pro uživatele, pro ad-hoc úlohy nebo různé drobnosti – jako když si napíšeš BASH skript na pět řádků.

[pawleeq]

Ještě k FEM. Tady je zajímavá volná knihovna, se kterou byse dal BRL-CAD skamarádit.

[qwubla]

na FEM tu existuje třeba docela pěkný prográmek > http://www.z88.uni-bayreuth.de/z88aurora/wasistz88_e.htm nebo Salome...

jinak k původním odpovědím, opravdu si myslíte, že to jádro BRL-CADu za tu práci stojí? Zkoušel jste některou z posledních verzí FreeCADu? Jak je to s BRL-CAD a formáty, hlavně co se týče importu a exportu. V jakém stavu jsou tam výkresy nyní? Když jsem to naposledy zkoušel, tak jsem se k tomu nedostal, takže nevím.

[qwubla]

V dokumentu nahoře je že výkresy asi nejsou? K tomu bych tedy se chtěl zeptat jak je na tom s křivkami a reprezentací parametrického objektu?

S tím souvisí aspoň formáty typu IGES, STEP v nejhorším případě STL nebo DXF?

[pawleeq]

Importy a exporty jsou komplexně pojednané tady.

Z osobní zkušenosti vím, že není problém naimportovat rovinné útvary z DXF, ovšem za tu cenu, že oblouky budou převedeny na lomené čáry. STL formát je v odkazovaném dokumentu pojednán taky, ale nezkoušel jsem ho.

Architekty a ostatní, kteří potřebují návaznost na GIS snad potěší možnosti importu SHP.

Zkoušel jsem i importy z Pro/E a IGESu, ale nepochodil jsem. To ovšem nemusí být chyba programu.

[pawleeq]

Osobně si myslím, že koexistence s BRL-CADem ušetří spousty práce. Je tam hromada funkcí, které se už nemusí dělat.

S výkresy to není nic moc. Dělá se na kótování, ale zatím jsem nic neviděl. Zobrazenou geometrii je možné vyplivnout do Postscriptu, ale udělat z toho výkres je další hromada manuální práce. Jak jsem psal mimo, tady začínáme od nuly.

FreeCADu jsem se -- asi ke své škodě -- dosud příliš nevěnoval. Vždycky to na mě působilo jako šílené klikadlo, padalo to a prostě mi nebyl sympatický. Pitomé důvody, uznávám.

[qwubla]

No a to bude ono, chtělo by to provést asi lepší a podrobnější porovnání právě těchto předních opensource CAD aplikací tedy BRL-CADu a FreeCADu, jejich možnosti a schopnosti, importy&exporty, licence, použité technologie a UI a na závěr i programovací jazyky a rozšiřitelnost systemů a modulový systém... současný stav použitelnosti pro normálního uživatele atd

[pawleeq]

Jestli znáte FreeCAD, tak můžeme zkoušet, kdo dočůrá výš :)

[qwubla]

tjn.... právě jsem myslel, že by se na to pohlíželo více neutrálně, tj by to zpracovalo více lidí?

[pawleeq]

Já BRL-CAD tlačím jen proto, že se mi líbí a už jsem ho trochu nastudoval. Zároveň nemám problém se ho vzdát a třeba CADus začne jako fork FreeCADu, nemám s tím žádný problém.

V této fázi jsou nejcennější poznatky z každodenního fungování v nějakém CADu a pak možnosti dalšího rozvíjení některého z těch otevřených.

Navrhuji udělat detailnější porovnání BRL-CADu*, FreeCADu a případně ještě OpensCADu a nad tímto porovnáním začít meditovat o vývoji.

*: Beru na sebe.

[Josef Kufner]

Jak chceš shánět lidi, když ještě pořádně nevíš, co vlastně chceš dělat?

Kdyby se sešla skupinka programátorů, tak sice budou mít teoretické znalosti na vytvoření CADu, ale nebudou mít vůbec žádnou motivaci ho vytvořit. A i kdyby ho vytvořili, tak ho nebudou používat, takže jim nebude záležet na kvalitě. Oproti tomu tu je několik lidí, kteří mají motivaci, budou to používat a snaží se nasbírat prostředky (další znalosti a lidi). Jako začátek mi toto přijde mnohem lepší.

[Jimmy]

Musím souhlasit. Tohle nemůže vyjít. Byl jsem svědkem nasazení poměrně nového CADu Caelum XXen. Nasazení do naší firmy bylo po 3-4 letech od zahájení prodeje nového CADu, postaveného téměř na zelené louce od firmy od firmy, která už CADy vytvářela, takže měla know how a věděla to čeho je. První rok nasazení bylo reportováno cca 500 chyb, druhý rok cca 200. A to byl jeden technik po první dva roky v kanceláři naší firmy a pomáhal řešit problémy přímo na místě. Po třech letech intenzivních oprav to bylo už konečně slušně použitelné. Jedná se CAD na úrovni SolidWorks (ale rychlejší a úspornější na paměť).

Napsat něco podobného po večerech je nemožné v nějakém reálném čase.

[keny]

Nevím, jak velké plány máte s elektromagnetismem a simulacemi. Každopádně trochu to s tématem souvisí. Kdybyste do toho šli, mrkněte na open-source simulační programy jako MaxFEM, OpenEMS, MEEP, B-CALM, CAMFR, MRCWA, CAPHE, Vemsa3D, IPKISS atd. Tyhle nástroje mají každý trochu jiné ovládání, ale navzájem se pěkně doplňují. Některé už mají i GUI. Pokud by se někomu povedlo sloučit jejich už hotové funkce pod jednu střechu a propojit je s rozumným CADem, tak to bude šlapat na paty profesionálním balíkům.

[keny]

A mimochodem, z laického pohledu, nechtěli byste do začátku forknout blender?

[pawleeq]

Nechtěli. Blender dělá mesh modeling, CAD potřebuje CSG modeling.

[stativ]

Zjednodušeně pro laiky – Blender ukládá finální podobu objektu ve formě nějakého meshe, kdežto CSG ukládá posloupnost operací, jak se do té finální podoby dostat pomocí jednoduchých operací (např. na pozici x,y je koule o průměru z, na pozici a,b je jednotková krychle a my chceme jejich průnik) a do meshe se to převádí (pokud vůbec) až pro účely zobrazování.

CSG ti umožní např. změnit poloměr koule a všechno se pak „samo“ opraví, kdežto u blenderu bys musel začít od nuly.

[pawleeq]

Díky za skvělý tip!

[fri]

Cadus vypadá jako název pro profesionální CAD program. Osobně bych si to přizpůsobil na Kaktus. To by se mohlo používat když ne jako hlavní název, tak jako přezdívka. Bylo by snadné nakreslit hezké logo/ikonu projektu.

[xkucf03]

Ne, ne, Kaktus (nebo Kadus) bude verze pro KDE – bude složená z plasmoidů a KParts… a bude používat aktivity (např. jedna aktivita bude návrh součástky, druhá: sestava, třetí: tisk výkresů).

[pawleeq]

Kristova noho, co potom my fluxboxáři?

[xkucf03]

Bylo to myšleno částečně jako vtip. Nicméně dokonalá integrace aplikace a desktopového prostředí a využití možností KDE naplno mne dost láká. Aplikace nemusí být jen obdélníkové okno odtržené od toho zbytku a DE není jen plocha a nabídka programů.

[pawleeq]

Na jednu na stranu je fajn mít k ruce celou řadu funkcí, který KDE nabízí, ale bál bych se toho. KDE jde pořád dopředu, každou chvíli se něco podělá, případně někde zmizne nějaká užitečná funkce. Například v kate jsem si zvyknul na XML completion, ale na debianu stable je kate 3.4.5 a tam to prostě nefunguje, resp v kate tahle extension není.

[Marián Kyral]

Vy budete mít Ficus

[pawleeq]

Díky. Cadus kaktus nezní špatně.

V českém se prostředí se to zkomolí na "kaďák", což otevírá další možnosti stran ikon :D

[pavlix]

V českém se prostředí se to zkomolí na "kaďák", což otevírá další možnosti stran ikon :D

A pak přijde pitomeš a napíše pro Cadus zásuvný modul jménem Phallus a bude to v pr…

[Aleš Kapica]

Doslova..

[pawleeq]

A určitě se ješt ěobjeví nějaká nouzová funkce c.list.eer :D

[jkb]

takze abychom se trochu hnuli dopredu. (i kdyz nerad rusim ty vedecke disluze ohldne vhodneho programovaciho jazyka ):

- potreboval bych pro ten 3D opengl-viewer data z toho jadra BRL-CAD. Predstavuji si to asi takhle - ten kolega, co se v tom BRL-CADU vyzna by mohl namodelovat jednoduchy strojarsky dil - treba uhelnik z ploche pasnice z dirami. Pasnice 40 mm sirka, 6mm tloustka, ohnuta do 90° delka ramen 100 a 200 mm, diry na ose ruznych prumeru, v kazdem rameni treba 2 kusy. Ted by bylo potreba zjistit, jak je mozno z toho jadra ziskat ty udaje - budou to 2 kvadry v kterych budou valce a nebo to budou plochy, cary a body? Zatim bych se nestaral o to, jak vypada ta cast toho ohybu, to bude pozdeji jiste zajimave, ale pro to vyzkouseni by to mohly byt ty dve ramena toho uhelniku (2 kvadry) spojene v tom ohybu 1/4 valce.

Kdyz uz to budou telesa , tak je to v opengl jednoduchy, ja bych zkusil to 3d okno a zacal bych si hrat s tim zobrazenim a interakci. (s fox-toolkitem)

Druhy ukol by byl pro BRL-CADisty zjistit , jak tomu modelu dodat zpatky zmenene udaje, treba zvetseny prumer nejake diry. Pro ten vyvoj bych si to predstavoval tak, ze by ta prezentacni vrstva pracovala s tim jadrem pres unixsockety, nechtel bych to cele dohromady slinkovavat. Na zacatek neni ani to potreba, predaval bych to pres soubory - tak jak se na vyvoj v linuxu slusi a patri.

Vpodstate by to same bezelo s tim opencascade, ale to tu zatim nikdo nezna. K tem doporucenim vzit ten FreeCAD jeste poznamka - pouzivaji tem ten coin3D, ktery uz patrne zemrel - to bych rekl ze je trochu blbe.

[qwubla]

coin3D sice asi umřel, ale měl by být relicencován na BSD licenci a tedy následně FreeCAD vývojáři naznačili něco v tom smyslu, že to začnou vyvíjet... Jinak FreeCAD používá i právě opencascade.

K té části toho produktu... ve FreeCADu je možné toto zpětně zjistit... případně při použití sketcheru i upravit v makru nebo přímo.

[qwubla]

tak ještě chyba... zřejmě je coin3D již přelicencován

[qwubla]

http://sourceforge.net/apps/mediawiki/free-cad/index.php?title=Development_roadmap

a tady mají i roadmapu > plus už tenhle projekt, ukazuje, že chtějí na

http://sourceforge.net/apps/mediawiki/free-cad/index.php?title=UTF_Project coin pracovat

[pawleeq]

Přílohy:

• uhelnik.g (2984 bytů)
• uhelnik.png (20704 bytů)
• uhelnik-commands.txt (1152 bytů)
• uhelnik.png (20704 bytů)

Tak tady to je.

Nejprve doporučuji prohlídnout PNG, ať víte co je to za bastl :)

.asc je nativní textová databáze

.g je interní binární databáze

.txt je žurnál seance v MGEDu, tedy můj přesný postup, který nemusí nutně dávat smysl ani osobám znalým modelování v BRL-CADu :). Ale najdete tam, že parametry nějakého tělesa se mění pomocí příkazu sed. (Pokud potřebujete více info, obratem dodám.)

Asi to moc nepomůže k výrobě zobrazovadla, ale snad to může být nějak jinak ku pomoci: tady se dá vyčíst, jak krmit BRL-CAD zvenčí pomocí PERLu a tady je na poodbný úkol použit bashový skript.

[pawleeq]

A tady ještě nějaký linky:

http://brlcad.org/wiki/New_Cross-Platform_3D_Display_Manager

http://brlcad.org/wiki/Talk:OpenGL_GUI_Framework

http://brlcad.org/wiki/User:Ralith

[xkucf03]

Jen technická poznámka: na odkazy je tu tlačítko a značka <a>

[jkb]

.asc je nativní textová databáze

ten obrazek je tam 2 x , ale tohle asi chybi ??

[pawleeq]

Příloha:

• uhelnik.asc (1985 bytů)

Ups, omouvám se.

[qwubla]

Přílohy:

• test.fcstd (11206 bytů)
• Snímek obrazovky pořízený 2013-03-18 10:55:04.png (155723 bytů)

Tak jo jen rychlá ukázka.. neměl jsem moc čas, asi to bude špatně :) Jinak png jako obrázek + výstupní soubor > zip

[pawleeq]

Chybí tam vnitřní zaoblení a ta velká díra (na delším rameni) směrem k úhlu má být kónická.

[...]

Přílohy:

• kkk.FCStd (11839 bytů)
• kkk.png (20307 bytů)

png jako obrázek + výstupní soubor > zip

[pawleeq]

Jo, to už je ono. Akorát můj FreeCAD 0.1 spolehlivě kolabuje při pokusu o otevření.

[qwubla]

já mám FreeCAD z PPA https://launchpad.net/~freecad-maintainers/+archive/freecad-daily

mají ještě stable řadu

[pawleeq]

jakmile děti usnou a manželka zmlkne, tak to sem pověsím

[jkb]

takze predem dekuji kolegum za ty soubory a dalsi odkazy. No, ehm, je to takove nedobre....

V kazdem pripade pro me se to trochu vyjasnuje, jak jsou ty systemy vybudovane, Zda se mi ze v principu jsou oba podobne, co se komunikace jadro <-> UI tyce. Tedy pres prikazovou radku (ze je to nekdy zabalene do nejakheo interpretru, ktery ty prikazy vyvolava je fuk) se jadru sdeluje ta 3D skutecnost. Ja jsem ocekaval, ze bude event. mozna komunikace na nizsi urovni - a hlavne ze bude obema smery. Jak to vypada, nezbyde nez se do tech zdrojaku podivat ...

Jinak jak sem ty systemy prosel, tak na to UI se vpodstate vyhradne pouziva openGL, vetsinou zabalena v nejakem tom toolkitu. A ta openGL si v podstate taky drzi nejaky svuj 3d model toho co ukazuje. Zde si nejsem jisty, jestli je lepsi, aby byla tesna komunikace jadra s tou OpenGL a nebo aby ty systemy byly skutecne striktne rozdelene.

Takze je k tehle konkretni problmatice a i k ostatnim vecem urcite tisice poznamek. Zde to brzy zapadne a tak si myslim, ze by skutecne byla lepsi nejaka samostatna stranka, navic to tady zajima asi jen omezeny pocet lidi.

[xxxxxxxxxxx]

Osobně hlasuji pro to aby to bylo striktně oddělaný. Že by jsi jádru posílal jenom čísla co potřebuješ za operace a zpátky by ti lezl nějakej výsledek v podobě čísel. A ten předek by zobrazoval sám a staral se o uživatele...

[pawleeq]

rozhejbu na své doméně trac a přesuneme se tam, link sem pověsím, jakmile to bude

[Josef Kufner]

Rovnou tam i připrav wiki (v Tracu), kam se nahází poznatky nasbírané ve zdejších diskusích dřív, než tu nezapadnou. Diskuse bych ale zatím nechal tady pod blogy – je tu víc lidí i lepší zázemí.

[qwubla]

chtělo by to právě podrobněji prozkoumat a analyzovat, dle nějakých hodnot stavy jednotlivých produktů

tedy připravit nějaký systém např. body, kterými by jsme mohli ohodnotit jednotlivé atributy programů, trochu více komplexněji. A zároveň i podrobněji, aby jsme měli nějaké srovnání vůči sobě a na základě hodnocení si rozmyslet, jaký způsob zapojení bude vhodný a čím se ze začátku do projektu zapojit?

[pawleeq]

Co to to dát do tabulky? 1. sloupec potřebný featury, další sloupce jendotlivý kandidáti, barvou, nebo zaškrtnutím se vyznačí, jak je na tom ta která featura v daném programu.

[qwubla]

jj, asi nějak tak

[qwubla]

možná něco jako je tady... http://www.bricsys.com/cs_CZ/bricscad/comparison/

[pawleeq]

Ok, něco takového vyrobím :)

[JS]

Drzim vam palce, at to vyjde. Zda se, ze tu vznika skupina lidi, kteri se o to zajimaji.

[pawleeq]

Díky!

[pawleeq]

Zatím ta nic moc není, ale to se snad změní :) http://77.93.223.241:8000/cadus

[Josef Kufner]

$ whois cadus.org
NOT FOUND

Pospěš si

[jkb]

je ta stranka jiz pristupna ? U me to nejde.

[pawleeq]

Včera to bylo trochu předčasné. Takže zatím je to takhle: http://77.93.223.241/trac a během dne tam nasměruju doménu cadus.org.

[pawleeq]

Tak už to funguje: cadus.org/trac

[qwubla]

pěkné ;)

co to porovnání, aby se na tom mohlo začít pracovat? Dále by asi bylo zajímavé vybrat nějaké důležité komentáře a překopírovat je tam, ať se to trochu setřídí?

[pawleeq]

Pracuju na tom, během dnešní noci to tam nahrnu, jak komentáře, tak udělám nějakou wiki tabulku na to porovnání.

Linknu to potom sem.

Otázka do pléna: chcete do toho tracu OpenID?

[xkucf03]

Stačí možnost registrace. Nebo mi pošli heslo přes můj profil tady

[pawleeq]

registrace už funguje

[qwubla]

Kam se tedy člověk může přihlásit jako podpora/konzultant a částečně i programování (znám malinko C++ a Pascal, převážně dělám v Pythonu)?. Část toho na čem děláme můžete vidět na www.dlauhy.cz/blog

[pawleeq]

http://cadus.org/trac/register

[Agent]

Jen tak pro zajímavost: https://jogamp.org/jogl/www/

[pawleeq]

Zajímavej projekt, díky.

[stativ]

<flame>Od toho se držte dál, je to Java.</flame>

Jinak s jogampem jsem pracoval/pracuji. Je to docela pěkné, ale s OGL se mi vždy pracovalo líp v C++.