Standardizace metod pro renderování OpenSCAD modelů

kaklik commented 5 years ago

Modely je potřeba umět přegenerovávat pomocí Makefile na základě změn na sobě závislých souborů
STL bude primárně využíváno pro náhledy modelů (github má pro STL integrovánu relativně kvalitní prohlížečku)
Vypadá to, že není schůdné slučovat tiskový soubor s modelovým souborem, protože na tiskový soubor a na zdrojový soubor modelu jsou různé požadavky. (tato záležitost se týká hlavně metadat a tvorby sestav)
Obrázkové náhledy by bylo lepší generovat z již vygenerovaných tiskových souborů, aby nedocházelo k vícenásobnému renderování
Soubor sestavy může být složen z vyrenderovaných tiskových souborů, aby se tak podstatně zkrátil čas renderování sestavy.

JanKott commented 5 years ago

TLDR: 1) Upravil jsem makefile aby generoval jen PRINT (noDRAFT) verze a respektoval závislosti. 2) Soubory bez prefixu P jsem nahradil soubory s prefixem P a ty pak smazal (takže už jsou jen ty bez prefixu v plném rozlišení) 3) Obrázkové náhledy se generují přímo z již vygenerovaných modelů. 4) Soubor sestavy se skládá přímo z vygenerovaných modelů, ale bude zřejmě třeba to ještě odladit. Aktuálně mi po vyrenderování některé části zmizí a mám problém udělat výřez do modelu.

Long story: 1) Upravil jsem makefile tak, aby respektoval změny v závilsých souborech. Make sám neumí dohledat závislosti, ale většina překladačů toto umožňuje. OpenSCAD není výjimkou, používá se pro to atribut -d. Tímto způsobem jsem tedy nechal vygenerovat soubory se závislostmi pro každý generovaný zdrojový soubor (soubory .deps v nové složce dep). Ty se následně includují v Makefile. Jako zdroj informací jsem použil https://www.gnu.org/software/make/manual/make.html

2 + 3. Soubory, které se dříve generovaly s prefixem P se nyní generují bez prefixu. Všechny zdrojové soubory obsahují parametr draft nastavený na true. V tomto režimu se renderují v nízkém rozlišení (aktuálně nastavuju fn = 20, nahrazuju screw za cylinder a curvedPipe nepoužívám pro odečet) pro práci v grafickém režimu openSCAD. V režimu draft = false se model renderuje ve vysokém rozlišení a posunutý/otočený do tiskové pozice. Make automaticky přepisuje proměnnou draft (příznakem -D "draft = false"). Všechny soubory s prefixem P a celou složku print_data jsem smazal.

4) Upravil jsem makefile tak, že při přegenerování obrázku PNG vytvoří dočasný soubor tmp.scad, který obsahuje pouze příkaz import("../amf/WINDGAUGE_XXX.stl") a ten použije pro vygenerování obrázku. Tím pádem není potřeba znovu renderovat model. Navíc jsem změnil závislost obrázků ze SCAD na STL soubory, ale to je spíše kosmetická změna.

5) Upravil jsem soubor assembly.scad tak, aby používal pouze již vygenerované modely. Tohle budu muset ještě ověřit, protože se mi aktuálně po přerenderování ztratí některé části modelu a mám problém, s generováním průřezů.

kaklik commented 5 years ago

Pokusil jsem se novou úpravu použít a vypadá to, že je nějaká potíž s absolutními cestami, které zřejmě někde zůstaly.

kaklik@popelnice:/media/kaklik/91d64ab1-13dc-4023-87e9-e53e8433a489/git/MLAB/Modules/mechanical/WINDGAUGE03A/cad$ make
make: *** No rule to make target '/Users/jkt/playground/OpenSCAD/kaklik/Modules/mechanical/WINDGAUGE03A/cad/src/lib/copyFunctions.scad', needed by '../amf/WINDGAUGE_R05.stl'.  Stop.
kaklik@popelnice:/media/kaklik/91d64ab1-13dc-4023-87e9-e53e8433a489/git/MLAB/Modules/mechanical/WINDGAUGE03A/cad$

