Koordynaty w RSL (3delight)

[aero]

Witam,

 

mam problem z koordynatami w proceduralnej teksturze napisanej w RSL. Oparta jest o ciag Fibonacciego, tworzy pattern zlozony z kropek.

 

Kod shadera:

float circle(float centerx, centery, radius)
{
float result;
extern float s,t;
float tt = 2*sqrt(pow(centerx-s,2)+pow(centery-t,2));

 if( pow(s-centerx,2) + pow(t-centery,2) //    result = 1;
   result =  abs (smoothstep(0,radius*2,tt)-1);
 else
   result = 0;

return result;
}


surface tiaDot(float spread_radius = .05; float seed_num = 80; float dot_radius = .02)
{
float i = 0 ,x = 0, y = 0, r =0;

float result = 0;;

for(i=0; i{
   x =  sqrt(i) * spread_radius * cos (radians(i*137.5));
   y =  sqrt(i) * spread_radius * sin (radians(i*137.5));
   result += circle(x+.5, y+.5, dot_radius); 
} 
Ci =  result;
}

 

Po nalozeniu na prosty polygon wszystko dziala:

Natomiast po nalozeniu na kule juz nie:

 

Jakis pomysl jak poprawic dystrybucje punktow?

 

P.S. Przepraszam za brak polskich diakrytykow, pracuje na linuxie.

[praetorian]

najprosciej robiąc UV mape na kuli w UV Layout lub czyms podobnym - chyba ze problem jest głębszy :)

[aero]

Zobrazuje problem inaczej - napisalem na bazie tego kodu shader truskawki:

 

 

Niezaleznie od tego czy umieszcze go na NURBSach czy polygonach (unwrap oczywiscie jest zrobiony) to zawsze pattern jest tylko po jednej stronie - jak widac na zalaczonym obrazku.

[kozioo]

shader masz napisany w przestrzeni 2d (z tego co widzę), więc obiekty potrzebują prawidłowego mapowania. Coś z tym musisz mieć źle - nawet na oko widać że tekstura jest nierówno rozciągnięta.

[aero]

Transformujac aktualnie cieniowany punkt na przestrzen "object" otrzymalem w koncu taki efekt:

 

Punkty w dalszym ciagu sa rozciagniete.

[SYmek]

Hej,

fajny wątek, rzadko ktoś się takimi sprawami tu zajmuje. Skąd Ci się to wzięło?

 

Tutaj są dwa tematy. Kształt kropek i ich wielkość. Przestrzeń st nie musi być symetryczna, stąd kropki będę prawie zawsze rozciągnięte. To raz.

Dwa, że transformacja z st do przestrzeni kamery nie jest liniowa, czyli kropki będą miały różną wielkość zależnie od pochodnej st, czyli od wielkości prymitywu.

Pewnie są elegantsze metody naprawy tych mankamentów, ale tak na szybko, żeby załatwić rozciągnięcie kropek swoje tt pomnóż przez stosunek pochodnych st (kod VEX, ale w RSL będzie podobnie):

 

 float ratio = Du(s)/Dv(t);
float tt = 2*sqrt(pow(centerx-s,2)*1.0/ratio+pow(centery-t,2)*ratio);

 

Jeśli chodzi o wielkość kropek, możesz radius przemnażać jakoś tak (tym samym uniezależniasz go od transformacji z st do ndc

 result += circle(x+.5, y+.5, 100*dot_radius*sqrt(Du(s)*Dv(t))/Pz);

 

pozdro,

skk.

 

ps to samo należałoby zrobić z parametrem gęstości - uniezależnić go od transformacji st do ndc, czyli od rozmiaru prymitywu na ekranie. W Twoim kodzie kropki będę gęstnieć na mniejszych prymitywach. To samo mnożenie, co powyżej powinno również pomóc tutaj. Obawiam się jednak, że istota sprawy jest bardziej złożona, a powyższe manewry wątpliwe matematycznie.

Edytowane 3 Sierpień 2012 przez SYmek

[legomir]

http://www.sidefx.com/docs/houdini12.0/shade/transitioning tu masz wypisane różnice miedzy RSL a VEX.

 

Mądra kózko ja zacząłem się uczyć RIB,RSL i VEX ;) Tylko dopiero początki przechodzę

[aero]

Dzięki za podpowiedź Symek i legomir (bardzo przydatny link z tą konwersją VEX do RSL). Znalazłem inną metodę dzięki małej pomocy Malcolma Kessona i przepisuje aktualnie kod na cellnoise().

 

Wzięło mi się stąd, że pamiętam z HA ten digital asset z truskawkami i próbuję go odtworzyć samym shaderem. Takie zadanie-ćwiczenie.