Unde faci SetVertexDeclaration()?

Fac o singura data, undeva dupa BeginScene, inainte sa randez ceva.


LE: Din cate vad doar daca randez tigrul inainte merge. Daca randez alt model tiny, skybox-ul, gruntul... Deci simpla schimbare din
    grunt = new Model( d3ddev, "../data/grunt.x", 0.0f, 1.0f);
in
    grunt = new Model( d3ddev, "../data/tiger.x", 0.0f, 1.0f);
il face sa mearga bine...

Daca randez gruntul,tigrul si particulele merge bine. Daca randez tigrul,gruntul si particulele merge prost.

    Nu am mai facut mare lucru la engine pentru ca a inceput facultatea si am fost ocupat cu mutarea ...

    Am facut un fisier din care citesc ce modele incarc si ce obiecte din joc fac cu ele.(in varianta finala o sa fie pe post de harta fisierul)
    Am reusit sa adaug si culoare la particule, pornesc de la o culoare si se transforma treptat in alta culoare. Nu stiu daca e functia standard de a combina 2 culori, eu am facut media aritmetica intre culoarea texturii si culoarea vertex-ului.
    Am mai adaugat cateva functionalitati micute la particle engine. L-am folosit in screenshot pentru a lasa o urma de foc dupa grunt.
    
    N-am idee exact ce am facut, dar am scapat de bug-ul din post-urile trecute( cred ).
    Vorba aia : Nu lasa pe maine ce poti face azi, lasa pe poimaine poate nu vai mai fi nevoie.
    
    Screenshot: http://img684.imageshack.us/img684/723/screen5d.png

    Am invatat sa fac render to texture. E mai usor decat credeam. Pacat ca nu prea am ce sa fac cu asta in momentul asta in engine.

    Am facut billboarding la particle engine ( poza e tot timpul indreptata inspre camera, adica e paralela cu near clip plane din view frustrum mai exact ).
    
    Din pacate am facut asta in CPU si a dat o lovitura serioasa FPS-ului. Am citit pe net si am aflat ca se face in shader billboarding-ul.
    Aici apare o problema. Eu calculez o matrice de Billboard(obtinuta din matricea View ) si fac pt fiecare particula scalare si translatie. Si rezultatul e ceva de genul scalare*matBill*translatie.
    Ma gandesc sa obtin cumva colturile unui quad de la -1,-1 la 1,1 din coordonatele de textura, sa le inmultesc cu factorul de scalare, sa le inmultesc cu matricea de Billboarding si sa translatez. Problema e ca nu stiu cm sa transmit scalarea pentru toate particulele, pentru ca fac instancing si nu pot sa setez constanta pentru fiecare in parte.
    
    Daca folosesc in structura de input pentru vertex shader TEXCOORD1 pe post de size, are ceva ? Sau size-ul de la pointsprites. Face directx ceva automat cu astea ?
    
    O alta problema e ca acum particulele fac ceva ce semana cu Z-Fighting. Adica apare una in fata, frame-ul urmator cealalta si tot asa . Sincer sa fiu, nu inteleg de ce nu se intampla asta si inainte, ca aveam setat acelasi Z pentru toate particulele la o instanta de ParticleSystem (intre timp am modificat sa nu am acelasi Z la particule). Am schimbat de la
    
d3dpp.AutoDepthStencilFormat = D3DFMT_D16;
    la
d3dpp.AutoDepthStencilFormat = D3DFMT_D24S8;
    
    si s-a mai rezolvat problema. Totusi mi se pare ca precizia e mult prea mica si cu 24 de biti la depth buffer. Adica nu cred ca asa e normal sa se intample.

ToDo:
    Reorganizare masiva ca deja am cam 900 de linii in main.cpp . Am gasit si un model mai modular dupa care sa imi construiesc aplicatia.
    Incerc de cateva zile sa inteleg cum merge treaba cu Skinned Meshes si cu animatia lor. Cred ca am inteles in mare, dar sa vedem cand incerc sa implementez si in engine-ul meu.
    
    

fa disable la depth write cand randezi particles, ca nu prea e nevoie, si le randezi dupa ce toate obiectele opace au fost randate, cu depth test doar, insa nu si cu write

Multumesc, a disparut problema cu Z-Fighting cand am dat disable la Depth Write. Cu toate astea se vede ciudat cand e un particle emitter in departare si se vede peste ceva din fata. Asa se face si in jocurile mari ?

Am facut BillBoarding pe GPU, dar din pacate se misca cam la fel cum se misca si pe CPU.

Am incercat sa folosesc un profiler. Imi arata ca present-ul dureaza mult si din explicatiile de pe site-ul profiler-ului asta inseamna ca programul e CPU-bound.

Am folosit PSIZE0 in shader pentru a retine cu cat trebuie sa scalez;

Am reorganizat codul si am ajuns la "doar" 500 de linii in main.cpp .(de la 900)

Diferenta e gigantica intre debug si release. 25 FPS vs 95 FPS.

In plus, in modul debug, tigrul porneste rotit la alt unghi decat in release(unde e bine). Nu prea am idee de ce inca...

Urmeaza sa incerc sa fac Skinned Meshes.

E absolut normal.



S-ar putea sa ai niste variable neinitializate, care sunt initializate de catre compilator diferit in Debug si in Release .

Mersi, aveai dreptate, in modul debug pornea cu mouse-ul apasat si rotea obiectul cand miscam mouse-ul. Era o variabila pe care o initializa cu true in debug si false in release.

Am reusit sa introduc in engine si animated skinned meshes . Vreau sa fac asta de muuult timp, dar nu e chiar LoadSkinnedMeshAndRunAnimation(5) asa cum ma asteptam . Mai am de inteles cateva chestii din cod, dar e mult mai usor acum ca functioneaza.

Si trebuie iar sa reorganizez codul putin.

    Dupa o pauza impusa de sesiune am inceput iar sa lucrez la engine. Am reusit sa fac unitatile sa se miste si am inceput sa transcriu engine-ul in DirectX 10(pe care nu il cunosc inca). O sa rescriu si terrain-ul ca sa suporte mai multe bucati ca sa nu il desenez pe tot de fiecare data si probabil o sa incerc sa fac si un pathfinding bazat pe tile-uri.

Am pus si un filmulet scurt cu stadiul la care a ajuns proiectul :

http://www.youtube.com/watch?v=K1z3iIQ42s8

Tu scrii shaderele in asm ?

Nu, vroiam doar sa ii suporte engine-ul ca sa ma pot juca cu ei. Am scris doar shaderi care fac lucruri simple in assembly. Oricum, cred ca e bine sa stiu cam ce genereaza codul pe care il scriu, poate mai fac o optimizare la codul generat de compilatorul HLSL.

"* Experience with shader assembly" era trecut ca plus la un job de la Blizzard, deci banuiesc ca nu e chiar inutil sa faci shaderi in assembly.