Z pogranicza

Raytracing: Spis treści

msm

Raytracing: Krok po kroku

spis treści

Część I - pierwsze kroki [#]_
ray.1.pdf

Część II - realistyczna kamera [#]_
ray.2.pdf

Część III - płaszczyzny
ray.3.pdf

Część IV - światło
ray.4.pdf

Część V - cień
ray.5.pdf

Część VI - model Phonga [#]_
ray.6.pdf

Część VII - doskonałe odbicie lustrzane [#]_
ray.7.pdf

Część VIII - sampling i antyaliasing [#]_
ray.8.pdf

Część IX - depth of field [#]_
ray.9.pdf

Część X - soft shading
ray.10.pdf

Część XI - przeźroczystość
ray.11.pdf

Część ilustracji do części V, VI i VII wykonanych przez Timagesa.

.. [#] Część I:

  • Dodatek: Diagram klas w projekcie: ray.1.graph.png
  • Poprawka: Off-by-half-pixel w metodzie Raytracer.Raytrace (rysowała scenę przesuniętą o pół piksela od ideału); poprawienie ilustracji;
  • Poprawka: Wytłumaczenie działania cross-productu; mandelbrota -> Mandelbrota; (dzięki Jadeszek)
  • Poprawka: Normalised -> Normalized; Wydajność właściwości; (dzięki Rev)

.. [#] Część II:

  • Poprawka: PinholeCamera -> Pinhole; Dowolna orientacje względem ... (reprezentowany ...) -> Dowolna orientacja względem; (dzięki Jadeszek)

.. [#] Część VI:

  • Poprawka: Pomineliśmy -> Pominęliśmy; (dzięki Patryk27)

.. [#] Część VII:

.. [#] Część VIII:

  • Poprawka: Przecinki przed żeby, elegancji -> elegancki, próbek -> próbkami, SampleDistribution -> SampleDistributor(dzięki Patryk27)
  • Poprawka: Wyrenderowany prawidłowo obraz na końcu.

.. [#] Część IX:

  • Poprawka: Przecinki, literówki (dzięki Patryk27)
  • Poprawka: Wyrównany układ stron, dopisek o związku z antyaliasingiem.

Wszystkie artykuły oraz kod dostępne na licencji http://creativecommons.org/licenses/by/3.0/ .

Z pogranicza

Raytracing w C# - część 3

  • 2012-06-06 16:55
  • 0 komentarzy
  • 2958 odsłon

Raytracing w C# - część 2

  • 2012-06-06 16:48
  • 0 komentarzy
  • 2757 odsłon

Raytracing w C# - część 1

  • 2012-06-05 16:15
  • 0 komentarzy
  • 6157 odsłon

42 komentarzy

Wiem jeszcze o co najmniej dwóch osobach które czytają, poza tym ktoś ostatecznie nabija wyświetlenia czyli raczej tak :]. Ad. pracy to cieszę się że się do czegoś przydały.

Hehe zastanawiam się czy oprócz mnie ktoś to czyta;) Nie widzę wysypu polskich rendererów na rynek;) Zaglądnąłem przy okazji bo twój sampling i kamera wirtualna wylądowały w pracy licencjackiej;) Dzięki!

No nie mam już wymówek na odkładanie :]. Wrócę do tematu w najbliższym czasie.

To jak kolego? Kiedy będzie kaustyka? ;)

Spoko. Obserwuję postępy w dalszym ciągu.

...po czym spóźniłem się jeszcze dwa tygodnie. Ogólnie mam nadzieję że wrócę do nawyku kończenia raz na tydzień/dwa, bo rzucać tego chwilowo nie zamierzam... Aczkolwiek mam wrażenie że coraz bardziej chaotycznie piszę, będę musiał chyba kiedyś wszystko jeszcze raz przejrzeć i bezsensowne fragmenty przepisać.
A, i nie poprawiłem miękkich świateł nie dlatego że zignorowałem Twoje komentarze, tylko dlatego że po głębszym przemyśleniu, na chwilę obecną się nie da bo jedyną figurą są kule właśnie (płaszczyzn się nie da samplować bo mają nieskończoną powierzchnię). Kiedy zrobię jakieś trójkąty do wczytywania modeli to poprawię światła, brzmi jak sensowna opcja...

Tak, wybacz spóźnienie spore, wiem że przesadzam ;]. Jeśli wszystko pójdzie dobrze, niedługo będzie część kolejna.

Kroi się coś nowego?

Tak jak mówiłem zależy jak widzisz swój program w przyszłości. Możesz sobie wymarzyć superpoprawny fizycznie raytracer, który będzie w gruncie rzeczy bezużyteczny - za to będzie świetnym materiałem poglądowym i chyba w tę stronę idziesz. Możesz napisać szybki ale wykastrowany z bajerów renderer z wieloma rodzajami świateł, w którym na pewno nieźle odnajdą się animatorzy. Możesz też napisać kolejnego klona vraya. Niezależnie od drogi którą wybierzesz zapisuje się na betatesty;)

Poza tym powiem ci że w praktyce pierwsza rzecz jaka dyskwalifikuje renderer to brak możliwości exportu jakiegoś elementu sceny. Raz nie łyknie siatki z n-gonami, innym razem cząsteczek czy czegoś innego innym razem krzywych. Jest sporo rendererów które pomimo fajnych możliwości nie są używane właśnie z tak trywialnego powodu;)

Przy GI (ściśle, path tracing) faktycznie sens mają tylko światła obszarowe, zazwyczaj 'płaskie' - do GI jeszcze trochę czasu i i tak nie wiem co z nim robić. Obsługa Ambient Occlusion wbrew pozorom jest dość prosta, brzmi w sumie jak dobry pomysł, najwyżej będzie więcej szumu.
W zasadzie masz rację... Ale z tym nie ma za bardzo jak czegoś zrobić bo wcześniej trzeba by było zaimplementować kilka nowych figur geometrycznych które by się dało wykorzystać np. jako źródło światła. Można by napisać część i pozamieniać kolejność w sumie...
A i tak cała ta seria to z założenia wprowadzenie, jeśli kogoś coś zainteresuje to kod ma być na tyle łatwy w rozszerzaniu żeby to bez problemu osiągnąć.
Jeszcze zobaczę :>

No właśnie moim zdaniem nie masz racji. Jeżeli piszesz tak dla siebie edukacyjnie to wiadomo że można pominąć. Ale to że niewiele osób potrzebuje to bujda. W oświetleniu wizualizacji (czyli tam gdzie masz GI) większość używa właśnie planelightów. Podobnie jest przy packshotach i innych stillach. Postacie także oświetla się najczęściej plane'ami żeby zasymulować softboxy.

W animacji gdzie GI nie używa się tak często (chociaż coraz częściej ale to przy dużych nakładach na rendering) właśnie planelightów używa się do fake'owania GI. Wszelkiego typu odbicia właśnie lecą na plane'ach. Często wykorzystuje się też Ambient Occlusion (Chociaż to nie ma nic wspólnego z unbiased renderingiem który tu propagujesz;))

Miało to wyglądać zupełnie inaczej, właśnie mniej-więcej tak jak opisujesz. To nie jest czepianie się, bo masz rację - ale taka wersja w jakiej to zrobiłem była prostsza i stwierdziłem że mało osób będzie potrzebowało np. światło w kształcie kwadratu (nie wspominając, że wcześniej miał być rozdział o figurach 2D który też jest pominięty - będą trójkąty przy modelach najwyżej).

Bardzo fajny artykuł. Ale specjalnie dla ciebie mała łyżka dziegciu z praktyki. Twoja klasa światła ma tylko konstruktory dla światła w kształcie kuli. Tak samo miały z tego co się orientuję stare śwatła mentala i do wprowadzenia photometric lights nawet utworzenie świecącego plane'a dawało podobny - mało zadowalający efekt w postaci świateł świecących jak kule, tylko przyciętych w mało elegancki sposób. Optymalna i uniwersalna byłaby możliwość tak jak w vrayu przypisania światła do każdego kształtu, jest tam nawet opcja "pick shape from geometry" czy jakoś tak;). Wiadomo że się czepiam, ale myślę że takie opcje to podstawa w dzisiejszym cg;)
Śledzę całyy czas twój projekt i jestem naprawdę pełen podziwu. Trzymaj tak dalej.

Powiem Ci że napisałem wcześniej coś o bokeh, skreśliłem, napisałem od nowa, znowu skreśliłem bo mi się nie podobało :>.
Ogólnie też lubię bokeh, szczególnie te o ambitnych kształtach jak sześcian a nie nudne kółko, ale jakoś ciężko to sensownie opisać, więc raczej poczeka chyba że mi przyjdzie natchnienie na trzecią próbę pisarską.

O, dof mój ulubiony temat;) Gdybyś jeszcze napisał skąd bierze się bokeh to już byłby kosmos.

Nie no, refrakcję pierwszy raz implementowałem kilka lat temu (w pierwszym raytracerze, i na tym wtedy skończyłem) więc idzie się do pewnych rzeczy przyzwyczaić.

Edit: Ech, jednak robię sampling, bo już miałem początek napisany i nie chciałem zaczynać pisania od nowa... To znaczy że prawdopodobnie Twoja refrakcja się trochę odwlecze (bo jak sampling to jego zastosowania w kolejnych częściach też), ale co tam, zostanie na deser :>. Tak czy inaczej jest 4:21, mimo że ostatecznie nie skończyłem (1 podrozdział właściwie został) to czas na dzisiaj chyba kończyć...

Nvm, rozmowa w komentarzach to chyba niespecjalnie dobry pomysł.

Edit2 - na razie wrzucam kod specjalnie dla Ciebie (http://speedy.sh/Wjatm/Article.Raytracing.zip) - ale chyba zainwestuję w GitHub-a i wrzucę tam projekt, kodu się raczej w większości nie muszę wstydzić :>.

Widzę że już zgłębiłeś temat;) Niezłe masz tempo.

Pudło, załamanie występuje przy przechodzeniu między ośrodkami, czyli nie będzie załamania pomiędzy próżnią i próżnią, szkłem i szkłem, powietrzem i powietrzem, ale pomiędzy próżnią i szkłem, owszem :>

No chyba że próżnia;)

