#### Archived

This topic is now archived and is closed to further replies.

# Transforming vertices

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

## Recommended Posts

This is a total newbie question, so be easy. I have my skin mesh totally animated now, using shaders, and I needed a fast method to perform collisions and line intersects on individual body parts. With vertex shaders, it''s impossible (right??) to know where a vertex is in 3D space except when it''s being rendered. If I were to transform them to check collision, I might as well do software skinning. So I constructed a very simple mesh which serves as a bounding area around each bone. Most only have 8 vertices, some 16, etc. I transform these in software when collision needs checked, rather than every frame. This is how I''m currently transforming them:
D3DXVECTOR4 FVec;
D3DXMATRIX *MTrans = &CurrentBoneMatrix;
Vert = OriginalVertexArrayPtr;
verts = LockVertexBufferOnCollisionDummy();
for(INT v=0; v<NumVerts; v++)
{
D3DXVec3Transform(&FVec, Vert, MTrans);
verts->x = FVec.x;
verts->y = FVec.y;
verts->z = FVec.z;

Vert++;
verts++;
}
FVF for vertices is only x,y,z. One thing I could do is add another veriable (w) to use a straight up D3DXVECTOR4. That would remove the extra copy per vertex. Sure, my dummy mesh is probably only around 100+ vertices, but that doesn''t mean I won''t need to do this with hundreds of them. I just want to make sure this routine is reasonably fast as I keep building. My question is: is this a stupid way to do this? D3DXVec3Transform? Should I transform the vertices myself instead? Is there a D3DX method to transform a mesh'' vertices for me? My current project requires lots of mouse pointing at objects, so some bounding objects may be pretty complex. Thanks for any suggestions.

##### Share on other sites
Sounds like a good plan generally (using a lower detail mesh for collisions etc).

Using D3DX functions will take advantage of current and future CPU optimisations by MS and engineers from the CPU manufacturers.

D3DXVec3TransformArray() seems particularly well suited to your needs.

Simon O''Connor
Game Programmer &
Microsoft DirectX MVP

##### Share on other sites
I second what Simon says (heh, "Simon says"), but with a little addition.

Why is the collision mesh in a vertex buffer? What pool is it in? You might be transferring the data to the graphics card, for no good reason, only to ask the graphics card to give it back, which is slow.

Feel free to ignore the remainder of this post. It''s getting picky about optimizations.

Also, D3DXVec3TransformCoord writes to a vec3 (it does the divide by W for you first). Since you''re not projecting, calculating and dividing by W is wasteful. Your method calculates W, then throws it away, but at the expense of needing to copy the data. I''m not sure which will be faster.

If you were to use Vec4 source (with W==1), the SSE code becomes simplified, and may actually be faster despite taking a bit more RAM.

Fastest of all would be to roll your own SSE version that takes Vec4 input and output, but doesn''t care about calculating W. That''s becoming overkill unless it''s a bottleneck for your app.

##### Share on other sites
quote:
Original post by S1CA D3DXVec3TransformArray() seems particularly well suited to your needs.

I some how totally missed this method, and the two that follow it in the docs. Thanks much for that!

quote:
Original post by Namethatnobodyelsetook
Why is the collision mesh in a vertex buffer? What pool is it in? You might be transferring the data to the graphics card, for no good reason, only to ask the graphics card to give it back, which is slow.

I should have mentioned it was only temporarily in a mesh. I did so to easily render it, to make sure I was transforming it correctly. It's in system memory.

quote:
Feel free to ignore the remainder of this post. It's getting picky about optimizations.
That's why I posted

quote:
D3DXVec3TransformCoord writes to a vec3 (it does the divide by W for you first).

Or even D3DXVec3TransformCoordArray, eh? I didn't find these methods. Guess I skimmed through the list of math methods too fast.

quote:
If you were to use Vec4 source (with W==1), the SSE code becomes simplified, and may actually be faster despite taking a bit more RAM.

I think transformcoord would be faster / more suited for me, since I don't really need to transfer the vertices anywhere. I just need to transform them, then check for collisions. Everything happens in system memory. You still think vector4 would be faster?

quote:
Fastest of all would be to roll your own SSE version that takes Vec4 input and output, but doesn't care about calculating W. That's becoming overkill unless it's a bottleneck for your app.

Not yet. I'll save that for a time when it seems worthwhile

Thanks much for pointing out these methods for me!

[edited by - Jiia on June 5, 2004 12:06:28 AM]

1. 1
Rutin
22
2. 2
3. 3
4. 4
5. 5

• 9
• 9
• 9
• 14
• 12
• ### Forum Statistics

• Total Topics
633308
• Total Posts
3011293
• ### Who's Online (See full list)

There are no registered users currently online

×