Cadus - backend bude BRL-CAD

4.4.2013 21:34 | Přečteno: 2684× | apps |

Navzdory trolům, remcalům, pesimistům, finanční krizi a všemu opruzu vůbec stále pokračujeme ve snaze udělat pořádný parametrický svobodný CAD. První rozhodnutí je za námi, nebudeme stavět na zelené louce, ale použijeme BRL-CAD. Má to několik dobrých důvodů.

• Jak už v diskusích pod zdejšími CAD blogy několikrát zaznělo, udělat CAD není žádná legrace. Proto se taky paktujeme s komunitou, jejíž jádro tvoří lidi z výzkumných laboratoří americké armády a kteří na tom dělají už více než 30 let.
• Získáváme všechny zásadní CAD funkce. Nesmusíme znova dělat tělesa, jejich matematiku, řešit raytracing atd. Máme to hezky napsané v C.
• V BRL-CADu už jsou ve vývoji vazby mezi tělesy a kótování.
• Jelikož pojedeme na Qt, potřebujeme něco jako QBrlcadWidget a komunita kolem BRL-CADu se v tomhle už na začátek dostala. Máme na co navázat.

BRL-CAD má více než 2000 interních C funkcí v 16 samostatných skupinách. To může leckoho vyděsit, ale když vás to vyděsí, můžete začít na zelené louce a začínat na zelené louce bez hromady peněz a desítek vývojářů je nesmysl. Ačkoliv může někoho uživatelské rozhraní brlcadu vyděsit k smrti -- a to pro zhýčkané AutaCADisty nebo Pro/Ečkaře nemusí být žádný problém -- pod tou ošklivou kapotou je velmi dobře fungující motor.

A ještě jedna podstatná věc, komunita kolem BRL-CADu je velmi vstřícná. Tohle vybírám z dnešní debaty na IRC: "we can certainly be the gecko to your firefox .. save you a few hundred man-years of work".        

Komentáře

[Nikt0]

len aby to nedopadlo ze "we can be a webkit for your vim" :D drzim palce.

[JS]

Dobry! To zni rozumne.

[smazáno]

Vypada jako dobre rozhodnuti nezacinat na zelene louce. Ale po pravde, jelikoz tu je uz asi deset blogu ale ani radka kodu, tak vam teda moc neverim :-/. No ale drzim palce, treba z toho neco zajimaveho bude.

[Josef Kufner]

Zatím jsme tím kecáním ušetřili nějakých 300 člověko-let vývoje.

[smazáno]

Skvele, tak ted uvidime jestli se bude dit i neco dal

[GeoRW]

ked to teraz po dalsich 10 diskusnych blogoch zabalite, tak usetrite dalsich 300

[Heron]

Ale po pravde, jelikoz tu je uz asi deset blogu ale ani radka kodu, tak vam teda moc neverim :-/.

Huh...? Já se na začátku bál spíš opačného přístupu. Šílené kódování od začátku a bez rozmyslu. Pokud se těm 10 blogům dá říkat analýza, tak je to jedině dobře.

[pawleeq]

Blogům bych analýza neříkal, tomu co z nich prosakuje do tracu už ano.

[alfonz mucha]

Přijde mi škoda, že neproběhlo ještě před tímto rozhodnutím větší prozkoumání možností současných knihoven. Na druhou stranu, pokud víte, že je ten BRL-CAD opravdu dobrý tak proč ne. Já totiž mám dojem, že už je to docela starší záležitost. A když se člověk například podívá na dnešní "novinku" v "CAD" světě SpaceClaim, tak půjde tento způsobe vývoje v CADUSu nad Brl-cadem aspoň částečně implementovat či se tím inspirovat?

ukázky jsou možné vidět na https://www.youtube.com/watch?v=44UNSrfU6As

Nebo je tu aspoň tohle > https://www.youtube.com/watch?v=66FoxykeT0w

Nevím jak moc takovéto věci půjde dělat právě v systému na bázi BRL-CADu. Může se k tomu někdo trochu vyjádřit?

[pawleeq]

Brl-Cad je starší záležitost, běhal už na PDP 11/70. Na tom není nic špatného, jelikož je pořád aktivně vyvíjen. Hegemoni komerčního GIS, ESRI, taky začali zkraje 80. let.

SpaceClaim na tom prvním videu vypadá a funguje skvěle. V zásadě je to pořád všechno CSG a po týhle stránce jsem tam neviděl nic, co by brlcad neuměl. Všechno to stojí a padá na uživatelském rozhraní a jeho interakci s matematickým jádrem. Trochu to rozepíšu:

Dnes se hodně používají fíčury typu sketch a revolve. Načmárám nějaký rovinný útvar a ten pak otočím, nebo vytáhnu. Tohle oboje brlcad samozřejmě zvládá a svádí to k pokušení používat pouze sketch a revolve jako (kolegové programátoři prominou možná nevhodný termín) datové typy. Tady -- nijak racionálně, spíše intuitivně čuju zradu -- a radši to kreslení vytahování a otáčení beru jako proces shromažďování poznatků o jednotlivých základních tělesech (jako datových typech) a vztazích mezi nimi. Sledujte dále.

Když nakreslím čtverec s ukousnutým rohem a boulí a vytáhnu ho, tak vlastně vytvořím kombinaci ((kvádr u válec) - tříboký_hranol_co_mi_kouše_roh). Když ten útvar budu otáčet, dostanu kombinaci (prstenec* u (válec1 - válec2)** - (válec3 - komolý_jehlan)***).

• *: boule
• **: kombinace válců čtvercového průřezu
• ***: tímhle ukousneme roh

Pokud namísto jedné sketch, nebo revolve použijeme tohle komplikovanější řešení získáme snadnější přístup k parametrům jednotlivých částí modelu a do uživatelského stromu si budeme vkládat rovnou CSG kombinace, což nám situaci značně zpřehlední a přiblíží tomu, co je vidět ve SpaceClaim.

Obdobný přístup bude potřeba aplikovat i u zaoblení nebo zkosení hran.

Komplikovanější to je, pokud nějaký jednoduchý model (třeba hranol s válcovou dírou) začnu kroutit do vrtule, nebo ohýbat podle Bezierovy křivky. Tam už narážíme na vzájemnou převoditelnost jednotlivých datových typů, resp jejich převoditelnost na NURBS plochy. Moc o tom nevím, ale podpora NURBS už v brlcadu je.

Podle toho videa vidím hlavní výhodu SpaceClaim v tom, že šikovně skrývá a odhaluje uživateli právě ty prvky UI, které zrovna (ne)potřebuje. Trochu mne zneklidňuje předídavé chování jakéhokoliv softu, ale tady je vidět, že se to dá dělat dobře. Ale nedovedu odpovědět, jak komplikované je něco takového udělat.

Osobně si spíš představuji, že půjdem krůček po krůčku:

Nejprve to asi bude vypadat nějak takhle:

• Menu/čudlík: chci válec, klik*
• tady bude střed první podstavy, klik**
• tady střed druhý, klik**
• Poloměr je tolik a tolik (vepíšu hodnotu do okýnka)

