Artykuł o raytracingu

16

Ave!

Ostatnio mnie trochę wzięło na napisanie czegoś ambitnego więc spróbowałem swoich możliwości stworzenia czegoś dłuższego niż kilkanaście linijek w języku nie służącym do programowania.

Raytracing: Spis treści

No ale na lekcjach polskiego się nie uważało i nie jestem specjalnie pewien swoich zdolności literackich - więc byłbym wdzięczny za jakąś krytykę/wskazanie rzeczy do poprawienia...

Z góry dzięki ;)

1

Nigdy nie miałem najmniejszej styczności z programowaniem grafiki.
Bardzo przyjemny artykulik.

1

myślałem, że biblioteke w brainfucku++ napisałeś :D dobra robota!

2

Nawet fajne, ale brakuje jeszcze ogólnego wzoru na kolizję promienia z wielokątem.

1

Jeszcze o GI napisz :D Nie no, żartuje :P
Ja z grafiką 3D miałem już trochę wspólnego, ale nie od strony programistycznej - w wolnej chwili chętnie przeczytam, na razie pobieżnie przejrzałem.

1

Jeśli już musisz robić w raytraycingu grafikę 2D to chociaż zrób jakieś fajne kolory...

Np. przy pomocy "triady" na stronie:
http://colorschemedesigner.com/

1

Fajnie się czyta i wszystko ładnie wyjaśnione. Brakuje mi na końcu jakiś informacji, co dalej. Mogłeś wspomnieć - hasłowo - o jakiś strukturach przyspieszających, algorytmach kolizji z trójkątem, cieniowaniu, teksturowaniu, światłach itd. A także podać może jakieś linki do innych artykułów np. tego http://www.flipcode.com/archi[...]ues-Part_1_Introduction.shtml. Ale tak ogólnie to dobra robota;).

0
vpiotr napisał(a)

Jeśli już musisz robić w raytraycingu grafikę 2D to chociaż zrób jakieś fajne kolory...

Kto mówi o grafice 2D - obiekty i obliczenia są przeprowadzane w 3D - po prostu 'renderowanie' obecnie jest dość ubogie.
A co do kolorów - na razie zostanę przy R, G i B, później będą minimalnie zmodyfikowane (monochromatyczne kolory (bardzo) kiepsko wyglądają przy próbach obsłużenia odbić i przezroczystości). Uwierz że później to całkiem nieźle wychodzi.

xxx_xx_x napisał(a)

Nawet fajne, ale brakuje jeszcze ogólnego wzoru na kolizję promienia z wielokątem.

Bryłą, z tą grafiką 3D to pisałem poważnie :] Mogę dopisać kolizję i obliczenia związane z trójkątem. Obecnie następną rzeczą którą zamierzam wysłać jest płaszczyzna, może to Ci się spodoba :>.

krwq napisał(a)

myślałem, że biblioteke w brainfucku++ napisałeś :D dobra robota!

Ciągle mam komuś obiecane napisanie kółka i krzyżyk na planszy dowolnej wielkości w Brainfucku - nie myślcie że zapomniałem!

naczelny szaleniec 4p napisał(a)

czekamy na kontynuację :)

pozytywista napisał(a)

Fajnie się czyta i wszystko ładnie wyjaśnione. Brakuje mi na końcu jakiś informacji, co dalej. Mogłeś wspomnieć - hasłowo - o jakiś strukturach przyspieszających, algorytmach kolizji z trójkątem, cieniowaniu, teksturowaniu, światłach itd.

W sumie mam napisane - ale w stanie dość szczątkowym, wymagającym pewnie kilku poprawek - sześć tekstów na ten temat. Tak więc będzie 'dalej', nie tylko hasłowo. Mimo posiadania pewnego zapasu zamierzam wrzucać coś raz na jakieś trzy dni (żeby wyrobić się z pisaniem) - ale życie i obowiązki to mogą zweryfikować :<. Jeśli to sugerowałeś, spróbuję dodawać pod koniec każdego artykułu jakieś co w następnym odcinku.

Jedyne co mnie martwi to fakt że początki przy pisaniu raytracera są dość przydługawe i zanim się dojdzie do jakichś efektów trzeba grzebać w kodzie - wydawałoby się - bez efektów.

Hmm, to dzięki za odezwanie się, czuję się zmotywowany do dalszych prób :>.
Ale mimo wszystko jakaś (konstruktywna) krytyka dot. rzeczy do poprawienia jest mile widziana bo nie łudzę się co do moich możliwości pisarskich...

1

Jestem ogromnym zwolennikiem programowania "po angielsku", a raczej "po amerykańsku". Stąd, napisałbym normalized, a nie normalised.

Dodatkowo zastanowiłbym się czy nie zrezygnować z automatycznych właściwości w strukturach. Wymagają one wywołania domyślnego konstruktora, który wyzeruje backing fields. Ty i tak ustawiasz je wszystkie we własnym konstruktorze, więc dochodzi do pewnej redundancji. Kompilator x86 potrafi to zoptymalizować, ale x64 już nie i na moim sprzęcie utworzenie takiej struktury jest o 60% wolniejsze.
Wiadomo od dawna, że kompilator x64 trochę posysa i w zasadzie niewielu z niego korzysta, no, ale warto to wziąć pod uwagę.

0

Jestem ogromnym zwolennikiem programowania "po angielsku", a raczej "po amerykańsku". Stąd, napisałbym normalized, a nie normalised.

Good point, szczerze mówiąc nawet tego nie zauważyłem... Trzeba będzie chyba wszystko poprawić :(.

Dodatkowo zastanowiłbym się czy nie zrezygnować z automatycznych właściwości w strukturach.

Proponujesz publiczne pola? Szczerze mówiąc właściwości w tym miejscu nie mają żadnych specjalnych zalet (X, Y i Z się przecież raczej nie zmieni...) i zastanawiałem się nad tym (tym bardziej że nawet MS swoje standardy w tym względzie czasami ignoruje, np. klasa Vector z XNA) - ostatecznie uznałem że premature optimization itd, ale jeśli różnica to 60% to chyba warto to rozważyć...

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0