Is generating normals for this impossible...?

This topic is 5470 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

D3DXVECTOR3 CTerrain::GetTriangleNormal(D3DXVECTOR3* vVertex1,
D3DXVECTOR3* vVertex2, D3DXVECTOR3* vVertex3)
{
D3DXVECTOR3 vNormal;
D3DXVECTOR3 v1;
D3DXVECTOR3 v2;

D3DXVec3Subtract(&v1, vVertex2, vVertex1);
D3DXVec3Subtract(&v2, vVertex3, vVertex1);

D3DXVec3Cross(&vNormal, &v1, &v2);

D3DXVec3Normalize(&vNormal, &vNormal);

return vNormal;
}

for(i = 0; i < m_dwNumOfIndices; i=i+3)
{

dwVertex1 = pBufferIndices;
dwVertex2 = pBufferIndices[i + 1];
dwVertex3 = pBufferIndices[i + 2];

vNormal = GetTriangleNormal(&D3DXVECTOR3(pcvVertices[dwVertex1].x, pcvVertices[dwVertex1].y,
pcvVertices[dwVertex1].z),
&D3DXVECTOR3(pcvVertices[dwVertex2].x,
pcvVertices[dwVertex2].y,
pcvVertices[dwVertex2].z),
&D3DXVECTOR3(pcvVertices[dwVertex3].x,
pcvVertices[dwVertex3].y,
pcvVertices[dwVertex3].z));

pNumOfSharedPolygons[dwVertex1]++;
pNumOfSharedPolygons[dwVertex2]++;
pNumOfSharedPolygons[dwVertex3]++;

pSumVertexNormal[dwVertex1].x += vNormal.x;
pSumVertexNormal[dwVertex1].y += vNormal.y;
pSumVertexNormal[dwVertex1].z += vNormal.z;

pSumVertexNormal[dwVertex2].x += vNormal.x;
pSumVertexNormal[dwVertex2].y += vNormal.y;
pSumVertexNormal[dwVertex2].z += vNormal.z;

pSumVertexNormal[dwVertex3].x += vNormal.x;
pSumVertexNormal[dwVertex3].y += vNormal.y;
pSumVertexNormal[dwVertex3].z += vNormal.z;
}

//Unlock the index buffer
m_pIndexBuffer->Unlock();

for(i = 0; i < m_dwNumOfVertices; i++)
{
vNormal.x = (float)pSumVertexNormal.x / pNumOfSharedPolygons;
vNormal.y = (float)pSumVertexNormal.y / pNumOfSharedPolygons;
vNormal.z = (float)pSumVertexNormal.z / pNumOfSharedPolygons;

D3DXVec3Normalize(&vNormal, &vNormal);

pcvVertices.nx = vNormal.x;
pcvVertices.ny = vNormal.y;
pcvVertices.nz = vNormal.z;
}


Which worked well, until I started with the quad ordered vertices. I have tried other code, takin into account 4 positions around, using the vertex position instead of the indices, which are generated like this:
	int iCalcX = 0, iCalcY = 0;
DWORD CurrVertex = 0;
int VertsPerQuad = (Size * Size);
int RowNum = 0;
int ColsPerRow = 8;

//Is it a leaf?
if (pNode->bType == LEAF_TYPE) {
//Back to 8x8 grid position
iCalcX = (pNode->vBoundingCoordinates[0].x + 1024)/256;
iCalcY = (pNode->vBoundingCoordinates[0].z + 1024)/256;

//Calculate row/col position
QuadPosition = ((iCalcY * 8) + iCalcX);

pNode->bGridRow = (BYTE)iCalcY; //Store row position
pNode->bGridCol = (BYTE)iCalcY; //Store col position

//Calculate start values
pNode->StartIndices = n;

for (y = 0; y < 16;y++)	{
for (x = 0; x < 16;x++)	{

pIndices[n++] = CurrVertex;	// triangle 1
pIndices[n++] = CurrVertex+1;	// triangle 2
pIndices[n++] = CurrVertex+Size;	// triangle 3

pIndices[n++] = CurrVertex+Size+1;	// triangle 3
pIndices[n++] = CurrVertex+Size;	// triangle 4
pIndices[n++] = CurrVertex+1;	// triangle 5

}

}
//Calculate end values. Divide indices by 3 already.
pNode->IndicesLength = (n - pNode->StartIndices) /3;
}
}


(some things are hardcoded for testing) It looks all good: But the terrain is acting weird too: I hope someone can help me on this. If you need more info, simply ask. So note though: I have never access to full vertex row data, as it's organized by quadtree level. Any help appreciated, Almar

Share on other sites
Computing normals for vertices and placing verticies into a quadtree are two separate things. First do one, then the other.

karg

Share on other sites
Note that you can compute normals without knowing anything about the neighboring vertices, if you know the data that generated those vertices. Thus, you can compute a normal per vertex by just evaluating the slope of your heighfield at the point in question; say by running a Sobel filter on the height map data around the point that generated the vertex.

Share on other sites
I generally find it handy to have a method of querying height values by absolute coords rather than just by trying to manually extract the vertices from whatever crazy optimised format you've got for rendering. Then normal generation will become much easier.

For the second problem of your terrain looking odd, it looks as if you've forgotten to turn on depth testing, and chunks are being drawn over the top of each other.

Share on other sites
I'm going to try one more time tommorow, using the heightmap directly (did that before though)

If it won't work (which will probably happen), I'm going to change my stuff row-based again, and think of a new structure. I got the theory on paper already.

As for the rendering: the Z buffer is enabled, if that's what you mean. (16 bit though, my *uch* voodoo3 doesn't like 32).

Thanks :)

Share on other sites

That's a lot better :). The squary look. That's the vertex lighting I guess? Still haven't found out how to solve the hills being transparant though.

Thanks :)

Share on other sites
You're just not enabling backface culling. Or Z-buffering. Either will fix that; you're drawing the terrain behind the hill after you draw the hill, which means it gets drawn overtop.

Share on other sites
Yeah, I got it fixed. somehow the Zbuffer wasn't doing very properly - But it didn't give any errors either.

Now it's time for some detail texturing :)

• Game Developer Survey

We are looking for qualified game developers to participate in a 10-minute online survey. Qualified participants will be offered a \$15 incentive for your time and insights. Click here to start!

• 15
• 22
• 17
• 46