*: tohle není problém **: tady už musíme umět lovit myškou souřadnice v 3D prostoru

V druhé iteraci už nebudu nic psát do okýnka, ale našmrdlám to myší, na to ale musíme umět lovit hodnoty v rovině kolmé k zadané přímce. V dalších iteracích už budou hezké kóty, kde bude možné měnit jednotlivé hodnoty od poloměru jendotlivých podstav po úhel sevřený osou a podstavou (tady se bude muset najít/napsat goniometrie). Tím máme hezky v UI ošetřený válec. U další těles můžeme postupovat analogicky

Jo a ten výkres "jakože vlastně 3D model", to mě dostalo. To je gól, to se jim povedlo a je to sakra inspirativní.

[alfonz mucha]

Ano já vím, že to typickou cestou jde... Ale to už tu máme, např částečně v podobě FreeCADu myslím. Kde takové věci již je možné dělat a i s tím docela pěkně pracovat GUI.

rozdíl je ovšem v tom, SpaceClaim má obrovské možnosti právě v tom, že konstruktér/návrhář není vůbec omezen nějaký rebuildem celé struktury operací a tvarem základních objektů. Přitom však může ovlivňovat vazby a celkový model stylem, který je známý z normálních parametrických modelářů + stylem který je blízký např. Blendru. Což umožňuje pohled spíše člověk, než programu na model.

Jinak již zmíněný 3D výkres, je již třešnička na dortu.

[alfonz mucha]

asi píšu nějak rychle :D sry za chyby...

jinak doufám, že tyto poznámky jsou stále konstruktivní a možné bližší prozkoumání současného stavu a možná i vylepšení toho budoucího.

[pawleeq]

Samozřejmě jsou kontruktivní a přínosné. Těmi několika odstavci jsem chtěl říct, že Ui ve stylu SpaceClaim je možné a že k němu vede dlouhá cesta.

[jkb]

konstruktér/návrhář

Ja si myslim, ze ten SpaceClaim je tak vhodny pro toho navrhare. Pro to, aby konstrukter protahl nejakou soucastku musi byt nejaky duvod. Ten duvod se musi prozkoumat, zvazit, to jsou mnohdy hodiny a dny. Uspora v celkovem procesu zanedbatelna. Ale vypada to hezky a moderne.

[alfonz mucha]

Na druhou stranu ten důvod přeci může mít konstruktér a vzhledem k tomu, že u všech operací je možné pracovat s číselnou reprezentací, tak je i přesnost operací docela zaručená. Tedy pokud ho prozkoumá, proč by to udělal, tak SpaceClaim pak jednoduše umožní s tím pracovat dál.

[pawleeq]

Ono je pro UI v zásadě jedno, z jakých pohnutek uživatel/konstruktér/vesmírná opice to, či ono dělá; jestli jen patlá, aby si ošahal funkce, nebo jestli ladí převodovku. Dobře navržený interface poslouží kreativci stejně jako technologovi a v detailech se přizpůsobí jejich specifickým potřebám.

[Jimmy]

Poněkud děsivá u SpaceClaim je absence historie. Ona tam stejně někdy být musí. U složitějších dílů se často používá skládání modelu z různých částí a občas je potřeba schovat část historie, přidat požadovanou věc a zas vrátit model do plného tvaru. U složitějších modelů také občas po nějaké editaci nelze model přepočítat, takže je nutné vrátit se na úroveň, kde model spočítat ještě lze a opravit/upravit problematický feature. U ukázkových příkladů to problém nebývá, u reálných dílů plných obecných křivek, zkosení a rádiusů to bývá běžný problém.

Obdobně editace 3D dat ve výkresu vypadá hezky, ale ve větší firmě kde často dělá 3D model jiný člověk než který z něj tvoří výkres je to přímo nežádoucí vlastnost. Už tak stačí kontrolovat chyby na výkrese, natož ještě kontrolovat 3D model zda se nezměnil.

[alfonz mucha]

k první otázce se ve SpaceClaim vztahuje možnost používat componenty a dále je omezovat, případně rozpojovat.

Dále problém s regenerací modelu ve SpaceClaim ani nevzniká, jelikož jak již bylo řečeno historie tam být vůbec nemusí. S tím samo sebou souvisí i možnost oprav modelů, které jsou téměř nemožné v normálních parametrických CAD programech. Na druhou stranu, je zde možné také parametry používat.

[xmdude00]

Vážený pane, z Vašich zápisů je vidět, že významu slova CAD vůbec nerozumíte, a vaše zkušenost je omezená pouze na jeden minoritní system ProEnginner. Význam slova CAD je počítačová podpora konstruování, pro Vás ovšem znamená počítačové vytváření objemových těles + tvorba dokumentace těchto těles. Pokud by jste napsal: CADUS bude používat BLR-CAD jako jádro pro operace s objemovými tělesy, zajásal by asi každý. Takto vytváříte pouze lepší klikátko okolo BLR-CADu. Proberte se z Vaší noční můry jménem Pro/Engineer a podívejte se okolo, co se děje a co se začíná masově šířit: kompozitní díly - plochy, kterým se přiřazuje tloušťka. Kovové "bionické" díly zhotovované 3D tiskem - Catmull-Clark mesh subdivision tak jak je to v Blenderu. Vážně věříte svému rozhodnutí?

[pawleeq]

Pokud nějaké ploše, resp. rovinnému útvaru přiřadím tloušťku, dostanu těleso. Jemu pak můžu dát shader, který se bude při raytracingu chovat jako zdrsněný povrch, nebo třeba tráva... Pozor, raytracing v brlcadu není jen renderování hezkých obrázků, ale plnohodnotná analýza.

Catmull-Clarkovo dělení sítí a "bionické" díly: na to máme v brlcadu NURBS plochy.

Věřím svému rozhodnutí a vůbec mi nevadí prozatím dělat další klikátko kolem BRL-CADu, třeba se dostaneme i někam dál.

Ještě jedna věc:

je vidět, že významu slova CAD vůbec nerozumíte

Argumentujeme ad rem, nikoliv ad personam, je to základ slušné a konstruktivní diskuse už dob starořeckých polis.

[psc]

Nenechte se odradit. Fandím vám a nápad oprášit BRL-CAD a udělat k němu komfortní front-end je určitě dobrý nápad.

Sám bych i přispěl troškou do mlýna, ale jsem teď dost vytíženej. Až to bude už v nějaké fázi zkompilovatelnej základ + zdrojáky přístupný např. přes Git, tak pokud budu mít čas a bude zájem, rád pomůžu.

[pawleeq]

Díky za podporu, teď promyslíme, jak budeme kooperavat s BRL a pak už brzy nějaký cód bude. GIT repo už máme, ale zatím se tam nic neděje...

[xmdude00]

Argumentujeme ad rem, nikoliv ad personam, je to základ slušné a konstruktivní diskuse už dob starořeckých polis.

To byla argumentace k věci Vás (Vašeho přehledu) v souvislosti s tvorbou ideového modelu.

