[Direct3D] Wavefront OBJ inladen en renderen

[Orwell]

Eerst eens die code:

C++:

int numverts,numfaces = 0;
char str;
char currentregel[256];
int i1,i2,i3 = 0;
float v1,v2,v3 = 0.0f;
std::ifstream fileStream("box.obj",std::ifstream::in);
while(!fileStream.eof()) {
    fileStream.getline(currentregel,255);
    if(currentregel[0] == '#')
        continue;
    if(currentregel[0] == 'v' && currentregel[1] == ' ') {
        numverts++;
    } else if(currentregel[0] == 'f' && currentregel[1] == ' ') {
        numfaces++;
    }
}

CUSTOMVERTEX *objvertex = new CUSTOMVERTEX[numverts];
short *objface = new short[3*numfaces];

int curvert = 0;
int curface = 0;
std::ifstream fileStream2("box.obj",std::ifstream::in);
while(!fileStream2.eof()) {
    fileStream2.getline(currentregel,255);
    std::stringstream ss;
    ss << currentregel;
    if(currentregel[0] == '#')
        continue;
    if(currentregel[0] == 'v' && currentregel[1] == ' ') {
        ss >> str >> v1 >> v2 >> v3;
        objvertex[curvert].x = v1;
        objvertex[curvert].y = v2;
        objvertex[curvert].z = v3;
        objvertex[curvert].NORMAL.x = 1.0f; // van later zorg,
        objvertex[curvert].NORMAL.y = 1.0f; // maar zo wijzen te tenminste 
        objvertex[curvert].NORMAL.z = 1.0f; // naar de camera
        curvert++;
    } else if(currentregel[0] == 'f' && currentregel[1] == ' ') {
        ss >> str >> i1 >> i2 >> i3;
        objface[curface+0] = i1;
        objface[curface+1] = i2;
        objface[curface+2] = i3;
        curface+=3;
    }
}

// Debugprut
cout << numverts << " vertices:\n";
for(int a = 0;a<numverts;a++) {
    cout << objvertex[a].x << " " << objvertex[a].y << " " << objvertex[a].z << "\n";
}
cout << numfaces << " faces:\n";
for(int a = 0;a<3*numfaces;a+=3) {
    cout << objface[a] << " " << objface[a+1] << " " << objface[a+2] << "\n";
}

Dit stukje code moet een OBJ-bestand, tot nu toe alleen met triangles en vertices met deze FVF:

C++:

#define CUSTOMFVF (D3DFVF_XYZ|D3DFVF_NORMAL)

... importeren. En dat doet 'ie perfect:


Maar het probleem is dat er volkomen niets op het scherm komt als ik hem in de buffer laad:

C++:

VOID* pVoid;
d3ddev->CreateVertexBuffer(sizeof(objvertex)*sizeof(CUSTOMVERTEX),0,CUSTOMFVF,D3DPOOL_MANAGED,&v_buffer,NULL);
v_buffer->Lock(0, 0, (void**)&pVoid, 0);
memcpy(pVoid, objvertex, sizeof(objvertex));
v_buffer->Unlock();

d3ddev->CreateIndexBuffer(sizeof(objface)*sizeof(short),0,D3DFMT_INDEX16,D3DPOOL_MANAGED,&i_buffer,NULL);
i_buffer->Lock(0, 0, (void**)&pVoid, 0);
memcpy(pVoid, objface, sizeof(objface));
i_buffer->Unlock();

... en zo vanuit de Scene teken:

C++:

d3ddev->SetStreamSource(0, v_buffer, 0, sizeof(CUSTOMVERTEX));
d3ddev->SetIndices(i_buffer);
d3ddev->DrawIndexedPrimitive(D3DPT_TRIANGLELIST, 0, 0, numverts, 0, numfaces);

Wel met meesterlijke framerate trouwens, dus er is gewoon niets (home-made tellertje FTW):


Maar ik heb dus geen flauw idee wat ik verkeerd doe. Misschien heeft er iemand een idee?

[ Voor 7% gewijzigd door Orwell op 14-09-2010 19:30 ]

[Killemov]

Heb je er al wel aan gedacht om een lichtbron te gebruiken?

[Orwell]

Killemov schreef op zondag 12 september 2010 @ 14:34:
Heb je er al wel aan gedacht om een lichtbron te gebruiken?

Jazeker, drie stuks zelfs. Hier is een plaatje van een model met statische buffers als voorbeeld:


Dat is gedaan met dit:

C++:

CUSTOMVERTEX vertices[] = {
    { -3.0f, -3.0f, 3.0f, 0.0f, 0.0f, 1.0f, },  // side 1
    { 3.0f, -3.0f, 3.0f, 0.0f, 0.0f, 1.0f, },
    { -3.0f, 3.0f, 3.0f, 0.0f, 0.0f, 1.0f, },
    { 3.0f, 3.0f, 3.0f, 0.0f, 0.0f, 1.0f, },

    { -3.0f, -3.0f, -3.0f, 0.0f, 0.0f, -1.0f, },    // side 2
    { -3.0f, 3.0f, -3.0f, 0.0f, 0.0f, -1.0f, },
    { 3.0f, -3.0f, -3.0f, 0.0f, 0.0f, -1.0f, },
    { 3.0f, 3.0f, -3.0f, 0.0f, 0.0f, -1.0f, },

    { -3.0f, 3.0f, -3.0f, 0.0f, 1.0f, 0.0f, },  // side 3
    { -3.0f, 3.0f, 3.0f, 0.0f, 1.0f, 0.0f, },
    { 3.0f, 3.0f, -3.0f, 0.0f, 1.0f, 0.0f, },
    { 3.0f, 3.0f, 3.0f, 0.0f, 1.0f, 0.0f, },

    { -3.0f, -3.0f, -3.0f, 0.0f, -1.0f, 0.0f, },    // side 4
    { 3.0f, -3.0f, -3.0f, 0.0f, -1.0f, 0.0f, },
    { -3.0f, -3.0f, 3.0f, 0.0f, -1.0f, 0.0f, },
    { 3.0f, -3.0f, 3.0f, 0.0f, -1.0f, 0.0f, },

    { 3.0f, -3.0f, -3.0f, 1.0f, 0.0f, 0.0f, },  // side 5
    { 3.0f, 3.0f, -3.0f, 1.0f, 0.0f, 0.0f, },
    { 3.0f, -3.0f, 3.0f, 1.0f, 0.0f, 0.0f, },
    { 3.0f, 3.0f, 3.0f, 1.0f, 0.0f, 0.0f, },

    { -3.0f, -3.0f, -3.0f, -1.0f, 0.0f, 0.0f, },    // side 6
    { -3.0f, -3.0f, 3.0f, -1.0f, 0.0f, 0.0f, },
    { -3.0f, 3.0f, -3.0f, -1.0f, 0.0f, 0.0f, },
    { -3.0f, 3.0f, 3.0f, -1.0f, 0.0f, 0.0f, },
};

short indices[] = {
    0, 1, 2,    // side 1
    2, 1, 3,
    4, 5, 6,    // side 2
    6, 5, 7,
    8, 9, 10,   // side 3
    10, 9, 11,
    12, 13, 14, // side 4
    14, 13, 15,
    16, 17, 18, // side 5
    18, 17, 19,
    20, 21, 22, // side 6
    22, 21, 23,
};
        
VOID* pVoid;
        
d3ddev->CreateVertexBuffer(sizeof(vertices)*sizeof(CUSTOMVERTEX),0,CUSTOMFVF,D3DPOOL_MANAGED,&v_buffer,NULL);
v_buffer->Lock(0, 0, (void**)&pVoid, 0);
memcpy(pVoid, vertices, sizeof(vertices));
v_buffer->Unlock();

d3ddev->CreateIndexBuffer(sizeof(indices)*sizeof(short),0,D3DFMT_INDEX16,D3DPOOL_MANAGED,&i_buffer,NULL);
i_buffer->Lock(0, 0, (void**)&pVoid, 0);
memcpy(pVoid, indices, sizeof(indices));
i_buffer->Unlock();

Edit: Heb daarna gewoon zelf maar een OBJ-bestand in elkaar geflansd, met als inhoud twee zijden van de doos die statisch ingevoerd wordt. Dan is het model tenminste correct. Uitkomst:


Prut dus. Dit houdt in dan het denkwerk van het importeren ergens scheefloopt. Iemand een idee?

Edit: Wat debugpogingen later:


Dit is de readactie van de OBJ met het kopietje erin. Output met het 'Debugprut'-stukje uit codelap uit startpost. Hij leest die bestanden toch echt goed! Er gaat dus wat anders verkeerd. Maar wat?

[ Voor 21% gewijzigd door Orwell op 14-09-2010 19:30 ]

[.oisyn]

Wat denk jij dat sizeof(objvertex) en sizeof(objface) doen? Ik zal je alvast een hint geven: het resultaat is altijd 4 op een 32 bits platform.

Overigens, ook al deed het wat je verwachtte dan klopt je code alsnog niet, want bij het aanmaken van de vertexbuffer doe je sizeof(objvertex) * sizeof(CUSTOMVERTEX), maar bij de memcpy() doe je die vermenigvuldiging niet (en gebruik je enkel sizeof(objvertex)).

[ Voor 55% gewijzigd door .oisyn op 12-09-2010 22:50 ]

[Orwell]

.oisyn schreef op zondag 12 september 2010 @ 22:48:
Wat denk jij dat sizeof(objvertex) en sizeof(objface) doen? Ik zal je alvast een hint geven: het resultaat is altijd 4 op een 32 bits platform.

Overigens, ook al deed het wat je verwachtte dan klopt je code alsnog niet, want bij het aanmaken van de vertexbuffer doe je sizeof(objvertex) * sizeof(CUSTOMVERTEX), maar bij de memcpy() doe je die vermenigvuldiging niet (en gebruik je enkel sizeof(objvertex)).

Die returnen de grootte van de variabele waar die pointer naar verwijst. Dus een 4byte-integer? Nee, als dat zo is snap ik het niet meer.

Elke CUSTOMVERTEX heeft een rijtje van 6 floats, dus 32 bytes. Oftewel, sizeof(CUSTOMVERTEX) returnt 32. Dat vermenigvuldigen met het aantal vertices en klaar is kees. Klopt he?

C++:

struct CUSTOMVERTEX {
    float x,y,z;
    D3DVECTOR NORMAL; // Gewoon drie floats, voor x-, y- en z-afstand van vector
};

Dan de indices. Daar vermenigvuldigen we de grootte van een korte int (2 bytes) met het aantal faces. Dan doen we dat vermenigvuldigen met drie, want drie shorts zijn een face? Ook weer klaar is kees.

Dan memcpy. Daar vullen we simpelweg sizeof(objface) of sizeof(objvertex) in.

Rolt daar uit:

C++:

VOID* pVoid;
        
d3ddev->CreateVertexBuffer(numverts*sizeof(CUSTOMVERTEX),0,CUSTOMFVF,D3DPOOL_MANAGED,&v_buffer,NULL);
v_buffer->Lock(0, 0, (void**)&pVoid, 0);
memcpy(pVoid, objvertex, sizeof(objvertex));
v_buffer->Unlock();

