Am testat editorul meu pe Vista, si se pare ca fiindca pe Vista fiecare fereastra rendeaza in buferu ei (tehnic o textura probabil), nu cum faceau inainte direct pe ecran, a disparut problema de care vorbeam acum 1-2 saptamani, cu rendat in off-screen etc.etc., pt ca atunci cand o fereastra trece peste a mea, nu trebuie sa mai rendeze din nou, starea ferestrei a ramas in buferu' de la Vista.

Nu am intrat in detaliile tehnice cu interfata de la Vista, dar cica face cam asa.

Anyhoo, o alta surpriza placuta a fost cat de rapid se deschid programele, versus hardware asemanator (tot 2GB RAM) pe XP.

Nice

Nice, dar nush daca e chiar asa, cu buffer separat. Gandeste-te cata memorie (video si/sau RAM) mananca numai trei ferestre maximizate. Gandeste-te ca ai 10 (un scenariu destul de des) si o sa vezi cata memorie ar trebui sa ai pe sistem. Cred ca are vreun spiel, adica pe unele le deseneaza direct si pe unele nu ... or something ...

Vista papa 700MB cand porneste, cel putin la mine. Insa e mult mai rapid si mai 'smooth' decat XP.. Ajuta si RAM-ul acela platit ca sa nu mai arunci CPU aiurea. (ce ma costa 40MB = 1280x800 * 10 ferestre maximizate * 4bytes per pixel cand am 2GB, si 256MB vram? Vine un amarat de 2% din RAM )

Hmm. Ma asteptam ca cifra sa fie mai ... mare . My bad, then.

Update http://keen360.blogspot.com/

So, yeah. Cg. Acum ma duc si eu sa ma uit ce e pe acolo...

In capitolul 6 din Cg Tutorial (link in postul de dinainte) am dat peste un articol care explica mura-in-gura cum se fac animatiile pe skelet intr-un vertex shader. Pana la urma iese ca e defapt mult mai simplu decat am crezut. Toata treaba consta in faptul ca nu mai inmultesti pozitia vectorului cu aceasi singura matrice (world view proj), ci cu o anumita matrice (defapt tot in spatiul world view proj, doar ca pregatita de inainte de CPU), in functie de vertex, acea matrice face parte dintr-o lista de matrici 3x4, fiecare reprezentand defapt cate un os din schelet. Si ca sa nu iasa urat ca naiba, fiecare vertex e inmultit cu pana la 4 matrici, si se face blending intre rezultate. (se pot pune si mai mult de 4, dar nu prea vad rostul) Fiecare vertex are setat care matrice/os sa foloseasca atunci cand tot obiectul este creat in programul preferat, skinning/rigging/whatever. (Max/Maya etc.)

M-am speriat putin cand am vazut ca exemplul seteaza numarul de matrici (adica numarul de oase din schelet) la 24, un pic cam mic. Imi trebuie doar putin mai mare, (vre-o 30) asa ca am dat fuga pe MSDN unde am aflat ca un vertex shader modelul 2 si 3 poate tine 256 constante float4, adica aproximativ 80 de matrici 3x4. 80 de oase sunt mai mult decat suficient, insa exemplul Cg nu zice nimic de scalare. Am citit si despre SM4 din curiozitate, si in noua arhitectura (cu cbuffer), pot sa bag la constante pana ma plictisesc.. Insa ce mi-a atras atentia si mai mult e modul cum sunt 'partajate'. (treaba cu cele pana la 16 cbuffers, si ca poti sa faci update numai la buferele care trebuie, nu la toate; iar chestia cu StreamOut suna de-a dreptul criminal de misto)

Am carpit o idee in 5 minute pt a avea si scaling, insa nu stiu daca merge, nu am incercat inca: trimit scalarea ca un float3 intr-o constanta la vertex shader, si multiplic pozitia object space a fiecarui vertex cu scalarea, apoi inmultesc cu matricile oaselor, iar la normale, inmultesc desigur doar cu matricile oaselor. Ma astept sa mearga, dar, ehhh...