No tak, ale refrakcja to zjawisko występujące razem (wtedy i tylko wtedy gry) z przeźroczystością - jeśli coś jest przeźroczyste to załamuje (refrakcja właśnie) światło.

Kod - da się załatwić, właściwie to chyba powinienem go dodawać do każdej wersji... Mam na pewno ostatnią wersję bo wypełniam ją podczas pisania i dodatkowo repozytorium w git poprzednich wersji, chociaż nie dam głowy czy kompletne. Jak zrobię część następną (postaram się to zrobić dzisiaj w nocy) to wyślę i gdzieś tutaj kod wrzucę.

A przy okazji, można gdzieś ściągnąć kompletny kod? Niespecjalnie mam ochotę to pisać, a cciałem sprawdzić działanie:)

Mówię o refrakcji (także dla materiałów o grubszych ścianach) ponieważ IMO kiedy domkniesz wszystkie fizyczne możliwości materiału (odbicie, pochłanianie, refrakcja, scattering, emisja) będziesz mógł zoptymalizować dla jego możliwości cały proces renderingu. Wejdziesz w rendering i okaże się że trzeba będzie przepisywać od nowa.
Pomijam oczywiście rzeczy, które trzeba fake'ować (tak jak sss na przykład)

Właściwie to planowałem zrobić wprowadzający artykuł (sampling) a później lecieć wszystkimi albo niektórymi zastosowaniami (soft shadows, antyaliasing, glossy reflection, depth of field itd), ale przeźroczystość też brzmi dobrze (tylko jest, jeśli chodzi o podstawy teoretyczne, trudniejsza). Ok, coś jakoś wymyślę.

