abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 13:33 | Zajímavý článek

Craig Loewen se v příspěvku na blogu Microsoftu věnuje novinkách ve WSL (Windows Subsystem pro Linux), které přinese Windows 10 1903. Jedná se především o možnost přístupu z Windows (Průzkumník souborů, explorer.exe) k souborům v nainstalovaných linuxových distribucích. Použit je protokol 9P.

Ladislav Hagara | Komentářů: 4
dnes 10:44 | Zajímavý software

Byl vydán Hangover ve verzi 0.4.0. Jedná se o součást projektu Wine umožňující spouštět Windows aplikace pro x86 a x86_64 na architektuře ARM64 (AArch64). Zdrojové kódy této alfa verze jsou k dispozici na GitHubu.

Ladislav Hagara | Komentářů: 0
včera 03:00 | Nová verze

Byla vydána nová major verze 3.0.0-1 linuxového prostředí pro operační systémy Windows Cygwin (Wikipedie). Přehled novinek v oficiálním oznámení.

Ladislav Hagara | Komentářů: 6
včera 02:00 | Nová verze

Byl vydán Debian 9.8, tj. osmá opravná verze Debianu 9 s kódovým názvem Stretch. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Předchozí instalační média Debianu 9 Stretch lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.

Ladislav Hagara | Komentářů: 0
15.2. 12:33 | Pozvánky

Příští týden bude na MFF UK zahájena série přednášek o architektuře a implementaci operačních systémů. Mezi přednášejícími budou odborníci z firem Kernkonzept, Oracle, Red Hat, SUSE či SYSGO. Pokud si chcete rozšířit obzory (virtualizace, ptrace, ZFS, kdump, ...), vyberte si z harmonogramu téma, které vás zajímá a přijďte. Přednášky se konají každý čtvrtek od 15:40 v učebně S4 na Malostranském náměstí 25 v Praze. Přednášky jsou přístupné veřejnosti (registrace není nutná), studenti UK a ČVUT si je mohou zapsat jako standardní předmět.

Vojtěch Horký | Komentářů: 14
15.2. 05:00 | Nová verze

Bylo vydáno Ubuntu 18.04.2 LTS, tj. druhé opravné vydání Ubuntu 18.04 LTS s kódovým názvem Bionic Beaver. Přehled novinek v poznámkách k vydání a v přehledu změn.

Ladislav Hagara | Komentářů: 0
15.2. 03:00 | Zajímavý software

Git History umí u souborů v git repozitářích zajímavým způsobem zobrazit jejich historii a následně jednotlivé změny, viz animovaný gif. Použít jej lze lokálně nebo aktuálně na soubory umístěné na GitHubu. Máte-li ve webovém prohlížeči zobrazen soubor umístěný na GitHubu, nahraďte v URL doménu github.com doménou github.githistory.xyz a nové URL odešlete. Využít lze také rozšíření Chrome i Firefoxu. V plánu je vedle GitHubu také podpora GitLabu a Bitbucketu.

Ladislav Hagara | Komentářů: 3
15.2. 01:00 | Nová verze

Byla vydána verze 1.0 webové a na frameworku Electron postavené desktopové verze svobodného decentralizovaného skupinového komunikátoru Riot (Wikipedie) využívajícího protokolu Matrix (Wikipedie). Přehled novinek i s náhledy v příspěvku na blogu. Zdrojové kódy jsou k dispozici na GitHubu.

Ladislav Hagara | Komentářů: 4
14.2. 14:22 | Nová verze

Společnost Collabora oznámila vydání verze 4.0 online kancelářského balíku Collabora Online a také Collabora Online Development Edition (CODE) pro domácí uživatele. Kancelářský balík vychází z LibreOffice Online (cgit).

Ladislav Hagara | Komentářů: 0
14.2. 12:11 | Nová verze

Byla vydána verze 241 správce systému a služeb systemd (GitHub, NEWS). Řešeny jsou také bezpečnostní chyby.

Ladislav Hagara | Komentářů: 0
Máte v desktopovém prostředí zapnutou zvukovou znělku po přihlášení se do systému?
 (7%)
 (1%)
 (90%)
 (1%)
Celkem 340 hlasů
 Komentářů: 11, poslední 14.2. 07:59
Rozcestník

Cadus - backend bude BRL-CAD

4.4.2013 21:34 | Přečteno: 2171× | apps | Výběrový blog

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ů.

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".        