Vypadá to, že si s aktuálními problémy poradíte, tudiž Vám velmi rád pomohu s doplněním požadavků z komerčních CADů, popř. s testováním.

Ještě mě napadá, jaké důvody Vás vedou k použití QtScript pro objekty (Zde chybí přehled mě). Osobně se mi líbí vestavěný interpret pythonu tak, jak ho používá ABAQUS. Modelování je pohodlné jak pomocí GUI, tak skriptu.

[Josef Kufner]

Ke QtScriptu nás vede to, že už je integrovaný v Qt a je velmi snadné vzít jakýkoliv QObject a strčit ho do skriptovacího enginu.

[pawleeq]

Ok, necháme rejpání a někam se pohneme.

Požadavky komerčních CADů buď šoupněte sem do samostatného vlákna, nebo je dejte (pokud možno anglicky) na tuto wiki stránku .

Necítím se úplně komptetentní odpovědět, proč zrovna Qt a jak přesně se bude používat. Snad si toho tady všimne někdo z programátorů a nějak lidsky to vysvětlí.

Samozřejmě počítáme v modelováním přes gui, cli (to už v podstatě v brlcadu máme) a pomocí skriptů.

[Josef Kufner]

V podstatě CLI modelováním nepočítáme. To prostě necháme na BRL-CADu, neboť se bude ukládat v jeho nativním formátu.

Celkově je moje představa taková, že všechno se dělá skriptem a GUI je napojené na ten skript. Takže z CLI bude možné volat skripty a ty můžou cokoliv, co může GUI. Výkonově tam ztráty nebudou, protože skript ve většině případů jen vyrobí propojky a eventy pak půjdou napřímo.

[dumblob]

Dovolim si poznamku, ze v pripade CSG ty skripty nejen ze budou zpomaleni, ale to zpomaleni bude dost vyrazne natolik, aby clovek mel pocit, ze pracuje s neinteraktivnim editorem. Chtelo by to pokud mozno ty skripty co nejdrive nahrazovat nativnimi C++ moduly.

Je zrejme, ze zprvu se bude psat vsechno ve skriptech, ale realne se to bude muset prepsat do tech C++ modulu (a i ty prave diky tomu super pomalemu mechanismu signal-slot v Qt budou muset byt optimalizovane).

Vyse uvedene pisu jenom pro upresneni, aby to nevypadalo, ze zde mame obdobny skvost jako LuaJIT v kombinaci s CSP.

[Josef Kufner]

Ty skripty jsou primárně zamýšleny pro poslepování GUI a všech částí dohromady. Tedy v místě, kdy se buď většinou čeká na uživatele, nebo se jedná jen o inicializaci. Možnosti generování modelů jsou jen vedlejším efektem.

Ještě uvažuju o zavedení nějaké centrální message bus, ale nejsem si jist, jak moc veliký přínos oproti samotným signálům a slotům by to znamenalo.

[dumblob]

Ještě uvažuju o zavedení nějaké centrální message bus, ale nejsem si jist, jak moc veliký přínos oproti samotným signálům a slotům by to znamenalo.

Urcite by to prinos melo. Zalezi ovsem ciste na jednoduchosti navrhu a kvalite implementace. Bavime se nyni prilis nekonkretne, abychom mohli napevno prohlasit "nyni muzeme zahodit velkou cast Qt signalu-slotu a pouzit nase reseni". Nemohu vsak neupozornit prave na reseni vyuzivajici CSP.

Myslim vsak, ze pokud se v samotnem CSG stromu signalum-slotum uplne vyhnete, tak jednoduse hierarchicky implementovane gui si s Qt signaly-sloty vystaci (videl jsem totiz odstrasujici priklad pouziti signalu-slotu v Qt, kdy se za jejich pomoci kreslilo jenom 40 polopruhlednych trojuhelniku ve 2D, ktere si mezi sebou takto vymenovali informaci o poloze a podle ni menili vlastni souradnice, velikost a natoceni; v tomto pripade clovek pohnul mysi jednim trojuhelnikem a pul vteriny cekal, nez se pohnuly i ostatni ).

[Josef Kufner]

Na grafiku a manipulaci s modelem je tu BRL-CAD. Tam se vůbec Qt nedostane. V podobě signálu půjde kliknutí uživatele z QBrlWidgetu do BRL-CADu.

40 trojuhelníků znamená 1560 jednosměrných spojení. To celkem odpovídá

[Bedňa]

Objekt zložený z obdĺžnikov a guličiek sa dá aj do budúcna ľahko upravovať, pretože len ťaháš za ne. Zato keď máš upraviť nejaký orezaný tvar, tak to prv spravíš nanovo s CADus :)

[Ovocníček]

Mimochodem, teď mě napadla jedna věc z vlastní drobné zkušenosti s těmihle elektronickými rýsovacími prkny.

Vychází to z práce s Allplanem, takže ne strojařina, ale architektura. Člověk obyčejně dostával plány exportované z Autocadu, a obyčejně tam byly reálné globální souřadnice (v řádu stoveka ž tisíc kilometrů). Při importu do Allplanu se před lety musely tyto souřadnice zkracovat, protože program zvládal jen rozsah v řádu circa 10 km (pokud člověk pracoval v mm/m, už nevím).

Z toho plynulo několik problémů - při importu člověk musel aplikovat posun, aby měl "tu věc" v pracovním výřezu. To se sice dalo (byl to vopruz), ale problém nastával, když nějaký element měl z nějakého důvodu ulítlé souřadnice (třeba i jen kontrolní pro nějaký pitomý prvek), nebo někdo předtím něco omylem šoupnul někam úplně jinak bokem a tak.

Čímž vás chci varovat, že byste se asi měli předem taky zamyslet nad problémem obrovských souřadnic a nějak to skoulet, aby s tím nebyly takovéhle problémy. Tedy pokud chcete kromě těch těles někdy podporovat práci i s architektonickými plány (BTW, je u nich taky ten problém, že jsou někdy velké, hejbat/zoomovat s třeba s celým sídlištěm může možná vyžadovat docela sofistikovanou architekturu, aby to nebylo superpomalé - ale hodně dat asi v plánech může být i u strojů).

[pawleeq]

Narazil jsem na podobnou věc při otevírání stavební dokumentace, která byla nakreslená hezky do JTSK. Součástí byl i samozřejmě bod 0,0, což je by-woko sever Finska. Takže ano, platná připomínka.

Obecně se to dá posunout do roviny integrace s GIS, resp využití geografických souřadných systémů. Knihovny na to jsou, ale netroufám si o tom cokoliv víc říkat. Bude to asi dost velké sousto.

[jkb]

ja bych si to tedy rad vyzkusil a budu potrebovat v nekolika bodech asi postrcit.

Nainstaluji BRL-CAD, ktery sam prelozim, abch pak mohl pridavat nejakou C-funkcionalitu.

Pomoci mged a zdejsiho serialu na abicku sdelim brlcadu ze chci kvadr a pote z toho kvadru 'odejmu' valec (do toho kvadru vyvrtam diru).