O alte chestie care ma lasat nedumerit este "daca artistu' vrea mai putin de 4 weight-uri pe un anumit vertex?". Spre exemplu, pt un skelet uman, nu vad de ce vertecsii de la cot ar trebui sa aiba mai mult de 2 weight-uri, sau cum ar putea avea 3 sau 4. Probabil ca un 'if' in acel loop ar trebui sa ma scape de problema asta:



Deocamdata numai asta imi vine in minte.

So yeah, vertex skinning. Mi-am luat o caramida de pe suflet...

Acum cu ce ma lupt este MAXScript. (trebuie sa il folosim pe asta intern deocamdata) Il iau dupa tutoriale. Limbajul in sine e usor de inteles dupa ce ai citit juma de ora ce si cum sta, e mult in genul Python ca 'feel', insa nu am aflat nimic inca de API.

Deci nu mai faci inmultire la sfarsit cu world matrix? Ca daca faci, poti baga scalarea acolo, fara sa o faci tu manual.

Nu sunt sigur ca am inteles ce vrei sa spui... cum adica sa "bag"... ahh, cred ca te referi, nu sunt sigur ca nu prea cunosc matricile, ca scalarea e cumva ultima linie dintr-o matrice 4x4, si tot ce trebuie sa fac este defapt sa copiez scalarea acolo, nu trebuie sa mai inmultesc?

Adica:



Asa?

In loc de:

Nu, scalarea nu e acolo .

Ce voiam eu sa zic e ca nu inteleg unde inmultesti tu vectorul cu world matrix. Ce ai facut acolo merge, daca modelul sta numai in origine. Daca vrei sa-l faci sa se miste pe la mama dracu trebuie sa mai inmultesti pozitia cu worldu', in care poti baga foarte frumos scalarea.

Ordinea pt geometrie statica vine asa:

world * view * proj

si pui rezultatul intr-o constanta, care e folosita de-a lungul executiei intregului shader, nu mai e recalculata degeaba la fiecare vertex.

Daca nu ma insel, la vertex skinning, ca oricum trebuie sa inmultesti matricile alea ca sa iti iasa hierarcia, le mai inmultesti inainte pe CPU si cu world*view*proj, asa ca, sper, formula e asa:

bone_matrix * world * view * proj

Pt fiecare os, si astea (rezultatele) le bagi in constante.

Ma rog, o sa se clarifice toate mizerile astea din teorie imediat ce termin de scris un exportor pt Max. Good 'ol trial and error...

Paaai e o idee proasta sa le inmultesti pe CPU, pentru ca oricum se vor schimba la fiecare randare a modelului si pe langa povara de pe CPU o sa mai trimiti si matrici la greu spre placa.

LE: Then again, oricum o sa trimiti matrici la greu spre placa, deci nu prea sta in picioare argumentul meu . Keep me posted, n-am facut pana acum animatie din vertex shader, deci sunt curios.

Idea proasta la aia era ca defapt bagi scalare in acea matrice, si face muci normala cand o inmultesti cu matricea aia. Vezi ca era de curand un thread care zice despre asta... cel in care a explicat Dark ce e cu inversa transpusa a unei matrici.

Btw, m-am uitat aici: http://www.gamespp.com/tutorials/matrixTransformationTutorial02.html
Tipul asta explica foarte clar ce e defapt o matrice de transformare

Well I did that too, but you didn't give a flying shit about it .

DUPAIA vazusem cum stau lucrurile intr-o matrice de transformare...
Insa e 7 dimineata si capul meu e varza. Ma rog, "we'll cross that bridge when we get to it".. Cand ai incercat tu sa-mi explici acu vre-un an parca mi-ai zis unde vine fiecare rotatie pt fiecare axa blablabla m-ai lasat la fel de nedumerit ca inainte sa intreb..


Idea proasta la aia era ca defapt bagi scalare in acea matrice, si se duce aiurea normala cand o inmultesti cu matricea aia. Vezi pe threadul "Intrebare HLSL" de la Grafica, cel in care a explicat Dark ce e cu inversa transpusa a unei matrici.

Plus ca daca nu le faci pe CPU, o sa le faci pe GPU din nou pt fiecare vertex. Incerc weekendul asta sa trec o animatie din Max intr-un program D3D.