Už je to tak pol roka, čo som začal pracovať na projekte kubofuturistického rendereru pre blender.
V tej dobe som navrhol skript, ale nevedel som nájsť odvahu (náladu, čas, etc.) aby som ho zrealizoval.

Dnes som spravil konečne ďalší krok a vytvoril som primitívny combiner, ktorý mi za pomoci masky dokáže vrátiť aspoň trocha prezentovateľné výsledky. A tak som si povedal, že už keď som sa dostal takto ďaleko, tak to predsa nezahodím a dokončím. A tak som to pridal do rozpracovaných projektov. Zatiaľ sem prihodím len základný workplan, bugtracker a primitívny renderer s pár výsledkami. Za každý názor, radu, či kritiku vám budem veľmi vďačný, je to fakt zákerná vec a bez podpory to nezvládnem.


Workplan:
návrh systému - OK
primitívna verzia - OK
pythonová implementácia
skript naviazaný priamo na rendrovanie
GUI
kontrola vstupov
implementácia split and merge algoritmu (zrýchlenie v prípade masiek s veľkými blokmi jednej farby)
implementácia image cache (zrýchlenie v prípade nižšieho množstva úrovní v maske a rôzne roztrúsených bodov, optimálne riešenie bez úprav pre väčšinu prípadov)
gradient (algoritmus pre špeciálne prípady s horizontálnym alebo vertikálnym gradientom - motion deform a podobne)
úprava rendrovacieho jadra pre priame rendrovanie - hodne náročné a nepravdepodobné, ale uvidíme, čo ponúkne 2.5

Bugtracker:
podivné šumové artefakty

Abstrakt:
skript by vo výsledku mal vziať animáciu a spojiť ju do jedného obrazu tak, že pomocou masky postupne nahradzuje hodnoty v maske bodmi z framu s rovnakým poradovým číslom (ak je na maske jednička, tak to vloží pixel ktorý je na danom mieste na prvom frame)
napríklad ak vezmeme ako masku gradient, kde úplne vľavo bude jednička a úplne vpravo 255, tak postupne bude obraz morfovať smerom doľava po jednotlivých framoch (viz. výstupy v primitívnom algoritme)

primitívny algoritmus:
prvá verzia algoritmu je veľmi špecifická. používa najhoršiu alternatívu tohto skriptu. funguje nasledovne:
zložka (nazvyme ju loco) musí obsahovať skript, masku (červený kanál obsahuje hodnoty 1-250, zelený a modrý sú prázdne) vo formáte PNG a 250 framovú animáciu vo formáte 0001.jpg .. 0250.jpg
túto zložku umiestnime na localhost a spustíme zavolaním index.php

link na php doplním zajtra, z technických dôvodov mi nejde FTP


na tomto obrázku máme hranol. mení sa len poloha kamery, ktorý sa presúva z pohľadu zpredu do pohľadu zhora


tieto dva obrázky zachytávajú rovnakú animáciu, ktorá je tvorená zoomom na pravé oko popolníka. Ľavý má ako masku kruhový gradient so stredom približne v mieste oka, pravý je tvorený lineárnym gradientom šikmo z ľavého horného rohu


test zmeny osvetlenia. postupne sa mení smer svetla a jeho farba. ako maska bola použitá depth mapa obrazu


pohľad na kocku. postupne rotuje o 360° maska je lineárny gradient zhora dolu


postupná rotácia kamery okolo kocky odhaľuje jej hornú, prednú, ľavú a pravú stranu v jednom momente...

som zvedavy kto ti v tom pomoze. Premna je to spanielska dedina... :)

po přečtení prvních pár řádků jsem si říkal to samý co Siso

myslim ze tu na fore je minimalne jeden clovek, ktory by asi vedel, pockajme co povie az si precita tento thread

ak narážaš na genoma tak on o tom vie prakticky od prvých konkrétnych myšlienok

zujimava vecicka, ja momentalne pisem path tracer ako diplomku a mam uz skoro hotovu integraciu do 2.50 tak keby si nieco potreboval poradit mozno budem vediet

Inak tie artefakty vyzeraju ako ukazkovy alias z podvzorkovania, takze by si asi mal skusit tie pixely z roznych framov nejak filtrovat. Ale myslim, ze s tym aj tak bude problem ak bude v tej animacii velka zmena.
Da sa to nejak zrychlit? lebo robit animaciu a 256 framov kvoli jednemu obrazku je docela brutus... Neviem ci by to slo v blenderi ale vacsinou sa tracuje po pixeloch tak asi idealne by bolo spravit nieco ako
setFrame(0) tracePixel(x,y) pre vsetky pixely ktore maju v maske hodnotu 1
setFrame(1) tracePixel.... tak by si pocital len jeden frame a mal tam celu tu animaciu

kazdopadne zaujimava vecicka

ne ne, genom nie...pantau...a uz sa aj ozval

no zrýchliť sa to dá pár algoritmami, ale bez zásahu do jadra to moc dobre nejde.

Optimálne by bolo že blender by postupoval a pri každom pixeli by strelil správny frame. To sa ale celkom dobre nedá, pretože blender si najprv všetko zapečie a potom až začne strielať pixely.
Druhé riešenie je trochu použiteľnejšie, ale neviem nakoľko je v tejto dobe aplikovateľné tu by skrátenie času fungovalo na tom spôsobe, že vždy by sa vzala maska, kde by bolo číslo framu, ktorý sa aktuálne rendruje, tam by sa dali jedničky, zbytok by boli nuly (proste prienik) a rendrovalo by to len framy ktoré by mali jedničku a zbytok by preskočil. K tomuto riešeniu by som sa chcel dopracovať vo finále.

