w moim rasteryzerze mam algorytm rasteryzacji kulki zrobiony na midpoincie (tym z
wiki) gdzie kazda scanline jest 'drugim' midpointem tylko w plaszczyznie xz

jakos to tam dziala choc ma swoje problemy

potrzebowalbym teraz mw tego samego tylko z cieniowaniem, w sumie zeby zrobic
cieniowanie potrzebuje normalnej do piksela w danym punkcie kulki (tutaj powiedzmy
cwiartka kuli)

// XXX
// XXXXX
// XXXXXX
// XXXXXXX
// XXXXXXXX
// XXXXXXXX
// XXXXXXXXX
// XXXXXXXXX
// XXXXXXXXX

jak wyznaczyc tą normalna, jaki wzór?

(i tak liczenie iloczynu skalarnego z normalna dla kazdego punktu nie jest chyba
za szybkie, moze jest cos lepszego?
- choc tak czy owak tej normalnej tez chcialbym sprobowac)

do góry

niezrozumineie bressenhama zawsze sie smiesznie msci - w sumie mozna omijac
zrozumienie go w nieskonczonosc, ale kiedys tez nalezaloby go pewnie i zrozumiec

(przypomina sie ksiazka sposob na alcybiadesa ktora byla quite very magic jak ja
kiedys czytalem w dziecinstwie)

do góry

w skrocie to jak mam kule zderiniowana przez promien R i lezaca powiedzmy w punkcie
0,0
to potrzebuje wzoru na normalna w punkcie x,y gdzie x siega od -R do R, tak samo Y

namysl sklania mnie do wniosku ze skladowa
z normalnej powinna chyba h = sqrt(1-r*r)
(jesli R=1) gdzie r= sqrt(x*x + y*y)
natomiast skladowe x i y nornalnej powinny wyniscic chyba x i y

czyli normal = x, y, sqrt(1 - (x*x + y*y) ) ?

nie jestem pewien ale niewykluczone

do góry

W dniu sobota, 15 listopada 2014 21:25:01 UTC+1 użytkownik firr napisał:
> w skrocie to jak mam kule zderiniowana przez promien R i lezaca powiedzmy w punkcie
0,0
> to potrzebuje wzoru na normalna w punkcie x,y gdzie x siega od -R do R, tak samo Y
>
> namysl sklania mnie do wniosku ze skladowa
> z normalnej powinna chyba h = sqrt(1-r*r)
> (jesli R=1) gdzie r= sqrt(x*x + y*y)
> natomiast skladowe x i y nornalnej powinny wyniscic chyba x i y
>
> czyli normal = x, y, sqrt(1 - (x*x + y*y) ) ?
>
> nie jestem pewien ale niewykluczone

ok, ten pomysl niby dziala

https://www.dropbox.com/s/puspymkgak7kyt8/kulki.jpg?
dl=0

zwolnilo alepewnie mozna zoptymalizowac nakladem pracy do rozsadnych wartosci
- gorzej ze niby oswitla ale przy ruchu kamery kierunek swiatla sie dziwnie zmienia -
to jest dlatego ze rasteryzacja nastepuje nie tylko w przestrzeni kamery ale co
gorsza w przestrzeni pikseli a nie chcialo mi sie poki co transformowac starannie
normalnej swiatla do tej dziwacznej przestrzeni

do góry

no dobra jakos tam dziala, now it looks like:

https://dl.dropboxusercontent.com/s/3y9xewngn0qwpjh/
kulkish.jpg?dl=0


https://www.dropbox.com/s/lagt88uivonqxr6/zuk.zip?dl
=0

powraca stary problem z plastikowym wygladem swiatla

do góry

polecam do odpalenia wersje 5, w sumie to nawet jest dosyc przyjemne w ogladaniu
(zwlaszcza na fullscreen - trzebabedzie teraz popracowac nad fizyka)

do góry