Nyni bych se chtel toho brlcadu zeptat co o mem modelu vi. Za tim ucelem otevru mnou programovane okno, kde bude zatim mit jen jediny button a textove okno. Do okna budu vydavat odpovedi brlcadu a ten button bude mit caption = dej_mi_info_o_aktualnim_modelu(cary, telesa, body..).

Ted ty otazky:

bude muj program separatni exe ?

jestlize ano, jak vi to me exe o tom modelu toho jineho exe, ve kterem prave bezi ten mged?

nebude zadne zvlastni exe ale funkcionalita bude soucasti toho mged.exe?

jestlize bude jen jedno .exe, bude existovat nejaky multiplexer, ktery bude koordinovat zadavani z ruznych zdroju?

At uz se to nahore zodpovi jakkoliv, v tech zdrojakach je 22 knihoven. Vi se jiz, ktera z tech knihoven zodpovi ty otazky po zmacknuti toho buttonu, jak uvedeno nahore?

[pawleeq]

Zodpovím tu BRL-CAD část:

Vyrobíme kvádr:

mged> in kvadr.s rpp 0 30 0 10 0 10

Zjistíme o něm, co se dá:

mged> l kvadr.s

kvadr.s: ARB8

1 (30, 0, 0)

2 (30, 10, 0)

3 (30, 10, 10)

4 (30, 0, 10)

5 (0, 0, 0)

6 (0, 10, 0)

7 (0, 10, 10)

8 (0, 0, 10)

Všimněte si, že rpp je vlastně arb8, rpp je (nenapadá mě lepší termín) metatyp, který jen usnadňuje zadání.

U válce postupujeme podobně:

Výroba:

mged> in valec.s rcc 5 0 5

Enter X, Y, Z of height (H) vector: 0 10 0

Enter radius: 3

Info:

mged> l valec.s

valec.s: truncated general cone (TGC)

V (5, 0, 5)

Top (5, 10, 5)

H (0, 10, 0) mag=10

H direction cosines=(90, 0, 90)

H rotation angle=90, fallback angle=0

A (0, 0, 3) mag=3

B (3, 0, 0) mag=3

C (0, 0, 3) mag=3

D (3, 0, 0) mag=3

AxB direction cosines=(90, 0, 90)

AxB rotation angle=90, fallback angle=0

Všimněte si, že pravoúhlý kruhový válec je datově vzato zvláštní případ komolého kužele.

Teď je zkombinujeme:

mged> c -r kvadr_s_dirou kvadr.s - valec.s

Creating region id=1000, air=0, los=100, GIFTmaterial=1

Info o jejich kombinaci vypíšeme stejně, ale už dostaneme jen info, o tělesech a vztazích mezi nimi:

mged> l kvadr_s_dirou

kvadr_s_dirou: REGION id=1000 (air=0, los=100, GIFTmater=1) --

u kvadr.s

- valec.s

Více zjistíme pomocí nástroje gqa, nebudu sem už dávat výpisy, ale jen povím, co je nač:

gqa -Ao kvadr_s_dirou - zjistíme překryv kombinace s jiným tělesem

gqa -Av kvadr_s_dirou - vypočte objem kombinace

gqa -Ag kvadr_s_dirou - zjistí díry v kombinaci

gqa -Ab kvadr_s_dirou - vypíše bounding box

Bylo by fajn mít ten výpis proklikávací na úroveň těles a pokud změním hodnotu ve výpisu tělesa (třeba souřadnici jednoho rohu kvádru), tak aby se to promítlo do tělesa.

Otázky stran kódu, resp. začlenění do architektury programu bohužel nedovedu zodpovědět.

[jkb]

moc dekuji, tohle je supr, nez bych to vubec vykoumal, jak to mam s temi telesy udelat ... vubec by nebylo spatne, kdyby byl nekde seznam takovych postupu - treba ale neco takoveho uz existzje ?

Ja zatim bojuji s tim prekladem pod windows Az se to podari, tak to sepisu.

[pawleeq]

Hodně se dá vyčíst tady. Stačí jen zadat in jméno_tělesa typ_tělesa a pak už se bude MGED vyptávat dokaď nebude vědět, co potřebuje.

Ještě pro doplnění a upřesnění předchozího:

gqa -Aop kombinace1.r kombinace2.r vypíše a v grafickém okně vyznačí překryv dvou kombinací. Textově můžeme překryv zjistit ještě pomocí rtcheck.

S překladem na Windows držím palce.

[alfonz mucha]

ve FreeCADu něco podobného to vypadá třeba takto... #vložíme válec, již má definované rozměry 10,2 >>> App.ActiveDocument.addObject("Part::Cylinder","Cylinder")

>>> App.ActiveDocument.recompute()

>>> Gui.SendMsgToActiveView("ViewFit")

>>> App.ActiveDocument.ActiveObject.Height

10.0

>>> App.ActiveDocument.ActiveObject.Radius

2.0

>>> App.ActiveDocument.ActiveObject.Radius = 5

>>> App.ActiveDocument.ActiveObject.Radius

5.0

#přidáme na hrany zaoblení 3

>>> App.activeDocument().addObject("PartDesign::Fillet","Fillet")

>>> App.activeDocument().Fillet.Base =(App.ActiveDocument.Cylinder,["Edge1","Edge3"])

>>> Gui.activeDocument().setEdit('Fillet')

>>> App.ActiveDocument.Fillet.Radius = 3.000000

>>> App.ActiveDocument.recompute()

>>> Gui.activeDocument().resetEdit()

[lacik]

Jak to tady všechny ty diskuse kolem CADu a cadusu čtu, měl bych jedno doporučení:

Sjednejte si co nejvíc exkurzí do konstrukčních, vývojových a projekčních kanceláří od modelářů a malých živnostníků až po nadnárodní firmy, třeba na jeden den, a pozorujte konstruktéry při jejich skutečné práci a vyptávejte se. Zjistěte, jak postupují. jak tvoří díly (obráběné, odlévané, lisované, plechové, potrubí atd.) a sestavy, jak celou konstrukci ladí a upravují, jaké používají externí knihovny a moduly a proč, co potřebují, co se jim na jejich softwaru líbí a nelíbí, co by chtěli. Vyptejte se správců CAD systému na propojení CADu se zbytkem firmy a s okolím - s nákupem, skladem, se subdodavateli. Vyptejte se manažerů na spolupráci s konstrukcí - na rychlost práce, na prezentační výstupy, na výstupy pro NC stroje. Výstupem z těchto exkurzí by měl být podrobná analýza a seznam toho, co CAD umět musí a jak, co umět může a nemusí, a co konstruktéra nezajímá, i když programátorovi se to strašně líbí.

Vaše cílová skupina by měla být konstruktéři, projektanti, návrháři. Zatím to vypadá, že to jsou programátoři; řeší se jejich představy o knihovnách, komunikaci, modulech, o jazycích; ale to by mělo vyplynout až z analýzy potřeb cílové skupiny. Jinak se může stát, že cadus bude z programátorského hlediska skvělá věc, ale skutečný konstruktér s tím nebude chtít dělat (a to je podle mě důvod, proč tolik CAD programů vyhořelo - pro jejich totální nepoužitelnost. Docela by mě mrzelo, kdyby Cadus dopadl stejně).