Hodnocení: 100 %

        špatnédobré        

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

Komentáře

Vložit další komentář

4.4.2013 22:02 Nikt0
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
len aby to nedopadlo ze "we can be a webkit for your vim" :D drzim palce.
4.4.2013 22:35 JS
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
Dobry! To zni rozumne.
4.4.2013 23:17 luv | skóre: 18 | blog: luv
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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 avatar 4.4.2013 23:24 Josef Kufner | skóre: 68
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
Zatím jsme tím kecáním ušetřili nějakých 300 člověko-let vývoje.
Hello world ! Segmentation fault (core dumped)
5.4.2013 00:06 luv | skóre: 18 | blog: luv
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
Skvele, tak ted uvidime jestli se bude dit i neco dal :-)
GeoRW avatar 5.4.2013 07:20 GeoRW | skóre: 13 | blog: GeoRW | Bratislava
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
ked to teraz po dalsich 10 diskusnych blogoch zabalite, tak usetrite dalsich 300 :-D
"This is to be taken with a grain of salt." ACBF - Advanced Comic Book Format
Heron avatar 5.4.2013 11:39 Heron | skóre: 51 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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 avatar 5.4.2013 11:42 pawleeq | skóre: 19 | blog: pawlixblg
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
Blogům bych analýza neříkal, tomu co z nich prosakuje do tracu už ano.
Overground against monoculture.
5.4.2013 07:47 alfonz mucha
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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 avatar 5.4.2013 10:04 pawleeq | skóre: 19 | blog: pawlixblg
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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í.

Overground against monoculture.
5.4.2013 11:16 alfonz mucha
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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.
5.4.2013 11:18 alfonz mucha
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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 avatar 5.4.2013 11:22 pawleeq | skóre: 19 | blog: pawlixblg
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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.
Overground against monoculture.
5.4.2013 11:34 jkb
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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.
5.4.2013 12:22 alfonz mucha
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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 avatar 5.4.2013 12:37 pawleeq | skóre: 19 | blog: pawlixblg
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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.
Overground against monoculture.
5.4.2013 22:39 Jimmy
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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.
5.4.2013 22:45 alfonz mucha
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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.
5.4.2013 08:56 xmdude00
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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 avatar 5.4.2013 10:30 pawleeq | skóre: 19 | blog: pawlixblg
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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.
Overground against monoculture.
5.4.2013 13:07 psc
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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 avatar 5.4.2013 13:11 pawleeq | skóre: 19 | blog: pawlixblg
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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...
Overground against monoculture.
5.4.2013 14:41 xmdude00
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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 avatar 5.4.2013 14:52 Josef Kufner | skóre: 68
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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.
Hello world ! Segmentation fault (core dumped)
pawleeq avatar 5.4.2013 14:52 pawleeq | skóre: 19 | blog: pawlixblg
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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ů.

Overground against monoculture.
Josef Kufner avatar 5.4.2013 15:24 Josef Kufner | skóre: 68
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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.
Hello world ! Segmentation fault (core dumped)
5.4.2013 20:55 dumblob | skóre: 10 | blog: dumblog
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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:-).
Refundace za Windows 7 od Lenovo obchodníka - soud rozhodl, že je zákazník v právu!
Josef Kufner avatar 5.4.2013 21:11 Josef Kufner | skóre: 68
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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.
Hello world ! Segmentation fault (core dumped)
5.4.2013 21:22 dumblob | skóre: 10 | blog: dumblog
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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 :-().
Refundace za Windows 7 od Lenovo obchodníka - soud rozhodl, že je zákazník v právu!
Josef Kufner avatar 5.4.2013 21:53 Josef Kufner | skóre: 68
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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á ;-)
Hello world ! Segmentation fault (core dumped)
Bedňa avatar 5.4.2013 10:35 Bedňa | skóre: 34 | blog: Žumpa | Horňany
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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 :)
KERNEL ULTRAS video channel >>>
5.4.2013 12:55 Ovocníček
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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 avatar 5.4.2013 13:15 pawleeq | skóre: 19 | blog: pawlixblg
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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.
Overground against monoculture.
6.4.2013 11:02 jkb
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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 avatar 6.4.2013 20:50 pawleeq | skóre: 19 | blog: pawlixblg
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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.
Overground against monoculture.
6.4.2013 21:31 jkb
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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 avatar 6.4.2013 23:37 pawleeq | skóre: 19 | blog: pawlixblg
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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.
Overground against monoculture.
6.4.2013 22:00 alfonz mucha
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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()