ďalšie použiteľné algoritmy by bol modifikovaný split and merge, ktorý by dokázal z obrazu vysekať pre každý frame aspoň bordery, ktoré by to značne urýchlili, ale zase tu by to rendrovalo každý border, takže by to bolo super na veľké bloky a nič moc na zbytok

ďalej by sa dalo vytvoriť algoritmus, ktorý ti orámuje oblast, v ktorej sa vyskytuje daná hodnota, to by bolo vinikajúce napríklad na gradienty

posledný algoritmus, ktorý by bol fajn by bola image cache, teda že by to vzalo prvý pixel masky a bola by tam jednička, tak by sa pozrelo do chache, či to má vyrendrovaný frame jedna a ak nie tak by ho vyrendrovalo, ďalší by bol tiež jedničkový pixel tak by to opäť overilo a keďže by to bolo v cache, tak by to tam rovno vložilo, a tak ďalej. Tým by sa vlastne uplne preskočili framy, ktorých hodnoty v maske nie sú, čo by parádne zrýchlylo rôzne skokové masky

a takto by sa to dalo rôzne zoskladať dokopy.

zatiaľ je úloha číslo jeden zosmoliť aspoň základný pythonovský skript (rendrovať to v PHP nie je zrovna košér) a potom môžem venovať čas hľadaniu ciest ako to optimalizovať...

každopádne mám to uznané ako robotu do labáku, takže začínam to brať ako podstatne vážnejšiu vec... (ak to nebude fungovať v skúškovom letím zo školy :P)

tak som cestou vo vlaku v polospánku prišiel k dvom veciam.
zlá je, že rendrovať to pixel po pixeli tiež nie je žiadna výhra u väčších projektov, pretože ak by mal človek v obrovskom rozlíšení počkať na preproces (octree a podobne) tak by to bolo časovo omnoho horšie. Na druhú stranu, dalo by sa to obísť funkciou, ktorá vyrendruje určitý zoznam pixelov z jedného nastavenia. otázkou je, či niečo také existuje...
dobrá je, že ten aliasing nie je nijak zásadným problémom ak sa nám to podarí rendrovaŤ po pixeloch. v tom prípade by sa to nadvzorkovalo bez OSA a oversampling by sa vykonal až po vyrendrovaní pixelu

Skus render rozdlěit na části, které se budou renderovat zároveň, tím by jsi trošku strhnul čas, ale zase se zvedne výkon.
Teď ma napadlo že by tam byly asi chyby, kdyby se to renderoval oněkolik částí najednou ...

no ja som to myslel tak, ze by si spravil ten preprocessing na frame a potom tracoval len casti v obrazku. Ved zatial mozes na tom pracovat tak ako si zacal a zrychlovanie nechat na koniec, mozno dovtedy na nieco prides

tak pripájam ďalšie využitie - tu je maska s ostrými okrajmi a zmena v animácií nie je nijak interpolovaná

(uploadnutý obrázok je zmenšenina ľavého kanálu anaglyfu - som zvedavý ako to bude vyzerať v 3D :P)

originál od M.C.Eschera

Konečně nějaký renderer 4D grafiky, doteď samý trapný konstantní 3D řezy 4D prostoru, s tím se nedá vyrenderovat ani zakřivení objektů v blízkosti časoprostorové singularity, pche! :)

K implementaci (ve 2.5 větvi, u v2.4 by změny asi přišli vniveč)

Vyrenderovat libovolný bod XYt je asi problém, bez rozsáhlých změn kódu rendereru. A alg. OSA by musel uvažovat o jeden rozměr navíc, takže náročnost výpočtu řádově vyšší.
Jako schůdnou cestu bych viděl implementaci render masky přímo v rendereru (v C) a zbytek v Pythonu, který by připravil render a udělal kompozici. Případně vlastní kompozice by šla v udělat v Nodech, např. modifikace nodu image se vstupem pro čas/pořadí snímku v případě nahrání animace. Zbytek by měl jít sdrátovat ze stávajících nodů, problém by mohl být u aliasingu.

"Rendermaska" urychlí čas výsledku a je to natolik univerzální funkce, že by to mohlo stačit pro uznání patche do hlavní větve (když se to vhodně podá). Jako vstup by byl "texturovací" slot, kde lze použít i načtený videosoubor, procedurální textury a text. nody. S animačními schopnostmi 2.5 by šla tedy maska řešit kompletně procedurálně. Kvůli AA by se muselo před vlastním renderingem ještě řešit rozšíření masky o příslušný počet pixelů.

Vlastní renderer by pak byl rozšíření Blenderu (ano, 2.5+ bude mít možnost rozšíření ala Firefox) viditelný v menu rendererů, takže by zbytečně nezahlcoval GUI, pokud by ho někdo nepotřeboval.
Tím samozřejmě v žádném případě nechci říct, že je tato funkce nějak méně využitelná. Třeba ty časoprostorové deformace, to je kilrfjůčr. A třeba takový Dalí, ten by přinejmenším slintal...