Těch exkurzí by mělo být co nejvíc a měly by rovnoměrně pokrýt všechny dnes používané CAD programy; ve strojírenství ProE, Catia, SolidEdge, Autodesk Inventor, I-Deas a další. pro stavebnictví a elektro to samé (ale tam to neznám). Mám pocit, že jediný z komunity abclinuxu, který CAD reálně používá, je pan Zima (a myslím ještě někdo s Autocadem), který ProE používá v rozsahu, který potřebuje, ale zase omezeném; protože nikdo na světě žádný CAD nevyužívá naplno se vším všudy.

[loki]

Ja cadusu moc drzim palce a preji stesti, ale moc neverim tomu, ze se to povede dotahnout do pouzitelneho stadia. Kdyz pak ctu, ze jadrem ma byt brl-cad, nad tim ma byt javascript(nebo jiny skriptovaci jazyk) a nad tim gui, ktere to 'poslepuje' dohromady, tak to mym pocitum prilis nepridava. Ale snad se pletu a projekt bude pouzitelny...

[alfonz mucha]

Jen doplním pár postřehů. Ano rozhodně je důležité, aby to byl program pro konstruktéry, návrháře a přímo uživatele. Pokud půjde navíc ovládat jednoduchým skriptem, bude to plus.

Pracuji v oboru, který prolíná stavebnictví a strojírenství dohromady > interéry a nábytek. Na Ubuntu mám DraftSight a BricsCAD, FreeCAD. Často přicházím do styku se SolidWorks, TruboCADem, AutoCADem a nakonec se SpaceClaim.

Reálně pracuji v BricsCADu a SolidWorks. FreeCAD je myslím, již na dobré cestě k použitelnosti minimálně jako prohlížeč a kontrola. Nějaký návhr se tam dá celkem udělat, ale je nutné dopředu trochu promyslet jakým způsobem se ten návrh bude ubírat a jak se potom převede na papír.

[xmdude00]

Příloha:

• wing.py (6423 bytů)

V podstatě CLI modelováním nepočítáme. To prostě necháme na BRL-CADu

To by byla dost velká chyba. CLI modelování pomocí vysokoúrovňového skriptovacího jazyka je dnes běžné a v některých případech je to nutnost. Představte si, že např. kreslíte listy vrtule větrné elektrárny. Máte na listu 40 řezů, ve kterých musíte dodržet daný profil listu, který je pokaždé jiný, dále jeho natočení vůči prvnímu profilu atd. Kreslit toto ručně je práce na dva dny. Až to nakreslíte, předáte model dále, aby jste se další den dozvěděli, že je potřeba změnit profily ve všech řezech. Tohle je běžná vývojová iterační smyčka. Pokud mám dobrý CAD, napíšu si za dvě hodiny jednoduchý skript, který modeluje za mě a bez chyb. Viz jednoduchá ukázka v přiloze.

[jkb]

tohle je myslim nejake nedorozumneni. Ja to chapu tak, ze scriptovani tak jak to mate v tom priklade uz v BRLCADu nejak podobne je. A nebo je to mylka?

[xmschor00]

Ano, v BLR-CADu kreslíte pomocí příkazů, ale je to dost nízkoúrovňové a pro praktické použití se mi to zá velmi těžkopádné. Na tom příkladu to asi až tak nevynikne, ale při větších modelech to bude znát. Navíc kombinace numpy + CAD je vážně jízda..

[JS]

Hm, myslim ze numpy (a vubec numerika) je dost silny argument proti Javascriptu.. Ale ja jsem jako Pythonista zaujaty (a CADum nerozumim).

[pawleeq]

Brlcad je opravdu nízkoúrovňový, ale skriptovat se dá. Tady je příklad, jak pomocí Perlu udělat spirálu.

[xmdude00]

Ten příklad velmi krásně ukazuje velký rozdíl mezi oběma přístupy. Teď mě napadá, zda by nebylo nejlepší začít s tvorbou vysokoúrovňového rozhraní? (BLR-CADu) Předpokládám, že změny modelu chcete mít v objektech, tj modelujete pomocí:

výsledek = Továrna.metoda(vstup)

[pawleeq]

Vyšší level je žádoucí udělat. Na základní úrovni se v brlcadu dělá hlavně s vektory, což má své výhody, ale i omezení, pokud chcete přesně pracovat s úhlem, tak si musíte dělat výpočty bokem...

[xmdude00]

Motivaci bych viděl v tom, že pomocí vysokoúrovňového rozhraní si vytvořím grafické objekty a potom můžu kdykoliv měnit jejich atributy buď z interpreteru skriptovacího jazyka, nebo ze stromu v GUI. Teď Vám přesně neřeknu, zda-li jsou grafické entity v ABAQUSu přímo pythonovské objekty, nebo zda se jedná o nějaký obal z COM-objektů nad nativními objekty jsko v případě CATIE.

[jucas]

Jenom několik poznámek. Projektu samozřejmě fandím, ale bylo by dobré promyslet strategii vývoje, aby neskončil podobně jako ostatní pokusy o OSS 3D CADy. Tedy obvykle ve fázi plánování, nebo pre-alfy (asi jediná výjimka je FreeCAD, který je stále vyvíjen). Tyto projekty obvykle končí na nedostatek vývojářů, obvykle jde o one-man-show, a psaní 3d CADu je natolik rozsáhlá úloha, že tento způsob je dopředu odsouzen k zániku. Takže otázka je jak nalákat vývojáře a aktivní komunitu. Pár věcí, co mě napadly.:

* Zaměřit se funkce, které jsou slabá místa komerčních 3D CADů (obvykle z marketingových důvodů) - zpětná kompatibilita, výměna dat, napojení na externí databáze a jazyky, vysokoúrovňový jazyk popisu modelu s případnou možností jeho implementace do komerčních CADů. Pokud bude OSS CAD použitelný pro konvertování modelů, přiláká spoustu uživatelů, i když bude mít slabší funkce.

* Propojení s jiným SW se silnou komunitou, např. Blender - skript pro import. Blender neumí pracovat s formáty jako je STEP a technické / CSG modelování s mesh jádrem je deprimující.

* Podpora vyššího skriptovacího a "add-on" jazyka s plným přístupem ke GUI. Ideální se jeví Python - Oblíbený mezi techniky, parádní knihovny využitelné v CADu, dobré vývojové nástroje. Využití by bylo zároveň i pro správu rovnic vazeb. Nebylo by od věci použití i pro definici GUI (viz Blender). Zaměřil bych se na hodně dobrou "vizuální" podporu tvorby uživ. funkcí, maker a rozšíření. Např. nahrávání maker - ale více interaktivní než je běžné s důrazem na generování znovupoužitelného kódu. Stejně tak generování GUI pro makra. Uživatelé CADu obvykle umí vytvořit algoritmus nebo posloupnost makra, ale nemají přehled o API a prohledávání API je zdlouhavé.