Na tym etapie proponowałbym dodać rerfakcję.

Swoją droga przypomniałeś mi że trzeba by było napisać jakąś kolejną część (która zapowiada się na nudną ale konieczną...), bo od ponad tygodnia nic nie wrzuciłem :>

No to powodzenia;) Będę śledził temat.

Kilka raytracerów napisałem (nigdzie projektów nie wysłałem tak czy inaczej), ale nic co mogłoby konkurować z tymi powyższymi. Trochę się tym interesuję, ale te artykuły piszę bardziej z myślą o prostym niż szybkim kodzie :>. Może kiedyś coś napiszę o realtime raytracingu (na GPU), ale to raczej z zupełnie innej okazji bo to by się wiązało z przepisaniem wszystkiego od nowa.

Niby słusznie. A tak z ciekawości, jesteś autorem jakiegoś silnika renderującego? Zastanawiam się w jakim kierunku pociągniesz ten projekt. Szczególnie ostatnio ilość możliwości wzrosła. Są renderery jak Octane (którego używam) liczące wszystko na CUDA, są tradycyjne na cpu jak mental, a ostatnio hybrydowe. Interesujesz się tymi technologiami czy to taki projekt raczej dla sztuki?

Zresztą, w artykule który podlinkowałem przed chwilą:

