Pokud mne moje pamet neklame, tak anglicky vyraz 'manifold' se v tomto (matematcikem) kontextu preklada jako varieta, coz je obecny n-rozmery prostor, jehoz loklani topologie je podobna eukleidovske, ale globalni uz ne (doufam, ze jsem timhle zjednodusenim nenastval zadne matematiky). Treba povrch Zeme se da v malych meritkach uvazovat jako rovina, ale ve velkych uz ne, protoze je to povrch koule (presneji receno geoidu, at zas nenastvu zadne kartografy a geology). Takze 2-manifold bude dvourozmena varieta. A onen efekt je hlavne zpusobeny konecnou reprezentaci cisel v pohyblive radocve carce, ktere nemohou byt z vlasni podstaty testovana na presnou rovnost, ale jen na nejaky interval (coz je prave ona varieta).
Myslím, že o tom bude řeč v dílu o fotonech (Photons) a "vnitřku" (Interior), který definuje věci jako index lomu vnitřního materiálu objektu a umí i ty tvoje prasátka.
http://en.wikipedia.org/wiki/Photon_tracing
-------------------------------------------
ps: "...programmed in C by Richard Keene, it took 100 Sun 1 computers operating at 1 MHz a month to render a single image." :-)
Nojo, to byly casy :-) Dneska jsme samozrejme s rychlosti uplne nekde jinde, ale i tak je photon tracing uz principielne pomalejsi nez raytracing. Vsak si prednosti a zapory obou metod (a vlastne jeste radiosity) jeste v serialu ukazeme.
kdysi jsem pracoval s metodou bidirectional path tracing, potazmo metropolis light transport, ktera byla (mimo jine) excelentni pro tyto typy scen. mozna by slo se zminit i o nich?
wow, a nebude na root.cz nekdy serial OpenGL pro pokrocile? docela rad bych umel raytracing v opengl, na inernetu je uz tahle slozitejsi vec vetsinou nevysvetlena a ze zdrojaku se to bez teorie pochopit neda :/
A k cemu ti to bude, muzes rici ? pises vlastni render ?
Osobne cekam kdy se akcelerovany rendering konecne zavede do vsech vyznamnych 3D vizializacnich programu.
Zatim to vypada ze vyrobci na GPU raytracing / GI trochu kaslou a nechavaji problem na strane uzivatele = kup si ctyrjadro nebo rovnou renderfarmu a neobtezuj ;-)
Na modelovani mechanik a jinych nezivych veci se hodi kde co (nic proti BRL CADu), problem nastava s organikou ktera je daleko komplexnejsi rozmanitejsi a rada se ruzne slozite hejba ;-)
Jde to tak daleko ze se pouziva modelovani kostry a svalu do fantomu, ktery se nasledne potahne kuzi a ta se pouzije jako model k dalsimu.
Ruznym oblastem se priradi ruzne modifikatory aby se "kuze" chovala treba gumovite, modifikatoru je cela rada vcetne "kosti" atd.
Velka sranda.
Mechanika je IMHO dost mala podmnozina. Pokud tedy nema jit o detailni simulaci nejakeho stroje.
Pekny clanek, s Pov-Ray jsem si drive chvilku hral, ale pak jsem presedlal na image based rendering v OpenGL. Nicmene raytracing me hodne laka a docela by mne zajimalo jestli je nejaka moznost jak indexovat v Pov-Ray ruzne textury (nebo casti jedne textury) v zavislosti na elevaci uhlu osvetleni vuci normale povrchu. Rekneme neco jako pouziti primych BRDF dat bez nahrady pomoci nejakeho BRDF modelu. Diky moc.
Podle me by to snad melo jit pomoci jazyka POV-Raye popsat. Vektorove operatory tam jsou, normalove vektory lze taky vyjadrit, akorat asi bude problem se zakrivenymi povrchy. K cemu to je konkretne zapotrebi? Modulace normaly?
Jinak takovou silu, jako shadery ten POV-Rayovsky jazyk samozrejme nema (ted se bavim o originalnim POV-Rayi), protoze pracuje na urovni popisu sceny a nelze tak resit klasicke shadery.
Diky za odpoved! Myslel jsem, ze mam rekneme tabulku hodnot pro ruzne hodnoty elevacniho a azimutoveho uhlu vzhledem k normale textury. Behem vykreslovani bych chtel tyto hodnoty mapovat na pozadovane misto povrchu objektu v zavislosti na vyse zminenych osvetlovacich uhlech pro to dane misto. Tj. pro kazde misto se vypoctou osvetlovaci uhly a temito uhly se zaindexuje do tabulky hodnot. Mate pravdu, v podstate se snazim o funkcionalitu klasickeho GLSL shaderu.
Diky (i Kvakorovi) za upozorneni. Priznam se, ze jsem vzdycky pouzival termin manifold a ani me - sprosteho IT programatora, nikoli matematika - nenapadlo, ze to ma cesky preklad :-( Takze diky za info!
btw: nepouziva termin manifold i Zara ve svych knizkach? Musim se mrknout.
Z prikazoveho radku je to volba +F
F[x] = write output file (in format x)
FC - Compressed Targa with 24 or 32 bpp
FN[n] - PNG (n bits/color, n = 5 to 16, default is 8)
FP - PPM
FS - System specific
FT - Uncompressed Targa with 24 or 32 bpp
Pokud pouzivate IDE ve Windows (tam jsou totiz BMP opravdu implicitni), muze se napriklad editovat prislusny ini soubor - proste se do nej tato volba dopise. Kdyz to v IDE nenajdete (je to trosku schovane), muzu popsat cely postup presneji.
Diky za serial. Zajima mne hlavne fyzikalni modelovani. Mozna jsem uplne mimo, ale pripada mi ze, paprskova teorie v pocitacove grafice trochu zaostava, za paprskovou teorii vyvinutou v geofyzice. Geofyzika se puvodne samozrejme inspirovala optikou, ale teorii paradne matematicky vybrousila, zdokonalila. Kaustiky, amplitudy (intenzity) - vse je pod jednou teorii, s obecnym resenim, ktere klade duraz na praxi. A dost je toho naprogramovano. Vyuziva se toho nejak v pocitacove grafice?
No ona samotna metoda raytracingu je vlastne tak trosku podvod a s fyzikou to ma spolecne jen vypocty odrazu a lomu. Osvetlovaci model (Phong) je taky udelany na miru lidskemu vnimani obrazu a ne na fyzikalni podstate svetla (Lambert). Proc to tak je? Predevsim jde o rychlost. Samozrejme je mozne vsude pouzit dopredne sledovani paprsku (photon mapping, particle tracing), ale je to silene pomale a hlavne ty vysledky vetsinou neodpovidaji celemu tomu usili, takze se photon mapping pouziva na jednotlive objekty a ne cele sceny.
Mmm, s tim 'podvodem' bych si dovolil nesouhlasit. Paprsky jsou nastrojem pro priblizne reseni Maxwellovych rovnic (nebo treba elastodynamickych rovnic). Paprskova teorie prave vymezuje za jakych podminek to funguje (a proc to funguje - matematicky).
Teorie by mohla pomoct prave tam, kde jevi soucasne metody ponekud zdlouhave (photon mapping, particle tracing - co jsem pochopil, metody budovane dost intuitivne). Myslim, ze pojmy typu 'paprskova trubice', 'dynamic ray tracing', 'ray centered coordinates' by mozna mohly pomoct. Co si pamatuju, znam-li drahu paprsku - intenzitu muzu vyresit rovnici a nemusim strilet paprsky vedle a pak interpolovat apod. - melo by to byt efektivnejsi.
Ale samozrejme souhlasim s tim, ze dulezita je rychlost - usit vypocet/modelovani na miru problemu (zanedbat nepodstatne).
Ohybani paprsku se samozrejme v geofyzice uvazuje. Dost se toho udelalo jiz v 70. letech, sponzorovali/sponzoruji to "naftarske firmy" - klade se duraz prave na praxi a efektivitu. Pro pocitacovou grafiku to muze byt teda docela podnetne.
Abychom si rozumeli: tim "podvudkem" jsem myslel pouziti v raytracingu, kdy se vlastne paprsek sleduje zpetne a zanedbava se spousta veci okolo. Proto se take v nekterych pripadech pouziva radiozita, ale u ni se opet zanedbavaji nektere veci, napriklad lomy.
Chapu, nazvoslovi je boj (pod pojmem raytracing si vybavim system rovnic - ne jeste zpusob reseni a algoritmizaci ...).
Hodne tech zanedbani pri hledani paprsku se da 'pretlumocit' do zanedbani detailu modelu (sceny). Vyznam paprsku furt zustane. A da se s nim dal pracovat - treba pocitat intenzitu. Tim myslim, ze samotny raytracing (pro jeden paprsek) lze vyuzi jako zaklad pro vypocet intenzity (nemusim pouzivat neco jineho - napr. radiozitu apod.).