* Začít jen se základními funkcemi - 3d pohled, výběr entit, základní primitiva (třeba jen kvádr), základní transformace - ale tyto funkce dovést do použitelného stádia. S ohledem na to, že jde o CAD, tedy např. posouvání těles myší nestačí na nějakou od-oka polohu, ale použít zadání vzdálenosti, zamykání a výběr os, přichytávání, skoky po smysluplných hodnotách (např. 0.1-0.25-1-5 mm podle zoomu), pravítko apod. Poté přidat další sadu a cyklus vývoje opakovat.

Ještě k jádrům - pokud je mi známo k dispozici je jen OpenCascade a potom těžko čitelné jako Varcon nebo právě BRL-CAD. Podle mého názoru je nezbytné, aby jádro podporovalo práci s formátem STEP a generování obrysů a průniků těles nebo NURBS povrchů jako vektory. Jak je na tom BRL-CAD? Pokud jsem dobře pochopil, STEP je nějak ve vývoji, ale není hotov. A veškeré informace o tělesech získává jádro pomocí raytracingu. Jak se dělá průmět modelu pro výkres, to se renderuje do bitmapy? nebo se renderované body spojí čarami, křivkami? Jak je to pak třeba se souřadnicemi např. hrany průniku těles? Její přesnost je daná rozlišením při raytracingu? Jak funguje tesselace modelu pro zobrazení v 3D pohledu (předpoklad, že bude použito OpenGL)? Nebo je nutné model vždy vyrenderovat? Na stránkách BRL-CADu jsem toho moc nenašel.

OpenCascade většinu z tohoto nějakým způsobem umí. Hlavně hranice ploch (pro promítání), tesselaci a STEP.

Vůbec, když se podívám na ten blokový diagram na stránkách Cadusu, tak v podstatě tohle už má takový FreeCAD hotové (QT + Python + API). Jasně, je to moloch, GUI je divoké, spousta věcí rozpracovaných a máloco použitelné, ale jak dlouho bude trvat dostat se do tohoto stádia? Navíc je potřeba si uvědomit, že ty jádra neřeší věci jako jsou 2D/3D geometrické vazby ve skicáři a sestavách, výkresy a entity s tím spojené (kóty, písmo, popisy, šrafování), správu prvků modelu a vůbec vysokoúrovňové prvky tak jak je známe z 3D CADů, udržení "objemovosti" modelů apod. Spoustu z těchto věcí má FreeCAD alespoň rozřešené.

Uf, to byl elaborát, ale zase to bylo souhrnné vyjádření k všem předešlým blogům.

... Ještě pro inspiraci jména některých z těch one-man-show:

HeeksCAD(asi mrtvý)

NaroCAD (Novinka, nechme stranou výběr jazyka a GUI. Zatím nefunguje na Linuxu, mluví se o portu do Mona)

Wildcat CAD (Starý pokus patrně o klon Pro/E ... včetně jádra, takže samozřejmě rychle skončené :)

[...]

NaroCAD (Novinka, nechme stranou výběr jazyka a GUI. Zatím nefunguje na Linuxu, mluví se o portu do Mona)

Zrovna GUI v podobě Ribbonu je podle mě dobrý krok (i když tady asi dost lidí nebude souhlasit, kůlivá jeho původnímu tvůrci).

[xxxxxxxxxxx]

tak s ribonem naprosto nesouhlasím. Ribon akorát zdržuje adělá z pracovních nástrojů bordel... Nejde o původního vůrce, ale o efektivitu?

[Josef Kufner]

V čem se ribbon liší od běžného toolbaru?

[xxxxxxxxxxx]

můj subektivni pocit.

[JS]

Ribbon je zrudnost UI designu. Je to bastard menu a toolbaru, pricemz oboji ma svoji a jinou funkci (menu obsahuje vsechny funkce a neda se konfigurovat, zatimco toolbar obsahuje jen bezne funkce, da se konfigurovat, pripadne je kontextovy). Navic ribbon uz z povahy veci nelze napriklad umistit vertikalne, coz muze byt problem. Je to pekne na koukani, a tim to konci.

[Agent]

Tohle bych řek, že je typický příklad, když pejsek s kočičkou něco kutěj.

[...]

Tak s tím tvůrcem jsem si jenom rejpnul :)
Každopádně mně se s ním dělá hodně dobře, nástroje mám pěkně na očích. Výhoda je, když program podporuje schování Ribbon menu a podporuje kvalitní práci s klávesovými zkratkami.

[xxxxxxxxxxx]

klávesové zkratky naprostej souhlas. ribbon bude asi subektivni záležitost.

[jucas]

Ribbon zabírá zbytečně hodně vertikálního prostoru na obrazovce, zvlášť když dnes je většina širokoúhlých. Někdy ho lze skrývat, ale zase to problikávání může být rušivé. Obvykle ho nelze přesunout na bok obrazovky na vertikální uspořádání. Uživatelská konfigurace prvků bývá často nedořešena, některé karty jsou napevno. Uspořádání do karet sice může být pro začátečníka přehlednější, ale kvůli jejich přepínání se najezdí a nakliká víc. Některé nápady v Ribbonu jsou ale dobré, třeba ty automatické klávesové zkratky s vizuální zpětnou vazbou.