Theoretically reflections, refractions, and shadows are all examples of global illumination, because when simulating them, one object affects the rendering of another object (as opposed to an object being affected only by a direct light). In practice, however, only the simulation of diffuse inter-reflection or caustics is called global illumination.

Bo to tak czy inaczej jest indirect illumination (światło nadchodzi odbite od innego obiektu a nie od źródła), ale lustrzane odbicie jest 'specjalnym przypadkiem' dla którego obliczenia wykonuje się znacznie prościej (dlatego pewnie nie ma opcji jako takiego wyłączenia odbicia w większości programów - po prostu zmieniasz materiał i odbicia nie ma). Z drugiej strony, innym przykładem indirect illumination jest to o czym mówisz - przy czym znane bardziej pod nazwą http://en.wikipedia.org/wiki/Global_illumination - bardziej kosztowne obliczeniowo i trzeba trochę bardziej kombinować.

Bardzo fajne artykuły. Sam zajmuję się grafiką i dowiaduje się wiele nowych rzeczy. Zastanawiam się tylko dlaczego piszesz że odbicie lustrzane to indirect illumination. W większości oprogramowania na którym pracowałem (np. w mentalu) indirect illumination nie odnosi się do odbić. Wytłumaczę na przykładzie. Lampa rzuca światło na lustrzaną kulę, a to odbija się i oświetla ścianę. Jeżeli wyłączę Indirect Illumination to kula wciąż odbijać będzie ściany i lampę. Odbite od niej światło nie będzie jednak oświetlać ściany.

Dzięki, to teraz będę się musiał chyba zająć również utrzymywaniem podartykułów :>.
Btw. nie znam się na HTML i CSS, ale wygląda na to że div style="text-align: center" kłóci się z ramką Strony w tej kategorii (browser = Firefoxie)...

Aaaa ok. Zajme sie tym.

Tak, mozna. W panelu administratora. Chodzi o to, aby przeniesc z Raytracing z kategorii Z pogranicza, do kategorii glownej, tak, aby tworzyla adres 4programmers.net/Raytracing ?

@Adamie a można przenieść istniejące artykuły tak by utworzyć osobną podkategorię? Swoją droga kto może przenosić artykuły?

Jezeli dodamy nowy artykul, w ktorym artykulem macierzystym bedzie wlasnie Z pogranicza/Raytracing, to automatycznie artykul Raytracing staje sie kategoria.

Ja jako moder też nie mogę. Zażalenia do Adama :P
Aczkolwiek, zmieniłem ścieżkę na "Raytracing" i generalnie można dodawać artykuły, których dokumentem macierzystym będzie właśnie ten tekst (Z pogranicza/Raytracing), czyli jakby tekst jest również kategorią.

Ja też nie mogę zmienić typu artykułu.... jeszcze pokombinuję i zobaczymy.

Byłoby fajnie, tylko

  1. teraz chyba jako zwykły, szary user nie mogę zmienić dokumentu macierzystego
  2. i tak już raczej zrezygnowałem z wgrywania poszczególnych części czyli to jest de facto jedyny artykuł

A może by z tego zrobić osobna podkategorię?