d3ddev->CreateIndexBuffer((numfaces*3)*sizeof(short),0,D3DFMT_INDEX16,D3DPOOL_MANAGED,&i_buffer,NULL);
i_buffer->Lock(0, 0, (void**)&pVoid, 0);
memcpy(pVoid, objface, sizeof(objface));
i_buffer->Unlock();

En in de scène:

C++:

// Buffers selecteren
d3ddev->SetStreamSource(0, v_buffer, 0, sizeof(CUSTOMVERTEX));
d3ddev->SetIndices(i_buffer);

// Tekenen inclusief translate
d3ddev->DrawIndexedPrimitive(D3DPT_TRIANGLELIST, 0, 0, numverts, 0, numfaces*3);

En dan doet 'ie het nog niet.

Maar we komen in de buurt.

[.oisyn]

Orwell schreef op maandag 13 september 2010 @ 14:55:
[...]


Die returnen de grootte van de variabele waar die pointer naar verwijst. Dus een 4byte-integer? Nee, als dat zo is snap ik het niet meer.

Nee, ze returnen de grootte van het type van de variabele. Wat is de variabele? Een pointer. Dus 4 bytes. Als je wilt weten wat de grootte is waar hij naartoe point, dan moet je 'm eerst referencen. Je maakt vervolgens de fout dat ie de totale grootte van de array teruggeeft, wat niet het geval is. De compiler kan aan de pointer niet zien dat hij naar het eerste element van een array wijst, en je kunt niet eens at runtime achterhalen hoe groot die array is als hij daadwerkelijk naar een array wijst. Een sizeof(*objvertex) returnt dan ook hetzelfde als sizeof(CUSTOMVERTEX), want *objvertex is van het type CUSTOMVERTEX.

De reden waarom het bij je hardcoded kubus voorbeeld wél werkt, is omdat objvertex en objface dan geen pointers meer zijn, maar daadwerkelijke arrays. Het type van objvertex is dan CUSTOMVERTEX[12], dus sizeof(objvertex) geeft dan hetzelfde als sizeof(CUSTOMVERTEX[12]), oftewel 12 * sizeof(CUSTOMVERTEX)

Elke CUSTOMVERTEX heeft een rijtje van 6 floats, dus 32 bytes. Oftewel, sizeof(CUSTOMVERTEX) returnt 32. Dat vermenigvuldigen met het aantal vertices en klaar is kees. Klopt he?

Klopt. Nou ja, 6 * 4 is bij mij nog altijd 24, maar dat terzijde

Dan memcpy. Daar vullen we simpelweg sizeof(objface) of sizeof(objvertex) in.

Waarom dan? Memcpy wil ook het aantal bytes, net als de eerste parameter naar CreateVertexBuffer(). Hoe kom je er dan in hemelsnaam bij dat je bij de een wel juist numverts*sizeof(CUSTOMVERTEX) specificeert, maar bij de ander een totaal andere waarde? Die twee dingen moeten hetzelfde zijn.

[ Voor 9% gewijzigd door .oisyn op 13-09-2010 16:43 ]

[NC83]

Face data in een OBJ file bestaat niet altijd uit 3 indexen het kan ook uit quads zijn opgebouwt en dan krijg je 4 indecis per regel in een OBJ file.Of zelfs minder "f 5722//4074 5741//4090 5742//4091 "

[Orwell]

NC83 schreef op maandag 13 september 2010 @ 20:50:
Face data in een OBJ file bestaat niet altijd uit 3 indexen het kan ook uit quads zijn opgebouwt en dan krijg je 4 indecis per regel in een OBJ file.Of zelfs minder "f 5722//4074 5741//4090 5742//4091 "

Je kunt het ook zelfs treffen dat je er drie tegenkomt per hoekpunt, om ze even op te noemen: vertexindex, vertexnormaal en textuurcoördinaat van die vertex. Kom je misschien zelfs twaalf getallen tegen per regel. Dat weet ik dus alemaal wel, maar laten we het eerst even op de simpele manier tenminste aan het werk krijgen. Lijkt me verstandiger.

.oisyn schreef op maandag 13 september 2010 @ 16:29:
[...]

Nee, ze returnen de grootte van het type van de variabele. Wat is de variabele? Een pointer. Dus 4 bytes. Als je wilt weten wat de grootte is waar hij naartoe point, dan moet je 'm eerst referencen. Je maakt vervolgens de fout dat ie de totale grootte van de array teruggeeft, wat niet het geval is. De compiler kan aan de pointer niet zien dat hij naar het eerste element van een array wijst, en je kunt niet eens at runtime achterhalen hoe groot die array is als hij daadwerkelijk naar een array wijst. Een sizeof(*objvertex) returnt dan ook hetzelfde als sizeof(CUSTOMVERTEX), want *objvertex is van het type CUSTOMVERTEX.

De reden waarom het bij je hardcoded kubus voorbeeld wél werkt, is omdat objvertex en objface dan geen pointers meer zijn, maar daadwerkelijke arrays. Het type van objvertex is dan CUSTOMVERTEX\[12], dus sizeof(objvertex) geeft dan hetzelfde als sizeof(CUSTOMVERTEX\[12]), oftewel 12 * sizeof(CUSTOMVERTEX)

Wat is het toch leuk om op Tweakers.net te lessen.

Tsja, inderdaad, tijdens runtime is een array inderdaad niet echt te onderscheiden van al die andere geheugenadressen. Maar goed, ik moet dus met een soort van omweg achter de vermoedelijke grootte van die array komen, oftewel 6 floats maal het aantal vertices? 'Simpel' gezegd:

sizeof(pointer) returnt de grootte van het type variabele waar die pointer naar verwijst, en niet de hele array!

Klopt. Nou ja, 6 * 4 is bij mij nog altijd 24, maar dat terzijde

Lol. Je zat er zelf ook naast.

*Orwell verwerkt het allemaal*

C++:

int numverts,numfaces = 0;
char str;
char currentregel[256];
int i1,i2,i3 = 0;
float v1,v2,v3 = 0;
std::ifstream fileStream("teapot.obj",std::ifstream::in);
while(!fileStream.eof()) {
    fileStream.getline(currentregel,255);
    if(currentregel[0] == '#')
        continue;
    if(currentregel[0] == 'v' && currentregel[1] == ' ') {
        numverts++;
    } else if(currentregel[0] == 'f' && currentregel[1] == ' ') {
        numfaces++;
    }
}

CUSTOMVERTEX *objvertex = new CUSTOMVERTEX[numverts];
short *objface = new short[3*numfaces];

int curvert = 0;
int curface = 0;
std::ifstream fileStream2("teapot.obj",std::ifstream::in);
while(!fileStream2.eof()) {
    fileStream2.getline(currentregel,255);
    std::stringstream ss;
    ss << currentregel;
    if(currentregel[0] == '#')
        continue;
    if(currentregel[0] == 'v' && currentregel[1] == ' ') {
        ss >> str >> v1 >> v2 >> v3;
        objvertex[curvert].x = v1;
        objvertex[curvert].y = v2;
        objvertex[curvert].z = v3;
        objvertex[curvert].NORMAL.x = 0.0f;
        objvertex[curvert].NORMAL.y = 1.0f;
        objvertex[curvert].NORMAL.z = 0.0f;
        curvert++;
    } else if(currentregel[0] == 'f' && currentregel[1] == ' ') {
        ss >> str >> i1 >> i2 >> i3;
        objface[curface+0] = i1;
        objface[curface+1] = i2;
        objface[curface+2] = i3;
        curface+=3;
    }
}

VOID* pVoid;
        
d3ddev->CreateVertexBuffer(numverts*sizeof(CUSTOMVERTEX),0,CUSTOMFVF,D3DPOOL_MANAGED,&v_buffer,NULL);
v_buffer->Lock(0, 0, (void**)&pVoid, 0);
memcpy(pVoid, objvertex, numverts*sizeof(CUSTOMVERTEX));
v_buffer->Unlock();

d3ddev->CreateIndexBuffer((numfaces*3)*sizeof(short),0,D3DFMT_INDEX16,D3DPOOL_MANAGED,&i_buffer,NULL);
i_buffer->Lock(0, 0, (void**)&pVoid, 0);
memcpy(pVoid, objface, (numfaces*3)*sizeof(short));
i_buffer->Unlock();

In de scène:

C++:

d3ddev->DrawIndexedPrimitive(D3DPT_TRIANGLELIST, 0, 0, numverts, 0, numfaces);

En dan doet 'ie nog steeds niks.

Verder heb ik nog wat andere vraagjes:

• Kan ik niet gewoon in HLSL-style de items uit een struct achter elkaar plakken, zoals dit:
  
  
  HLSL:
  

  vs_output.vposition.xyz = float3(1.0f,1.0f,1.0f); // vertexpositie binnen de vertexshader :)

• En waarom geeft dit stukje code eigenlijk een met rommel gevulde 'var1' op:
  
  C++:
  

  int var1,var2 = 0;

Zo, dat was het wel weer zo'n beetje. Echt om gek van te worden.

[ Voor 3% gewijzigd door Orwell op 14-09-2010 19:32 ]

[CodeCaster]

Orwell schreef op maandag 13 september 2010 @ 22:05:
En waarom geeft dit stukje code eigenlijk een met rommel gevulde 'var1' op:

C++:

int var1,var2 = 0;

Omdat je zo var1 wel declareert, maar niet initialiseert.

[NC83]

Heb je al eens je D3D runtime op debug gezet en de warning en error schuif naar een onder het maximum gezet. Dan weet je tenminste zeker dat het niet aan D3D ligt.

Welke FVF of VertexDeclartie stel je in alvorens die call naar DrawIndexPritive, want die call heb ik nog niet gezien en als die call niet over een komt met de stream source dan kan er ofwell niks worden getekent ofwel garbage.

Ik mis dus dit:

C++:

d3ddev->SetFVF(CUSTOMFVF);
||
//VertexDecl elders gecreeerd
d3ddev->SetVertexDeclaration(VertexDecl);

Orwell schreef op maandag 13 september 2010 @ 22:05:

Verder heb ik nog wat andere vraagjes:

• Kan ik niet gewoon in HLSL-style de items uit een struct achter elkaar plakken, zoals dit:
  
  
  HLSL:
  

  vs_output.vposition.xyz = float3(1.0f,1.0f,1.0f); // vertexpositie binnen de vertexshader :)

Die HLSL code zou moeten werken, mits vs_output een float3 vposition declareerd uiteraard, en je vertex op 1,1,1 in neer moeten zetten, let erop dat dit de geprojecteerde wereld is als dit als hoofd position naar buiten komt.

[ Voor 51% gewijzigd door NC83 op 14-09-2010 02:23 ]

[Orwell]

CodeCaster schreef op maandag 13 september 2010 @ 22:09:
[...]

Omdat je zo var1 wel declareert, maar niet initialiseert.

Oh! Dat scheelt weer een hoop. Heb eventjes een fix doorgevoerd op sommige plekken:

C++:

int numverts = 0; (global in een header)
int numfaces = 0;
// En dus niet 'int numverts,numfaces = 0'
// Al had ' int numverts = numfaces = 0'  ook gekund

Met wat home-made debuggen later:

C++:

sprintf(tmp,"%d",numverts*sizeof(CUSTOMVERTEX));
SendMessage(hwnd,WM_SETTEXT,0,(LPARAM)tmp);

Leverde dat op:


Wat dus bullshit is (dit zou inhouden dat er 651176880 / 24 = 27132370 vertices zouden zijn) maar levert nu op:


Dat ziet er gelijk veel gezonder uit. Klopt nog ook: (138 vertices maal 24 bytes per vertex = 3312!)

Zo, alweer een fout gevonden! Al twee gehad! We hebben een render! Al kan ik dat niet tonen, ik mag hier op school op sommige PC's geen eigengemaakte executables openen. Wat dus zuigt.

Maar hij rendert een beetje, eh, gebroken. Maar mijn boredomtijd is op in dit lesje informatica, dus ja, ik ben weer effies weg.

Heb je al eens je D3D runtime op debug gezet en de warning en error schuif naar een onder het maximum gezet. Dan weet je tenminste zeker dat het niet aan D3D ligt.

Ik heb geen idee waar je het over hebt, maar ik zal het eens Googlen ofzo.

Welke FVF of VertexDeclartie stel je in alvorens die call naar DrawIndexPritive, want die call heb ik nog niet gezien en als die call niet over een komt met de stream source dan kan er ofwell niks worden getekent ofwel garbage.

Ik heb gewoon SetFVF() gebruikt om de grootte van de vertexdata wat bij te zagen, en verder heb ik niets anders uitgespookt daarmee. Houdt dus in:

C++:

// In de header
#define CUSTOMFVF (D3DFVF_XYZ|D3DFVF_NORMAL) // Scheelt een berg bytes per vertex

// En dan aanzetten als de device gemaakt is
device->SetFVF(CUSTOMFVF);

Die HLSL code zou moeten werken, mits vs_output een float3 vposition declareerd uiteraard, en je vertex op 1,1,1 in neer moeten zetten, let erop dat dit de geprojecteerde wereld is als dit als hoofd position naar buiten komt.

Ik weet, was zomaar een pluk uit een vertexshader, met de objectpositie van de te verwerken vertex. Maar dat was dus een volledig random voorbeeld van dat structitemsplakken, maar dat gaat dus niet werken met de floats zelf. Wel met D3DVECTOR. Mooi zo.

[ Voor 84% gewijzigd door Orwell op 14-09-2010 10:32 ]

[.oisyn]

Orwell schreef op dinsdag 14 september 2010 @ 08:47:
[...]


Oh! Dat scheelt weer een hoop. Heb eventjes een fix doorgevoerd op sommige plekken:

C++:

int numverts = 0; (global in een header)

Variabeldefinities zet je niet in een header, alleen de declaraties

Dus:

C++:

// in bladiebla.h
extern int numverts;

// in bladiebla.cpp
int numverts = 0;

[Orwell]

.oisyn schreef op dinsdag 14 september 2010 @ 11:34:
[...]

Variabeldefinities zet je niet in een header, alleen de declaraties

Dus:

C++:

// in bladiebla.h
extern int numverts;

// in bladiebla.cpp
int numverts = 0;

Oh, ik maak van headers altijd variabeledumpen. Dus af en toe met opstartinstellingen, zoals booleans die van alles en nog wat regelen. Maar goed, hij rendert niet helemaal:


Zoals al eerder werd verwacht is het het inladen van de data dat voor de problemen zorgt. Heb net simpelweg met dit:

C++:

sprintf(tmp,"%f",v1); // v1 of v2 of v3
SendMessage(hwnd,WM_SETTEXT,0,(LPARAM)tmp);
Sleep(1000);

... alle vertices gecontroleerd tijdens OBJ scannen. Werkte perfect! Alles klopte. Ben nu wel benieuwd naar wat 'ie returnt als ik het tijdens het framemaken doe.

Er gaat toch echt iets structureel fout (hier met een 5x5-plane):

[ Voor 33% gewijzigd door Orwell op 14-09-2010 17:43 ]

[NC83]

D3D runtime op debug zetten kan in de DirectX properties window dat te vinden is onder start->DX folder->DirectX Utilities->DirectX properties

Een FVF moet normaal voor iedere draw call worden gezet als je vertex formaat verandert, ik geloof niet dat dat in dit geval gebeurt maar voor de toekomst dan maar.

[Orwell]

NC83 schreef op dinsdag 14 september 2010 @ 19:33:
D3D runtime op debug zetten kan in de DirectX properties window dat te vinden is onder start->DX folder->DirectX Utilities->DirectX properties

Een FVF moet normaal voor iedere draw call worden gezet als je vertex formaat verandert, ik geloof niet dat dat in dit geval gebeurt maar voor de toekomst dan maar.

Ik heb hem eens volledig op 'More' gezet. Maar ik ga nu eerst maar eens naar m'n nest toe denk ik zomaar.

Verder moet ik je er even op wijzen dat hij tegenwoordig (met je June 2010 SDK dan in ieder geval) hier staat:

sdkdir\Utilities\bin\x86\dxcpl.exe

Weet je/u dat ook weer.