Vhodnější GUI je podle mě nahoře jen menu / úzké lišty ikon a vše ostatní do bočního panelu + plně konfigurovatelné klávesové zkratky, konfigurovatelné kontextové menu (i více než jedno), vyhledávání příkazů a funkcí, a co nejvíce prvků integrovat do 3D okna (např.: Solidworks (3D okno, boční panel), Blender (panely, konfigurace kl. zkratek a GUI, vyhledávání) .

[alfonz mucha]

popravdě to byl také ten důvod, proč jsem se pozastavil právě nad výběrem toho BRL-CADu, když již FreeCAD má většinu těchto věcí vyřešenou a zbývá ho dostat do použitelného stavu a vývoj se právě teď v poslední době docela rozjíždí... A jakmile bude lepší napojení na Blender, tak už si myslím, že v tu dobu bude FreeCAD už hodně použitelný.. no uvidíme.

jinak HeeksCAD právě umřel s tím, že se pan Heeks myslím doporučil právě přechod na FreeCAD.

[jkb]

ja bych mel nekolik poznamek.

Zaměřit se funkce, které jsou slabá místa komerčních 3D CADů (obvykle z marketingových důvodů) - zpětná kompatibilita, výměna dat, napojení na externí databáze a jazyky, vysokoúrovňový jazyk popisu modelu s případnou možností jeho implementace do komerčních CADů.

Tohel co pisete je jiz samostatny projekt. Ja delal 1986-1991 ve firme, ktera pomahala zavadet tenkrat ve strednich a vetsich firmach CAD. Uz jenom ten vyber, vyhodnocovani pozadavku, srovnavani tech systemu, analyza konstrukcnich zvyklosti konkretni firmy a rada dalsich aktivit byly projekty v hodnote tenkrat tak 200 tisic DM. Ja si myslim, ze tohle je nerealizovatelne.

Podpora vyššího skriptovacího a "add-on" jazyka s plným přístupem ke GUI. Ideální se jeví Python

To s tim Pythonem se tu jiz objevilo nekolikrat. Rad bych skutecne vedel, proc je to idealni. Je to ted nejake moda? Uci se to na skolach jako kdysi Pascal? Se scriptovacim jazykem souhlasim, ale proc se omezovat na jeden jediny?

OpenCascade většinu z tohoto nějakým způsobem umí.

problematiku vidim v tom nějakým způsobem

Jak se dělá průmět modelu pro výkres,

Tohle bych rekl ze je zasadni problem a je to jako prvni treba objasnit. Ale to se nepodari v diskuzi, to se proste musi zkusit. Idealni by bylo, kdyby nekdo analyzoval jak to vypada u toho OpenCascade a jak to je s tim BRL-CAD. Ja za sebe se snazim proniknout do toho BRL-CADu a jeste soucasne kontroluju, jak by to bylo v gcad3d. I kdyz to ted v projektu rozhodli, ze to bude BRL-CAD, tak ja to tak lozene nevidim.

[qwubla]

Myslím, že Python má takovou oblibu kvůli tomu, že prostě je jednoduchý, efektivní, vysoce modulární a je vhodný pro spojování programů.

[JS]

No jednoduchy. Treba takova Lua je jako skriptovaci jazyk jednodussi.

Ja myslim, ze je to kulturou, velmi pratelskou pro neprogramatory, a pomerne velkou standardni knihovnou. Tohle zadna konkurence Pythonu nema. Shell, Perl a Ruby maji tendenci byt krypticke (prvni pro vsechny, posledni pro neprogramatory). Forth, TCL, Scheme a dalsi Lispy se spatne ctou, mnoha lidem. Javascript a Lua jsou mozna celkem pratelske, ale jejich zakladni knihovna je minimalni.

Co je jeste zbyva? Par jazyku, ktere je asi obtizne embeddovat.. Smalltalk, PHP, Object REXX, VB. Uz nevim.

Spousta velkych OSS aplikaci je v Pythonu skriptovatelna (treba Blender a SageMath).

[qwubla]

To že je spousta velkých OSS app skriptovatelná v Pythonu je dle mého výhoda. To totiž umožní je poté jednoduše propojovat... a tento ucelený systém je potom to, co dělá tu hlavní konkurenční výhodu.

Pokud tedy vezmu Python a mám ho v Blendru, své aplikaci a ve FreeCADu, tak jejich spojení je docela pěkné a funkční.

[JS]

To s tim Pythonem se tu jiz objevilo nekolikrat. Rad bych skutecne vedel, proc je to idealni. Je to ted nejake moda? Uci se to na skolach jako kdysi Pascal? Se scriptovacim jazykem souhlasim, ale proc se omezovat na jeden jediny?

Viz vys. To s temi vicero jazyky je takova teoreticka moznost, ale prijde mi, ze v praxi stejne vyhraje to, co budou pouzivat puvodni autori. Aspon tak bych to odhadoval na zaklade toho, co se deje v OSS projektech. Vetsina lidi, co k tomu prijde pozdeji, proste skriptuje v tom co je, a na vytvareni API pro vlastni jazyk vetsinou neni moc sila.

[jkb]

To s temi vicero jazyky je takova teoreticka moznost,

my u nas ve firme pouzivame uz 15 let swig a kdyz uz chceme zcela specialni predavani parametru, tak se musi napsat zvlastni typemap, jinak bezne se da pouzit to, co ma swig uz v sobe. Takze pro kazdy scriptovaci jazyk je potreba jen:

- makefile

- typemap-file (kdyz uz)

- remaping file

To se udela jednou a je to. Samozrejme, ze je 'vhodne', aby zaklad byla C, pak je to easy, s C++ je to bohuzel i se swigem opruz. A pak taky chapu, ze se autori rozhodnou pro jeden skriptovaci jazyk.

Problem je v tom, ze moznost pouzit jen jeden scriptovaci jazyk predstavuje znacne omezeni. U kazdeho uzivatele je uz nejake infrastruktura, u nas treba perl. V tom se vyzname, vime jake knihovny, spousta hotoveho kodu. A pak prijde nekdo s CAD s pythonen. To vede automaticky k odmitave reakci. Jako uzivatel byvh mel mit moznost se rozhodnoutz pro ten scriptovaci jazyk, pro ktery jsme vytvoril vlastni infrastrukturu. Jako vyrobce nejakeho toolu bych se mel snazit toto uzivateli umoznit. Jestlize je to alespon nejak rozumne realizovatelne.

[Martin Mareš]

Se swigem je to snadné, pokud stačí, aby interface v daném jazyce přesně kopíroval logiku Céčkového interfacu. Pokud ale chcete, aby se spíš řídil konvencemi obvyklými pro daný jazyk, tedy třeba v Pythonu hlásil chyby výjimkami, už to tak snadné není. Ale souhlasím, že i tehdy swig dost práce ušetří.

[jucas]

Tohel co pisete je jiz samostatny projekt. Ja delal 1986-1991 ve firme, ktera pomahala zavadet tenkrat ve strednich a vetsich firmach CAD. Uz jenom ten vyber, vyhodnocovani pozadavku, srovnavani tech systemu, analyza konstrukcnich zvyklosti konkretni firmy a rada dalsich aktivit byly projekty v hodnote tenkrat tak 200 tisic DM. Ja si myslim, ze tohle je nerealizovatelne.

Když se vezmete skupinu současně používaných parametrických CADů se stromově uspořádanými prvky, tak úplně základní funkce modelování jsou téměř stejné - roviny, souřadné systémy, skicy (základní entity), základní vazby, prvky vysunutí, rotace profilu, zaoblení a sražení. Když se definuje jazyk, který model popíše na této úrovni (v podstatě postup operací uživatele), tak jde ve většině CADů tohle interpretovat pomocí API daného CADu. Komplexní modely vzhledem k rozdílnosti CADů by byly problém, ale pro často používané malé jednoduché součásti (např. normalizované) to je dostatečné. Implementace do jiných CADů by nemuselo být v rámci vývoje OSS CADu, ale kdyby se podařilo vytvořit dobrý standard, třeba by se začal používat, a OSS CAD by měl výhodu v integraci.

To s tim Pythonem se tu jiz objevilo nekolikrat. Rad bych skutecne vedel, proc je to idealni. Je to ted nejake moda? Uci se to na skolach jako kdysi Pascal? Se scriptovacim jazykem souhlasim, ale proc se omezovat na jeden jediny?

Netvrdil jsem, že by musel být podporován pouze Python. Ale myslím, že je lepší vytvořit dobrou podporu pro jeden jazyk s jeho datovými typy, než univerzální API. A jak jsem už psal, Python je přehledný, má dobré knihovny jak v základu, tak velké množství externích pro numerické a technické výpočty, grafy, simulace, symbolickou matematiku, zpracování dat, apod. Dále má dobré vlastnosti pro integraci konzole do aplikace, dobré OOP, které ale není nuceno, a jako integrovaný skriptovací jazyk je ověřený. Doporučuji se podívat na integraci Pythonu v Blenderu (mimochodem API je generované z datových struktur) a jeho interaktivní konzoli.

problematiku vidim v tom nějakým způsobem

Ano, ale pokud vím, nic lepšího k dispozici není, a na základ to snad stačí. Jádro se také stále vyvíjí.

Idealni by bylo, kdyby nekdo analyzoval jak to vypada u toho OpenCascade

Tak vzhledem k tomu, že většina aplikací využívající OpenCascade zobrazuje hranice tělesa a hrany jako křivky v 3d náhledu, tak snad nebude problém s průmětem. Základ tvorby pohledu a export do svg tam už také je.

[pawleeq]

Co k tomu vím, zodpovím :)

