trueSpace 3.2 exporter update
by Shane McLeod · in Torque Game Engine · 04/17/2003 (4:01 pm) · 7 replies
Well, I've been banging on this for some time now and 3.2 is being nasty. Here's the deal...
trueSpace stores the vertices, uvVerts, and faces in three separate arrays. The face objects have members that store indices into the vert and uvVert arrays to define it's vertices. Here's an example from a cube:
First the 8 vertices that define the cube in 3d space:
Vert[0] - -0.100000, -0.100000, -0.100000
Vert[1] - -0.100000, -0.100000, 0.100000
Vert[2] - 0.100000, -0.100000, -0.100000
Vert[3] - 0.100000, -0.100000, 0.100000
Vert[4] - -0.100000, 0.100000, -0.100000
Vert[5] - 0.100000, 0.100000, -0.100000
Vert[6] - 0.100000, 0.100000, 0.100000
Vert[7] - -0.100000, 0.100000, 0.100000
Now the 14 UV Verts used for texture mapping the same cube:
tVert[0] - [u]0.250000, [v]0.333333
tVert[1] - [u]0.000000, [v]0.333333
tVert[2] - [u]0.000000, [v]0.666667
tVert[3] - [u]0.500000, [v]0.666667
tVert[4] - [u]0.250000, [v]1.000000
tVert[5] - [u]0.500000, [v]1.000000
tVert[6] - [u]0.250000, [v]0.666667
tVert[7] - [u]0.500000, [v]0.333333
tVert[8] - [u]0.500000, [v]0.000000
tVert[9] - [u]0.250000, [v]0.000000
tVert[10] - [u]0.750000, [v]0.666667
tVert[11] - [u]1.000000, [v]0.666667
tVert[12] - [u]1.000000, [v]0.333333
tVert[13] - [u]0.750000, [v]0.333333
So an example face will look like this:
Vix 3 tVix 0
Vix 1 tVix 1
Vix 0 tVix 2
Where each number is an index into the above arrays.
Well this is how it works in every version of trueSpace AFTER 3.2. However faces in 3.2 are being reported from TS like this:
Vix 0 UVix 12
Vix 10 UVix 0
Vix 0 UVix 0
... or this:
Vix 0 UVix 0
Vix 1 UVix 0
Vix 0 UVix 0
Now, a quick observation here shows the problem. In the first example Vix 10 is illegal. There are only 8 Verts.
In the second example, you'll see that point 1 and point 3 are EXACTLY the same. Not a triangle.
To clarify, the correct example data above is reported via the trueSpace 4.2+ APIs using my exporter code. The incorrect 3.2 data is being reported from the exact same code block using the exact same documented API calls on the exact same model. This leaves me scratching my head. I'm hesitant to say that the 3.2 API is screwed but I'm begining to think it is. Either that or I'm missing some undocumented detail.
Anywho, I'm going to get in touch with Caligari and ping them for some support here. I'm not giving up yet.
trueSpace stores the vertices, uvVerts, and faces in three separate arrays. The face objects have members that store indices into the vert and uvVert arrays to define it's vertices. Here's an example from a cube:
First the 8 vertices that define the cube in 3d space:
Vert[0] - -0.100000, -0.100000, -0.100000
Vert[1] - -0.100000, -0.100000, 0.100000
Vert[2] - 0.100000, -0.100000, -0.100000
Vert[3] - 0.100000, -0.100000, 0.100000
Vert[4] - -0.100000, 0.100000, -0.100000
Vert[5] - 0.100000, 0.100000, -0.100000
Vert[6] - 0.100000, 0.100000, 0.100000
Vert[7] - -0.100000, 0.100000, 0.100000
Now the 14 UV Verts used for texture mapping the same cube:
tVert[0] - [u]0.250000, [v]0.333333
tVert[1] - [u]0.000000, [v]0.333333
tVert[2] - [u]0.000000, [v]0.666667
tVert[3] - [u]0.500000, [v]0.666667
tVert[4] - [u]0.250000, [v]1.000000
tVert[5] - [u]0.500000, [v]1.000000
tVert[6] - [u]0.250000, [v]0.666667
tVert[7] - [u]0.500000, [v]0.333333
tVert[8] - [u]0.500000, [v]0.000000
tVert[9] - [u]0.250000, [v]0.000000
tVert[10] - [u]0.750000, [v]0.666667
tVert[11] - [u]1.000000, [v]0.666667
tVert[12] - [u]1.000000, [v]0.333333
tVert[13] - [u]0.750000, [v]0.333333
So an example face will look like this:
Vix 3 tVix 0
Vix 1 tVix 1
Vix 0 tVix 2
Where each number is an index into the above arrays.
Well this is how it works in every version of trueSpace AFTER 3.2. However faces in 3.2 are being reported from TS like this:
Vix 0 UVix 12
Vix 10 UVix 0
Vix 0 UVix 0
... or this:
Vix 0 UVix 0
Vix 1 UVix 0
Vix 0 UVix 0
Now, a quick observation here shows the problem. In the first example Vix 10 is illegal. There are only 8 Verts.
In the second example, you'll see that point 1 and point 3 are EXACTLY the same. Not a triangle.
To clarify, the correct example data above is reported via the trueSpace 4.2+ APIs using my exporter code. The incorrect 3.2 data is being reported from the exact same code block using the exact same documented API calls on the exact same model. This leaves me scratching my head. I'm hesitant to say that the 3.2 API is screwed but I'm begining to think it is. Either that or I'm missing some undocumented detail.
Anywho, I'm going to get in touch with Caligari and ping them for some support here. I'm not giving up yet.
About the author
#2
Assume that the pPolyhedron var is a pointer to a valid truespace polyhedron type (cube).
The output of pFVxs->vix and pFVxs->uvix are where the vertex listings in my first post come from. The exact same cube has different output based on whether the ts version is 3.2 or not. There's just not much room to screw something up in that code. It's pretty straight forward stuff. Nothing complicated in it. I'll admit that this is not my exporter code although the exporter does use some of this logic of course. However, to validate my findings, I ran the cube through the code above for a sanity check in both 3.2 and 5.2. Once again, same code, same cube, same mapping, same texture, different results.
04/17/2003 (7:26 pm)
Sure:// BEGIN MINI TEST
// Number of vertices
int vertnum = tsxPolyhGetNbrVxs(pPolyhedron);
file << "\nVertices : " << vertnum << "\n";
// List of vertices with coordinates
CtsxTxmx3f TransMatrix;
tsxPolyhGetVxTxmx(pPolyhedron, &TransMatrix);
CtsxVector3f* pVertex = tsxPolyhGetVxArray(pPolyhedron);
// Allocate using tsx methods only (cannot use new)
CtsxVector3f* pTransVertex = (CtsxVector3f*)tsxMalloc(vertnum * sizeof(CtsxVector3f));
// ... transform coordinates from local to scene frame
tsxTransformVecs3f(vertnum, pTransVertex, pVertex, TransMatrix);
CtsxVector3f *ptv = pTransVertex;
while(vertnum--)
{
file << ptv->x << "," << ptv->y << "," << ptv->z << "\n";
ptv++;
}
// Free temporary memory on the heap
tsxFree(pTransVertex);
// UV space coordinates ...
int uvnum = tsxPolyhGetNbrUV(pPolyhedron);
file << "\nUv space : " << uvnum << "\n";
CtsxUV* pUV = tsxPolyhGetUVArray(pPolyhedron);
while(uvnum--)
{
file << pUV->u << "," << pUV->v << "\n";
pUV++;
}
// Number of faces
int facenum = tsxPolyhGetNbrFaces(pPolyhedron);
file << "\nFaces : " << facenum << "\n";
// Trace and put faces into filestream ...
CtsxFace** ppFace = tsxPolyhGetFaceptrArray(pPolyhedron);
while(facenum--)
{
CtsxFace* pFace = *ppFace; // Working with simple pointer is easier
int facevertnum = pFace->nbrVxs;
file << "\n" << facevertnum << ":";
CtsxFaceVx* pFVxs = pFace->pFVxs;
while(facevertnum--)
{
file << "{" << pFVxs->vix << ","; // Index into vertex array
file << pFVxs->uvix << "}"; // Index into uv-space array
if(facevertnum > 0) file << ","; // comma serves as separator
pFVxs++;
}
file << "\n";
//END MINI TESTAssume that the pPolyhedron var is a pointer to a valid truespace polyhedron type (cube).
The output of pFVxs->vix and pFVxs->uvix are where the vertex listings in my first post come from. The exact same cube has different output based on whether the ts version is 3.2 or not. There's just not much room to screw something up in that code. It's pretty straight forward stuff. Nothing complicated in it. I'll admit that this is not my exporter code although the exporter does use some of this logic of course. However, to validate my findings, I ran the cube through the code above for a sanity check in both 3.2 and 5.2. Once again, same code, same cube, same mapping, same texture, different results.
#3
I used the above code to test (of course, I added the missing line ppFace++ and the closing brace) in tS3.2 and tS5.1sp2 and got exactly the same results, with a triangulated cube with cubic mapping applied:
The only thing I can guess at is that you're not rebuilding each version with the correct headers/libs. If you try to run the plugin linked against the 3.2 API (or 4) in tS5 (or 6), you'll get incorrect results. This is because tS5 introduced a new member in the CtsxFaceVx structure.
04/19/2003 (9:43 am)
Sorry I didn't get to this right away, but as you may know I've just launched the freecp project and I need to devote time to preparing that source.I used the above code to test (of course, I added the missing line ppFace++ and the closing brace) in tS3.2 and tS5.1sp2 and got exactly the same results, with a triangulated cube with cubic mapping applied:
tS3.2: tS5.1:
Vertices : 8 Vertices : 8
-1,-1,0 -1,-1,0
-1,-1,2 -1,-1,2
1,-1,0 1,-1,0
1,-1,2 1,-1,2
-1,1,0 -1,1,0
1,1,0 1,1,0
1,1,2 1,1,2
-1,1,2 -1,1,2
Uv space : 8 Uv space : 8
-1,1 -1,1
0,1 0,1
0,0 0,0
-1,0 -1,0
0,-1 0,-1
1,0 1,0
1,-1 1,-1
1,1 1,1
Faces : 12 Faces : 12
3:{1,0},{3,1},{2,2} 3:{1,0},{3,1},{2,2}
3:{0,3},{1,0},{2,2} 3:{0,3},{1,0},{2,2}
3:{2,4},{5,2},{4,5} 3:{2,4},{5,2},{4,5}
3:{0,6},{2,4},{4,5} 3:{0,6},{2,4},{4,5}
3:{2,3},{3,0},{6,1} 3:{2,3},{3,0},{6,1}
3:{5,2},{2,3},{6,1} 3:{5,2},{2,3},{6,1}
3:{1,7},{7,5},{6,2} 3:{1,7},{7,5},{6,2}
3:{3,1},{1,7},{6,2} 3:{3,1},{1,7},{6,2}
3:{4,5},{5,2},{6,1} 3:{4,5},{5,2},{6,1}
3:{7,7},{4,5},{6,1} 3:{7,7},{4,5},{6,1}
3:{4,2},{7,1},{1,7} 3:{4,2},{7,1},{1,7}
3:{0,5},{4,2},{1,7} 3:{0,5},{4,2},{1,7}The only thing I can guess at is that you're not rebuilding each version with the correct headers/libs. If you try to run the plugin linked against the 3.2 API (or 4) in tS5 (or 6), you'll get incorrect results. This is because tS5 introduced a new member in the CtsxFaceVx structure.
#4
Trying again...
04/19/2003 (10:35 am)
Hmmm, could be I s'pose. I work on this stuff incredibly late at night and might have screwed up the linkage. Trying again...
#5
04/19/2003 (10:50 am)
Thanks Simon. That's what it was. Jeez, that's a little embarassing. I missed the header switch. Bleh.
#6
07/07/2003 (10:29 am)
So is there still work being done on this?
#7
I'll keep you posted.
07/08/2003 (1:47 pm)
Actually, I have been unable to do anything with this for quite some time as my paying job has been quite intense. Things are slowing down for a bit and I'll be reacquainting myself with where I was.I'll keep you posted.
Torque Owner Simon Windmill