En je bedoelt dat ik FVF bij elke frame moet setten? Dat zeiden ze bij de tutorials ook al, maar ik had meer zin in wat extra frames dan dat 'zinloze' gedoe elke frame. Dat is dus daarvoor. Maar goed, ik kan nog steeds niet vatten waarom de boel niet werkt. En het debuggen levert niets op, behalve dat er vermeld wordt dat ik tijdelijke adressen voor mijn transformmatrixen gebruik, maar dat is oud nieuws.

[.oisyn]

Wat ik raar vind is dat je hardcoded kubus wel werkt, maar de kubus in een OBJ file dus blijkbaar niet. Dit doet me vermoeden dat je toch nog ergens wat fout doet met sizeof oid.

NC83 schreef op dinsdag 14 september 2010 @ 19:33:
Een FVF moet normaal voor iedere draw call worden gezet als je vertex formaat verandert, ik geloof niet dat dat in dit geval gebeurt maar voor de toekomst dan maar.

Zoals je zelf al zegt, dat doe je gewoon als je een nieuw formaat in wil stellen. Zeker niet voor iedere draw. En @ Orwell, elke frame instellen kan echt geen kwaad, hoor. Je wint er geen drol mee door het niet te doel

[Orwell]

.oisyn schreef op dinsdag 14 september 2010 @ 23:12:
Wat ik raar vind is dat je hardcoded kubus wel werkt, maar de kubus in een OBJ file dus blijkbaar niet. Dit doet me vermoeden dat je toch nog ergens wat fout doet met sizeof oid.

Ja, maar wat. Ik heb mezelf dus al het rambam gedebugd, maar heb nog steeds niets vaags gevonden.

Al zit ik er wel aan te denken dat dit een mega-facedesk wordt als het probleem gevonden wordt. Ik verwacht één of andere lamme RenderState waarvan de bool omgedraaid moet worden. Of andere lamme dingen van die soort.

Zoals je zelf al zegt, dat doe je gewoon als je een nieuw formaat in wil stellen. Zeker niet voor iedere draw. En @ Orwell, elke frame instellen kan echt geen kwaad, hoor. Je wint er geen drol mee door het niet te doel

Nouw, goed, valt te proberen. Laat ik nog eens een screen maken, misschien dat iemand het bekend voor komt.


Het lijkt alsof sommige vertices een stel corrupte coördinaten hebben, maar als ik een frame verder spring, is die corruptie weer weg. Echt om gek van te worden. Al blijft de corruptie die binnen de viewport zit en blijft wel altijd aanwezig.

[.oisyn]

Oh, ik zie het al. Je moet de docs voor DrawIndexedPrimitives() nog even goed doorlezen, want je laatste parameter klopt niet

[Orwell]

.oisyn schreef op woensdag 15 september 2010 @ 14:21:
Oh, ik zie het al. Je moet de docs voor DrawIndexedPrimitives() nog even goed doorlezen, want je laatste parameter klopt niet

Je bedoelt:

C++:

d3ddev->DrawIndexedPrimitive(D3DPT_TRIANGLELIST, 0, 0, numverts, 0, numfaces*3);

...? Ja, die had ik al veranderd naar dit (zonder *3):

C++:

if(useobj) { // Dynamisch gedoe
    d3ddev->DrawIndexedPrimitive(D3DPT_TRIANGLELIST, 0, 0, numverts, 0, numfaces); 
} else { // Hardcoded support
    d3ddev->DrawIndexedPrimitive(D3DPT_TRIANGLELIST, 0, 0, 24, 0, 12);
}

En dat in al die debugtijd van deze draad, al ben ik het vergeten te vermelden. Dit is trouwens wel de goede aanpak zoals verkondigd wordt op MSDN.

Verder schuift die parameter weinig als je over de limiet heen gaat, dan begint 'ie gewoon weer aan het begin van de array met faces tekenen.

Als je dit niet bedoelt, zeg het even (ben wel aan het kijken op MSDN at the moment).

Edit: Weer een symptoom op de gevoelige plaat gelegd (de onderkant van de pot):


Dat stel vertices heeft positie (0,0,0), wat best vaag is op zich. Moet erbij zeggen trouwens dat een paar van diezelfde vertices ook gare normalen hebben, want ze wijzen niet met de rest mee (grijze lijntjes!) naar een blauw licht op dit moment. En omdat normalen gewoon statisch ingevoerd worden, is er meer aan de hand.

[ Voor 19% gewijzigd door Orwell op 15-09-2010 16:20 ]

[.oisyn]

Dat was idd wat ik bedoelde.

[Orwell]

Overigens, sommige van die vertices op 0,0 horen gewoon op die plek, want op die plek zit een door Max getrianguleerde polygoon die het hele ondervlakje opvult. Maar het punt is dus dat die grijzes er niet thuishoren, en dat verder niet de goeie lines naar het onderste puntjes gaan.

Simpel gezegd is het hele ondervlak verdwenen in de corrupte coördinaten.

[Orwell]

Aha, er is een mogelijke dader gevonden. Lang leve debuggen!


Stringstream zit onwaarheden te verkondigen! Die moet aangepakt worden. Alleen is nog niet bepaald duidelijk waarom 'ie nu de fout in gaat, maar dat komt nog wel.

Je ziet hier trouwens links het originele OBJ-bestand en rechts de gegevens die eerst zijn uitgelezen en daarna weer naar een bestand geschreven zijn.

[ Voor 22% gewijzigd door Orwell op 16-09-2010 22:05 ]

[.oisyn]