- Zpětná datová kompatibilita je na brlcadu v pohodě.

- Jako výměnný formát je obecně navržen DXF, ovšem i s ním to občas skřípe. Na STEPu se už pomalu dělá. Ostatní datové formáty, zejména ty binární bez přístupné dokumentace... asi všichni víme, co Linux vzkázal výrobcům, kteří nevydávájí specifikace svých produktů :)

- Napojení na externí databáze apod. jsou výhledově v plánu, ale spíše bych to řešil na základě konkrétního požadavku.

- Propojení s Blenderem by bylo fajn, ale nevidím to jako reálnou možnost. Resp. netuším, jak překonat propast mezi CSG a mesh modelem.

- Vysokoúrovňový jazyk a modelování s jeho pomocí je fajn a počítáme s tím. BTW: spousta stavřů na své výpočty používá Excell...

- Základní fce vlastně přebíráme od brlcadu, krom široké škály primitivů tím získáme i právě možnosti jako přesný posun, chytání k mřížce atd.

- Ne všechny informace brlcadu získává přes raytracing, něco je už na úrovni tělesa (typicky objem u některých těles).

- Teselace u brlcadu nějak funguje, ale moudrý z toho dvakrát nejsem. Více zde.

- Ad výkresy: jedna možnost je vyhrnout obsah grafického okna do postscriptu, dostanete vektor. Druhá možnost je raytracing, resp. rtedge, kdy vykreslíte viditelné hrany a dostanete rastr. Výsledek potom závisí na rozlišení raytracingu. Obě možnosti jsou dosti blbé.

[jucas]

Propojení s Blenderem myslím jen jako export geometrie do meshe. Nebo zavolání Blenderu a export/import scény přímo z GUI. Blender, respektive komunita jeho uživatelů je jen příklad jak na sebe upozornit.

Implementace STEPu je docela náročná, a může trvat dost dlouho. A jak jsem už psal, jeho podpora v CADu je podle mě naprosto klíčová.

K teselaci, zajímalo by mě proč ji Brlcad nepoužívá v Archeru. Ono obecně k BrlCadu není moc dohledatelné dokumentace, nebo demonstrace jeho možností. Třeba jak se dělají ty výkresy, raytracingem by to bylo příšerné.

[dumblob]

Pokud bude OSS CAD použitelný pro konvertování modelů, přiláká spoustu uživatelů, i když bude mít slabší funkce.

Tohle me zaujalo z jednoho prosteho duvodu - prevody mezi formaty jsou temer vyhradne one-man show, coz mnohym vyvojarum vyhovuje a je to docela challenge (tipovani co v danem binarnim formatu bez dokumentace asi je ).

Tedy pokud nekdo specifikuje API pro vnitrni reprezentaci (zatim to vypada na API z BRL-CADu), tak staci do todo vypsat par polozek a nekdo si k tomu (nezavisle na zbytku ekosystemu Cadusu) sedne, za nejaky cas to udela jako one-man show a commitne.

To je imho jedina soucast Cadusu, ktera nepotrebuje temer zadnou spolupraci s ostatnimi vyvojari a uz vubec ne se strojari a pritom by opravdu pritahla pozornost. Postupem casu by se Cadus staval pouzitelnejsim a lide, kteri potrebuji prevadet formaty (predpokladam, ze to je potreba docela casto) by ho pravdu zacali pouzivat pomaloucku polehoucku i na kresleni a ne jenom prevod/prohlizeni. Proste by to byl imho trumf v rukavu zajistujici trvaly prisun novych, neodchazejicich clenu do komunity uzivatelu .

[xxxxxxxxxxx]

Zkoušel jsem ten WillCAD. Vypadá to spíš na klona CATIE. Strom prvků i ikonky jsou stejné. Bohužel jse mě nepodařilo namodelovat ani bž. Asi se tma nedostali. Jinak velice příjemné GUI!!!! Jednoduché a že to každej konstruktér pochopí!

[jkb]

ja jsem to zkusil pod XP a okazite se to pro pokusu o zalozeni noveho projektu odporoucelo.

P.S. Jinak jak jsi psal ohledne toho CADParts v nejakem tom predchozim blogu, tak ted aktualne nemame potrebu, ale ja se presto ozvu na mailu, az bude trochu vic cas. Jinak, my delame spis do ERP a u mensich firem vidim potencial ohledne 3d, proto se o to tady take zajimam. Kdyz by se to 3d trochu rozmohlo, ze by to bylo zaplatitelne i pro ty mensi firmy, tak jsou i takove dodatecne softwarove nastroje urcite zajimave.

[alfonz mucha]

zkoušel jste i FreeCAD? ten má např. i nějaké testovací napojení na OpenPLM myslím.

[xxxxxxxxxxx]

Díkes, až bude čas tak napiš a ukážu co mám v plánu a co je hotovýho. Malý a střední podniky jsou mým cílem a myslím že by to pro ně mohlo být hodně zajímavý. Ale to je na delší vysvětlování. Každopádně díky za zájem.

[jucas]

Vypadá to, že autor začal s GUI, a pak zjistil, že tvorba geometrického jádra je mimo možnosti jednoho člověka. Proto jsem navrhoval opačný postup. Zjistit co umí dostupná jádra, vytvořit pro jádro vysokoúrovňový jazyk popisu modelu a pak až dělat GUI.

[Josef Kufner]

Ono začínat od GUI není vůbec špatný nápad. Hodně to pomůže s ujasněním si, co ta aplikace má umět a co je k tomu potřeba. Také to umožní získat od budoucích uživatelů zpětnou vazbu dřív, než se vlastně něco opravdu začne dělat. A když se dělat začne, tak už je připraveno prostředí pro testování nového kódu (automatické testy to nenahradí, spíš to pomůže při vývoji). A díky existujícímu GUI lze opět jít za uživateli a zeptat se, zda to je to, co chtějí.

[dumblob]

+1

[MichalekII]

Plánujete zařadit i pevnostní výpočty, či výpočty proudění?

[pawleeq]

Je to výzva, ale zatím bych to nechal na externích nástrojích a maximálně jim usnadnil výměnu dat.

Například na proudění je tu OpenFOAM, an žere STL formát kterýžto zase není problém vymáčknout z BRL-CADu.