JanKott commented 5 years ago

Pokusil jsem se novou úpravu použít a vypadá to, že je nějaká potíž s absolutními cestami, které zřejmě někde zůstaly.

kaklik@popelnice:/media/kaklik/91d64ab1-13dc-4023-87e9-e53e8433a489/git/MLAB/Modules/mechanical/WINDGAUGE03A/cad$ make
make: *** No rule to make target '/Users/jkt/playground/OpenSCAD/kaklik/Modules/mechanical/WINDGAUGE03A/cad/src/lib/copyFunctions.scad', needed by '../amf/WINDGAUGE_R05.stl'.  Stop.
kaklik@popelnice:/media/kaklik/91d64ab1-13dc-4023-87e9-e53e8433a489/git/MLAB/Modules/mechanical/WINDGAUGE03A/cad$

Jé, na to jsem zapomněl. Opravil jsem to ručně a pak doplnim nějakej skript, kterej to vždycky opraví. Problém je v tom, že OpenSCAD vygeneruje všechny cesty k závislým souborům absolutní, kromě cesty ke zdroji.

JanKott commented 5 years ago

Opraveno. Je otázka, kde všude ještě chceš abych to měnil? Našel jsem ještě 2 Makefile, které pracují se *.scad soubory: ./Modules/mechanical/AWSCREEN01A/cad/Makefile ./Modules/mechanical/WINDGAUGE02A/cad/print_data/Makefile

kaklik commented 5 years ago

Já si myslím, že by se na tenhle systém mělo přejít všude. Protože je to změna, ktrá by mohla značně zpřehlednit i jiné mnohem rozsáhlejší návrhy.

Teď jsem si ale zkoušel v aktualizovaném repozitáři spustit make. Trochu mě překvapilo, že změny, které git vidí jsou rozsáhlejší než bych očekával. Konkrétně to vypadá takhle:

$ git status
On branch master
Your branch is up to date with 'origin/master'.

Changes not staged for commit:

  (use "git add <file>..." to update what will be committed)

  (use "git checkout -- <file>..." to discard changes in working directory)

modified:   ../amf/WINDGAUGE_R03.stl
modified:   dep/WINDGAUGE_D02.deps
modified:   dep/WINDGAUGE_R01.deps
modified:   dep/WINDGAUGE_R03.deps
modified:   dep/WINDGAUGE_R04.deps
modified:   dep/WINDGAUGE_R05.deps
modified:   dep/WINDGAUGE_R06.deps
modified:   dep/WINDGAUGE_S01.deps
modified:   dep/WINDGAUGE_S03.deps
modified:   dep/WINDGAUGE_S04.deps
modified:   ../doc/img/WINDGAUGE_D01.png
modified:   ../doc/img/WINDGAUGE_D02.png
modified:   ../doc/img/WINDGAUGE_R01.png
modified:   ../doc/img/WINDGAUGE_R03.png
modified:   ../doc/img/WINDGAUGE_R04.png
modified:   ../doc/img/WINDGAUGE_R05.png
modified:   ../doc/img/WINDGAUGE_R06.png
modified:   ../doc/img/WINDGAUGE_S01.png
modified:   ../doc/img/WINDGAUGE_S03.png
modified:   ../doc/img/WINDGAUGE_S04.png

Přitom bych očekával, že jak soubory .deps, tak i soubory .png budou vygenerovány jako identické. Tj. git nepozná změnu. Je ale možné, že to souvisí s nějakým obsahem časových razítek, nebo něčím podobný nezajímavým. Pro změnu ../amf/WINDGAUGE_R03.stl ale nemám vysvětlení vůbec.

roman-dvorak commented 5 years ago