Kun je je code eens posten? Want met de code uit de topicstart zou je niet eens die waarden eruit moeten krijgen (ik vermoed dat je code hebt toegevoegd om de //<int> te negeren)

[Orwell]

.oisyn schreef op donderdag 16 september 2010 @ 22:12:
Kun je je code eens posten? Want met de code uit de topicstart zou je niet eens die waarden eruit moeten krijgen (ik vermoed dat je code hebt toegevoegd om de //<int> te negeren)

D'r is inderdaad een aardig hoopje veranderd, onder andere dus inderdaad doordat normalen en texturecoördinaten nu wel geladen worden. Of beter: opgevangen worden. Maar goed. Die 'int achter de streepjes' wordt nu wel degelijk meegenomen (zie al die andere regels in dat outputje). Laat ik nog wat duidelijker maken: die ints horen niet thuis in de face, ze geven alleen aan welke normaal bij welke vertex past. Dus mochten ze van mij ophoepelen.

Verder over die code: ik houd dus niet echt van van dat lappen zooi posten, maar dan toch voor de volledigheid hier de code:

C++:

// Variabeles die hier *niet* gedeclareerd of geïnitialiseerd zijn staan in een header
std::ifstream fileStream(objpath,std::ifstream::in);
while(!fileStream.eof()) {
    fileStream.getline(currentregel,127);
    if(currentregel[0] == '#' || currentregel[0] == ' ')
        continue;
    if(currentregel[0] == 'v' && currentregel[1] == ' ')
        numverts++;
    if(currentregel[0] == 'v' && currentregel[1] == 'n')
        numnormals++;
    if(currentregel[0] == 'v' && currentregel[1] == 't')
        numtextures++;
    if(currentregel[0] == 'f' && currentregel[1] == ' ')
        numfaces++;
}

CUSTOMVERTEX *objvertex = new CUSTOMVERTEX[numverts];
ZeroMemory(objvertex,numverts*sizeof(CUSTOMVERTEX)); // Dit fixt wat gare artefacten

CUSTOMVERTEX *objnormal = new CUSTOMVERTEX[numnormals];

short *objface = new short[3*numfaces];
ZeroMemory(objface,(3*numfaces)*sizeof(short)); // Idem

int i1,i2,i3,t1,t2,t3,n1,n2,n3 = 0; // De outputs voor stringstream
float v1,v2,v3 = 0; // Idem
std::ifstream fileStream2(objpath,std::ifstream::in);
while(!fileStream2.eof()) {
    fileStream2.getline(currentregel,127);
    if(currentregel[0] == '#' || currentregel[0] == ' ') // Heb dan schijt aan regel (t/m newline)
        continue;
    std::stringstream ss; // Inladen
    ss << currentregel;
    if(currentregel[0] == 'v' && currentregel[1] == ' ') { // Process vertices (dit gaat *perfect*)
        ss >> str >> v1 >> v2 >> v3;
        objvertex[curvert].x = v1;
        objvertex[curvert].y = v2;
        objvertex[curvert].z = v3;

        if(!numnormals)
            objvertex[curvert].NORMAL = D3DXVECTOR3(1.0f,1.0f,1.0f);
        if(v2 > maxheight)
            maxheight = v2;
        if(v2 < minheight)
            minheight = v2;

        // Camerastraal vergroten als vertex buiten die straal komt.
        double dist = sqrt(pow(sqrt(pow(v1,2)+pow(v3,2)),2)+pow(v2,2)); // Lol 
        if(dist > radius)
            radius = dist + 5.0f;

        curvert++;
    }
    if(currentregel[0] == 'v' && currentregel[1] == 'n' && numnormals > 0) { // Process normals (dit gaat *perfect*)
        ss >> str >> str >> v1 >> v2 >> v3;
        objnormal[curnormal].NORMAL = D3DXVECTOR3(v1,v2,v3);
        curnormal++;
    }
    if(currentregel[0] == 'f' && currentregel[1] == ' ') { // Process faces (dit gaat dus fout)
        for(int a = 0;a < 128;a++) { // Filter en vervang de slashes, 
            if(currentregel[a] == '/') { // dit omdat stringstream variabelen
                currentregel[a] = ' '; // in strings dan op die spaties onderscheidt
            }
        }
        std::stringstream ssface; // Gebruk even een andere (oplosprobeersel)
        ssface << currentregel;
        if(!numnormals && !numtextures) { // geen textures en geen normals
            ss >> str >> i1 >> i2 >> i3;
            objface[curface] = i1;
            objface[curface+1] = i2;
            objface[curface+2] = i3;
        }
        if(numnormals && !numtextures) { // Dit is goed te vatten
            ssface >> str >> i1 >> n1 >> i2 >> n2 >> i3 >> n3;
            objface[curface] = i1;
            objface[curface+1] = i2;
            objface[curface+2] = i3;

            objvertex[i1].NORMAL = objnormal[n1].NORMAL;
            objvertex[i2].NORMAL = objnormal[n2].NORMAL;
            objvertex[i3].NORMAL = objnormal[n3].NORMAL;
        }
        if(numnormals && numtextures) { // Same, maar nog onderontwikkeld
            ssface >> str >> i1 >> t1 >> n1 >> i2 >> t2 >> n2 >> i3 >> t3 >> n3;
            objface[curface] = i1;
            objface[curface+1] = i2;
            objface[curface+2] = i3;

            objvertex[i1].NORMAL = objnormal[n1].NORMAL;
            objvertex[i2].NORMAL = objnormal[n2].NORMAL;
            objvertex[i3].NORMAL = objnormal[n3].NORMAL;
        }
        curface+=3;
    }
}

Met als resultaat (werkende normalen ):


Edit: Heb het is een beetje aan zitten staren/gapen, maar die oplossing blijft in m'n bovenkamer erg afwezig.

[ Voor 3% gewijzigd door Orwell op 16-09-2010 22:44 ]

[.oisyn]

Je checkt ook niet echt op errors, maar ik zie zo snel niet waarom het niet klopt. Overigens probeer je nog altijd een hele zwik variabelen in een keer te initialiseren (zie regen 25 en 26), terwijl dat alleen maar de laatste variabele initialiseert. Daarnaast lijk je ook geen rekening te houden met het feit dat een vertex die wordt geshared tussen twee faces niet voor beide faces dezelfde vertex normal hoeft te hebben. Denk maar eens aan een kubus, elk hoekpunt wordt door 3 polygonen gedeeld, maar voor elk polygoon heeft het een unieke vertex normal (die gelijk is aan de normal van de polygoon zelf). In de vertex buffer moeten dat dan ook 3 afzonderlijke vertices worden, met gelijke positie maar verschillende normals.

[Orwell]

.oisyn schreef op donderdag 16 september 2010 @ 22:44:
Je checkt ook niet echt op errors, maar ik zie zo snel niet waarom het niet klopt. Overigens probeer je nog altijd een hele zwik variabelen in een keer te initialiseren (zie regen 25 en 26), terwijl dat alleen maar de laatste variabele initialiseert. Daarnaast lijk je ook geen rekening te houden met het feit dat een vertex die wordt geshared tussen twee faces niet voor beide faces dezelfde vertex normal hoeft te hebben. Denk maar eens aan een kubus, elk hoekpunt wordt door 3 polygonen gedeeld, maar voor elk polygoon heeft het een unieke vertex normal (die gelijk is aan de normal van de polygoon zelf). In de vertex buffer moeten dat dan ook 3 afzonderlijke vertices worden, met gelijke positie maar verschillende normals.

Het eerste punt over dat initialiseren: had 'k al eerder geprobeerd, geen effect helaas. Dit omdat die stringstream verplicht is om de variabelen te overschrijven (en als 'ie dat niet doet, zit er een fout in de code).

Over het volgende punt: je hebt daar inderdaad een punt. Maar ik weet nog niet hoe ik dat aan ga pakken, dus dat is van later zorg helaas. Op dit moment krijgt elke vertex gewoon de normal van de laatste triangle in de index. Verder nog een probleempje dat 3dsMax per doos bijvoorbeeld gewoon 8 vertices exporteert, maar wel al de normalen waar je het over hebt in het OBJ-bestand zet. Dat wordt klote.

[.oisyn]

Orwell schreef op donderdag 16 september 2010 @ 23:03:
Het eerste punt over dat initialiseren: had 'k al eerder geprobeerd, geen effect helaas. Dit omdat die stringstream verplicht is om de variabelen te overschrijven (en als 'ie dat niet doet, zit er een fout in de code).

