Tranforming a model's vertices

[Nemo Krad]

The vertex positions you are getting from the buffer will be relative to the mesh's position.

[DoomMarine]

the positions im getting i dont transfrom and they still get screwed up, i think i initialize the vertexpositiontexture[] and the short[] arrays wrong, how am i to get the total number of indices and vertices?

[Nemo Krad]

Right I have just had to pay with this, the position of the vert is relative to the position of the mesh, you don't have to translate it it's position is equal to mesh.position + vert.poition.

For example in the code I have just used it in I get the vertext positon like this:

Code:

                for (int side = 0; side < 6; side++)
                {
                    int off = side * 4;
                    Vector3[] thisPos = new Vector3[] { els[off + 0].Position + block.myPosition, els[off + 1].Position + block.myPosition, els[off + 2].Position + block.myPosition, els[off + 3].Position + block.myPosition };
                ... more code ...

So to get at the position of a vert in a given primitive I can use

Code:

    VertPos = thisPos[3];

Which will live me position of the forth vert in the vertex buffer relative to the location of the mesh.

[DoomMarine]

i dont think u have understood my question, when i use this code

Code:

VertexPositionTexture[] myverts = new VertexPositionTexture[mesh.VertexBuffer.SizeInBytes / mesh.MeshParts[0].VertexStride];
               
               
                mesh.VertexBuffer.GetData<VertexPositionTexture>(myverts);
                if (mesh.IndexBuffer.IndexElementSize == IndexElementSize.SixteenBits)
                {
                    short[] myinds = new short[mesh.IndexBuffer.SizeInBytes / sizeof(short)];
                    mesh.IndexBuffer.GetData<short>(myinds);
                    for (int i = 0; i < myinds.Length; i += 3)
                    {
                        mylist.Add(ProcessMeshTrianglesShort(myverts, i, myinds));
                    }
                }
               
                if (mesh.IndexBuffer.IndexElementSize == IndexElementSize.ThirtyTwoBits)
                {
                    int[] myinds = new int[mesh.IndexBuffer.SizeInBytes / sizeof(int)];
                    mesh.IndexBuffer.GetData<int>(myinds);
                    for (int i = 0; i < myinds.Length; i += 3)
                    {
                        mylist.Add(ProcessMeshTrianglesInt(myverts, i, myinds));
                    }
                }

i need to find a number for the total number in the arrays to make it like this

Code:

int[] myinds = new int[mesh.IndexBuffer.SizeInBytes / sizeof(int)];

i was wondering i got the correct number to put in each array and which way it was actually supposed to be done

[Nemo Krad]

Yes, it looks like I have totally missed the point!

Why are you using the index buffer??

When getting the vertexbuffer I used this calculation

Code:

                VertexPositionNormalTexture[] els = new VertexPositionNormalTexture[4 * 6];
                block.blockMesh.Meshes[0].VertexBuffer.GetData<VertexPositionNormalTexture>(els);

The object is a simple cube so has 6 sides and each side is made from 4 Verts, so the array size will be 4*6.  It should be the same for the index buffer. I guess you need to know how many primitives are in your mesh to do this. When I have time I will see if I can find out how you can do this. Maybe the new Picking sample on the Creators club could help you?

[DoomMarine]

i am currently trying to get each meshpart in the mesh and find the value of its primitive count, adding to the mesh's "totalprimcount" but that number multiplied by 3 or just by itslef doesnt seem to work.

EDIT:
I just remembered that a meshpart also stores a number of vertices for itself and getting each number and adding together seems to work.

[Nemo Krad]

Oh good, so have you solved your issue?

[DoomMarine]

no the issue is still there. when i compare the mesh data i tagged to the mesh with the triangles made from the vertex buffer some of the vertices positions dont match up, and i still get the same results as i did before i got rid of the index buffer. I wonder iff there is some sort of offset that needs to be applied to the positions to get the real ones, although in both the mesh data and vertexbuffer data the 1st vertex has the same coordinate.

EDIT: ive also compared the total number of vertices stored in the mesh data to the vertices i got from the vertex buffer and they dont match, so i gettin the total number of vertices doesnt seem to work.

EDIT: i have initialized the vertexposition texture i use in a different way and the total numbers match up but the positions are wrong now and it has nothing to do with the transformation of the vertices.

[DoomMarine]

ok i found the problem with the vertex buffer data, i need to use the 3rd overload of GetData to get the right results, now i am back to the simple problem of transformation, i can now change the position of the object and rotate it but scaling screws it up. This is without using the meshes parent bone transform though so that may have something to do with it. any help would be appreciated.

[Nemo Krad]

Sorry mate, I think this is a little out of my depth at the moment, if I find anything to help I will post it here.

[DoomMarine]

ok i think that the problem with the scaling has something to do with the bones of the model. how exactly would u calculate the child bones transform from the parents i assumed it was something like actualTrans = storedTrans * parentTrans but im not sure.

[DoomMarine]

ok so i take it no one else can help me out?

[mikeschuld]

This would depend on the transform type. Translations would be child + parent, scaling would be child * parent, and rotation (since we are using quaternions) would be something like child x parent (that's a cross, as in cross product)

[DoomMarine]

so your saying that i should do it manually instead of using vector3.transform?

[DoomMarine]

ok i tried to do this only noticing that i have no idea where the bones scaling position and rotations are stored if they are at all, and im not sure thast would help the problem anyways since it is just the scaling of the collision mesh thats the problem