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.
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 ;)
Nigdy nie miałem najmniejszej styczności z programowaniem grafiki.
Bardzo przyjemny artykulik.
myślałem, że biblioteke w brainfucku++ napisałeś :D dobra robota!
Nawet fajne, ale brakuje jeszcze ogólnego wzoru na kolizję promienia z wielokątem.
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.
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/
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;).
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...
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ę.
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ć...