Nou, nee. Als er geen geldige int in de stream staat, dan overschrijft ie niets.

[Orwell]

.oisyn schreef op vrijdag 17 september 2010 @ 00:36:
[...]

Nou, nee. Als er geen geldige int in de stream staat, dan overschrijft ie niets.

Nou, ja, want als het niet het geval is, is het een verkeerd geëxporteerd OBJ-bestand.

En uiteraard heb ik die variabeles nu gewoon onder elkaar staan, zodat de hele boel uitgenuld is.

*Orwell gaat vanmiddag naar het foutgooien van stringstream kijken*

Edit: Dat levert dus ook weer geen drol op, fail() uit de stringstreamclass wordt nooit op true gezet. Hij doet het dus gewoon 'goed'. Denkt 'ie. Dit idee heb 'k geprobeerd trouwens:

C++:

/* Rommelen met stringstreamen en die variabeles */
if(ss.fail()) {
    MessageBox(hwnd,"FAIL","FAIL",0);
    break;
}

De oorzaak gevonden! Dit stukje zorgt vaag genoeg voor de problemen:

C++:

objvertex[i1].NORMAL = objnormal[n1].NORMAL; 
objvertex[i2].NORMAL = objnormal[n2].NORMAL; 
objvertex[i3].NORMAL = objnormal[n3].NORMAL; 

Als ik dat dus wegcomment wordt de data wel gewoon goed opgeslagen. Übervaag als je 't mij vraagt.

[ Voor 43% gewijzigd door Orwell op 17-09-2010 16:14 ]

[NC83]

Kijk eens naar de data in objnormal array en kijk dan ook naar de VERTEX en NORMAL fields. Daarnaast zero je de objevertex array volledig en het objnormal array niet, daarnaast verspil je behoorlijk veel geheugen door je normal in een CUSTOMVERTEX array op te slaan.

[Orwell]

NC83 schreef op vrijdag 17 september 2010 @ 16:28:
Kijk eens naar de data in objnormal array en kijk dan ook naar de VERTEX en NORMAL fields.

Check. Ziet er best wel perfect gezond uit.

Daarnaast zero je de objevertex array volledig en het objnormal array niet

Dat was dus omdat die normalen er perfect uitzagen, maar het is altijd handig natuurlijk. Dus check vanaf nu.

daarnaast verspil je behoorlijk veel geheugen door je normal in een CUSTOMVERTEX array op te slaan.

Die verspilling is verholpen, nu gebruik ik dus dit:

C++:

struct NORMALS {
    D3DVECTOR NORMAL;
};

Scheelt weer een whopping 193KiB, maar vooral flink rekentijd.

Verder blijft de fout wel bestaan als de normalen verwerkt worden. Helaas.

[ Voor 4% gewijzigd door Orwell op 17-09-2010 17:03 ]

[Orwell]

C++:

/* stel variabelen in voor import */
curvert = 0;
// moest zijn
curvert = 1;

En nu rendert 'ie perfect.