Nebylo by dobré tento Makefile přesunout do vlastního repozitáře a na všechny další místa, kde se bude používat, importovat jen submodul? Už se používá na docela dosti místech :)

Nebo vymyslet nějaký jiný způsob, jak udržovat tento makefile aktuální skrze více repozitářů a umístění.

kaklik commented 5 years ago

@roman-dvorak Tenhle makefile je dost novinka. Takže se používá zatím u WINDGAUGE03A. Pak bych samozřejmě chtěl, aby se používal i na více místech. Spíš než submodul s makefile je asi lepší zvážit submodul ze složky lib a do této složky přesunout i parametry některých obecněji používaných součástek, jako jsou třeba šrouby a matice.

kaklik commented 5 years ago

@JanKott tak diff na ten deps soubor dopadne takhle:

vypadá to, že se to liší pořadím.

když spustím make znova na takto změněný repozitář, tak se podruhé už nic měnit nesnaží.

 make: Nothing to be done for 'all'

JanKott commented 5 years ago

Přidal jsem sortování *.deps souborů. OpenSCAD ovšem vygeneruje poslední záznam bez escapovaného konce řádku (bez zpětného lomítka) a ten se pak může dostat doprostřed. Proto jsem navíc přidal, že se zpětné lomítko doplní na řádek, na kterém chybí.

kaklik commented 4 years ago

Nebylo by dobré tento Makefile přesunout do vlastního repozitáře a na všechny další místa, kde se bude používat, importovat jen submodul? Už se používá na docela dosti místech :)

Nebo vymyslet nějaký jiný způsob, jak udržovat tento makefile aktuální skrze více repozitářů a umístění.

Tohle je již aktuální záležitost.

@JanKott z makefilu, který tu vznikl je odvozen i úplně nový makefile, který už používá processor3D a obsahuje přípravu pro automatické zpracování modelů.

roman-dvorak commented 4 years ago

@JanKott nedokázal bys udělat nějaký AMFsorter? Je tam stejný problém jako u STL. Že pokud se vygenerují dva AMF soubory tak se liší. A pak to dělá problém GITu. Což je předevšim problém u toho automatického generování výrobních souborů.

roman-dvorak commented 4 years ago

Navrhoval bych ten makefile přesunout do toho repozitáře OpenSCAD_stdlib

kaklik commented 4 years ago

@JanKott nedokázal bys udělat nějaký AMFsorter? Je tam stejný problém jako u STL. Že pokud se vygenerují dva AMF soubory tak se liší. A pak to dělá problém GITu. Což je předevšim problém u toho automatického generování výrobních souborů.

Roman myslí AMF alternativu tohoto: https://pypi.org/project/stlsort/

Po zběžném prohledání webu se mi nepodařilo najít alternativu pro AMF.

kaklik commented 4 years ago

Navrhoval bych ten makefile přesunout do toho repozitáře OpenSCAD_stdlib

Nad tím jsem taky přemýšlel. Ale nevím jak ten make nějak rozumně spouštět, aby se nemuselo lézt kdoví jak hluboko do toho projektu. Nějakým bashovým skriptem?

JanKott commented 4 years ago

@roman-dvorak Já tohle nepozoruju. Vygeneroval jsem si 5x WINDGAUGE_R05.amf a všechny jsou stejné. Můžeš mi dát příklad kde se ti to děje?

JanKott commented 4 years ago

Navrhoval bych ten makefile přesunout do toho repozitáře OpenSCAD_stdlib

Nad tím jsem taky přemýšlel. Ale nevím jak ten make nějak rozumně spouštět, aby se nemuselo lézt kdoví jak hluboko do toho projektu. Nějakým bashovým skriptem?

Pořád nerozumim v čem je problém. Zkoušel jsem si například toto na anemometru - přesunul jsem makefile uplně mimo WINDGAUGE složky a zavolal make s cestou:

jkt@ntb:~/playground/OpenSCAD/kaklik/WINDGAUGE03/cad> make --dry-run --always-make -f ../../makefile_folder/Makefile

A to normálně funguje

Pokud to chcete obráceně (volat z Makefile složky) tak se to udělá takhle: make --dry-run --always-make -C ../WINDGAUGE03/cad/ -f $(pwd)/Makefile

Bez dry-run a always-make samozřejmě. To tam mám pro účely testování.

JanKott commented 4 years ago

Navrhoval bych ten makefile přesunout do toho repozitáře OpenSCAD_stdlib

@roman-dvorak Jinak to asi nebude složitý, to bude hezká pythoní úloha ;-)

načteme soubor, vertexy si uložíme do listu listů:

a = [[-70, 0, 0], [-69, 3, 5], [-69, 2, 7], [-69, 2, 3], [4,5,6]] zjistíme pořadí: [b[0] for b in sorted(enumerate(a),key=lambda i:i[1])] [0, 3, 2, 1, 4]

A pak to podle toho sesortíme.

Otázka zůstává - je to opravdu potřeba? Mě to připadá už sesortěný (používám OpenSCAD 2020.02.16.nightly (git 5696d07))

kaklik commented 4 years ago

Navrhoval bych ten makefile přesunout do toho repozitáře OpenSCAD_stdlib

Nad tím jsem taky přemýšlel. Ale nevím jak ten make nějak rozumně spouštět, aby se nemuselo lézt kdoví jak hluboko do toho projektu. Nějakým bashovým skriptem?

Pořád nerozumim v čem je problém. Zkoušel jsem si například toto na anemometru - přesunul jsem makefile uplně mimo WINDGAUGE složky a zavolal make s cestou:

jkt@ntb:~/playground/OpenSCAD/kaklik/WINDGAUGE03/cad> make --dry-run --always-make -f ../../makefile_folder/Makefile

A to normálně funguje

Pokud to chcete obráceně (volat z Makefile složky) tak se to udělá takhle: make --dry-run --always-make -C ../WINDGAUGE03/cad/ -f $(pwd)/Makefile

Bez dry-run a always-make samozřejmě. To tam mám pro účely testování.

Ano, ale tady je problém, že ten příkaz je závislý na tom projektu. Což je hodně nepříjemný pro dokumentaci, neboť to vyžaduje, aby si uživatel sám upravil ten příkaz podle toho, jak to zrovna má.

kaklik commented 4 years ago

Navrhoval bych ten makefile přesunout do toho repozitáře OpenSCAD_stdlib

@roman-dvorak Jinak to asi nebude složitý, to bude hezká pythoní úloha ;-)

načteme soubor, vertexy si uložíme do listu listů:

a = [[-70, 0, 0], [-69, 3, 5], [-69, 2, 7], [-69, 2, 3], [4,5,6]] zjistíme pořadí: [b[0] for b in sorted(enumerate(a),key=lambda i:i[1])] [0, 3, 2, 1, 4]

A pak to podle toho sesortíme.

Otázka zůstává - je to opravdu potřeba? Mě to připadá už sesortěný (používám OpenSCAD 2020.02.16.nightly (git 5696d07))

Je možný že se to týká jen rozdílných verzí openscad. Vytvořil jsem na to nové issue https://github.com/ThunderFly-aerospace/Openscad_stdlib/issues/3

Taktéž jsem vytvořil nové issue na tu záležitost s makefile: https://github.com/ThunderFly-aerospace/Openscad_stdlib/issues/2

kaklik commented 4 years ago

Tohle issue začalo vypadat poměrně chaoticky, navíc není zřejmě úplně vhodně umístěno. Vytvořil jsem proto nová issue obsahující zde nevyřešené záležitosti v repozitáři s knihovnami.

MLAB-project / Modules

Standardizace metod pro renderování OpenSCAD modelů #18