W dniu niedziela, 16 listopada 2014 20:00:25 UTC+1 użytkownik firr napisał:
> polecam do odpalenia wersje 5, w sumie to nawet jest dosyc przyjemne w ogladaniu
(zwlaszcza na fullscreen - trzebabedzie teraz popracowac nad fizyka)

przy okazji moge powiedziec jeszcze ciekawostke zwiazana z optymalizacjami

mam do wyrasteryzowania taki 'szescian'
z tysiaca kulek (10x10x10) i co sie okazuje o ile patrzec na niego z jednej strony to
rasteryzacja trwa 9 ms o ile z
drugiej to jego rasteryzacja trwa 20 ms

chyba z godzine nie moglem pojac co jest grane bo kod nie mial jakichs specjalnych
rozgalezien
- w koncu zgaduje ze po prostu kulki do rasteryzacji sa poddawane w szybkim
wypadku od przodu (tak ze ten tzw (poniekad sławny) overdraw jest mniejszy)
a w wolnym case od tylu - i to naprawde
(ten spory owerdraw) potrafi zmulic ze 3 razy tak ze da sie zauwazyc np czaowego laga
:/ (to tez wynika stad ze ja licze tu normalna dopiero po depth tescie tak ze dla
takiego overdrav moge liczyc np 10
normalnych zamiast jednej)

z innej ciekawostki jesli zakomentuja taka to slabo wygladajaca procedure

inline unsigned dimColor(float f, unsigned color)
{
//return 0xffffff;

float wa = 0.3;
float wb = 1.0-wa;

if(f<0.0)
{
f=0.0;
}

int b = (color&0xff0000)>>16;
int g = (color&0x00ff00)>>8;
int r = (color&0x0000ff);

float b_ = ((float)f*b*wa + b*wb);
float g_ = ((float)f*g*wa + g*wb);
float r_ = ((float)f*r*wa + r*wb);

b = b_;
g = g_;
r = r_;

return rgb(r,g,b);
}

ktora tutaj po prostu przyciemnia/rozjasnie kolor dla piksela na samym koncu to
wspomniane 10 ms z jednej 20 ms z drugiej steje sie 3 milisekundami
z jednej i 3 milisekundami z drugiej -
(w sumie nie wiem czemu bo tu overdraw tez
powinien byc)
taie male i proste badziewie a konsumuje
66 %, 82 % czasu ramki - i ciagle tenbeznadziejny problem jak to poprawic by bylo ze
dwa razy szybsze @$#%@$#@@!

do góry

W dniu niedziela, 16 listopada 2014 21:48:55 UTC+1 użytkownik firr napisał:
<ciach>

Zamiast przeliczać te r/g/b za każdym razem, wygeneruj sobie tablicę z gotowymi
wynikami, będzie nieco szybciej ;)

AdamK

do góry

W dniu niedziela, 16 listopada 2014 22:35:25 UTC+1 użytkownik Adam Klobukowski
napisał:
> W dniu niedziela, 16 listopada 2014 21:48:55 UTC+1 użytkownik firr napisał:
> <ciach>
>
> Zamiast przeliczać te r/g/b za każdym razem, wygeneruj sobie tablicę z gotowymi
wynikami, będzie nieco szybciej ;)
>
nie rozumiem, dokladniej jak?

do góry

W dniu niedziela, 16 listopada 2014 22:47:56 UTC+1 użytkownik firr napisał:
> W dniu niedziela, 16 listopada 2014 22:35:25 UTC+1 użytkownik Adam Klobukowski
napisał:
> > W dniu niedziela, 16 listopada 2014 21:48:55 UTC+1 użytkownik firr napisał:
> > <ciach>
> >
> > Zamiast przeliczać te r/g/b za każdym razem, wygeneruj sobie tablicę z gotowymi
wynikami, będzie nieco szybciej ;)
> >
> nie rozumiem, dokladniej jak?

Dla jednego składnika masz potencjalnie 256 wyników. Zrób tablicę gdzie dla f masz
t[f] będąca wynikiem.

AdamK

do góry