6.4.2013 13:22 lacik
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD

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.

6.4.2013 15:39 loki
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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...
6.4.2013 16:24 alfonz mucha
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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.

6.4.2013 21:05 xmdude00
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
Příloha:
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.
6.4.2013 21:33 jkb
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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?
6.4.2013 23:15 xmschor00
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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..
7.4.2013 00:36 JS
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
Hm, myslim ze numpy (a vubec numerika) je dost silny argument proti Javascriptu.. Ale ja jsem jako Pythonista zaujaty (a CADum nerozumim).
pawleeq avatar 6.4.2013 23:29 pawleeq | skóre: 19 | blog: pawlixblg
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
Brlcad je opravdu nízkoúrovňový, ale skriptovat se dá. Tady je příklad, jak pomocí Perlu udělat spirálu.
Overground against monoculture.
6.4.2013 23:53 xmdude00
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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 avatar 7.4.2013 11:17 pawleeq | skóre: 19 | blog: pawlixblg
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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...
Overground against monoculture.
7.4.2013 13:39 xmdude00
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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.
9.4.2013 02:00 jucas
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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é :)
9.4.2013 11:31 ...
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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).
9.4.2013 11:34 xxxxxxxxxxx | skóre: 13 | blog: rhrtshrth
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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 avatar 9.4.2013 11:50 Josef Kufner | skóre: 68
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
V čem se ribbon liší od běžného toolbaru?
Hello world ! Segmentation fault (core dumped)
9.4.2013 12:55 xxxxxxxxxxx | skóre: 13 | blog: rhrtshrth
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
můj subektivni pocit.:-)
9.4.2013 15:53 JS
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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 avatar 9.4.2013 20:42 Agent | HC city
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
Tohle bych řek, že je typický příklad, když pejsek s kočičkou něco kutěj.
Nevěděl zpočátku, co si počít, jak žít, co dělat, ale brzy se vpravil do role samotáře.
9.4.2013 11:52 ...
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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.
9.4.2013 12:49 xxxxxxxxxxx | skóre: 13 | blog: rhrtshrth
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
klávesové zkratky naprostej souhlas. ribbon bude asi subektivni záležitost.
9.4.2013 21:57 jucas
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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í) .
9.4.2013 16:31 alfonz mucha
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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.
9.4.2013 17:17 jkb
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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.
9.4.2013 17:41 qwubla
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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ů.
9.4.2013 18:07 JS
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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).
9.4.2013 18:35 qwubla
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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í.
9.4.2013 18:20 JS
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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.
9.4.2013 19:31 jkb
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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.
9.4.2013 22:15 Martin Mareš
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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ří.
9.4.2013 23:33 jucas
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-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.
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 avatar 9.4.2013 18:09 pawleeq | skóre: 19 | blog: pawlixblg
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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é.
Overground against monoculture.
10.4.2013 00:01 jucas
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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é.
9.4.2013 21:43 dumblob | skóre: 10 | blog: dumblog
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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 :-).
Refundace za Windows 7 od Lenovo obchodníka - soud rozhodl, že je zákazník v právu!
9.4.2013 11:33 xxxxxxxxxxx | skóre: 13 | blog: rhrtshrth
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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í! :-)
9.4.2013 17:28 jkb
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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.
9.4.2013 17:36 alfonz mucha
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
zkoušel jste i FreeCAD? ten má např. i nějaké testovací napojení na OpenPLM myslím.
9.4.2013 18:51 xxxxxxxxxxx | skóre: 13 | blog: rhrtshrth
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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. :-)
10.4.2013 00:08 jucas
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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 avatar 10.4.2013 00:22 Josef Kufner | skóre: 68
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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í.
Hello world ! Segmentation fault (core dumped)
10.4.2013 08:38 dumblob | skóre: 10 | blog: dumblog
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
+1
Refundace za Windows 7 od Lenovo obchodníka - soud rozhodl, že je zákazník v právu!
16.4.2013 10:39 MichalekII
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
Plánujete zařadit i pevnostní výpočty, či výpočty proudění?
pawleeq avatar 18.4.2013 22:48 pawleeq | skóre: 19 | blog: pawlixblg
Rozbalit Rozbalit vše Re: Cadus - backend bude BRL-CAD
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.
Overground against monoculture.

Založit nové vláknoNahoru

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.