greetings i have created a small project which involves of rendering doom3 (md5) models using directx 9c.There is some dynamic lighting and shadowing involved and all this contributes to a low frame rate. I render the triangles by passing them into a d3dxmesh (which later on passes the data into a vertex buffer).Each model is rendered twice on for the shadow volume and then a second time for the actual draw (also a small grid is rendered in order to produce the shadows) therefore i have four-five vertex buffer switches.I have a frame rate of 13 frames per second which i consider tooooo low (something more tha 8000 vertices), also i forgot to mention that for each d3dxmesh which is constructed from the interpolated data, i compute normals and tangents. I dont know if this frame rate is something which i had to expect ,or iam doing something wrong.I am thinking to abandon the d3dxmesh format and send the data directly to a huge vertex buffer or to loose my sleep and proceed to some high tech render 2 vertex buffer aproach.My hardware is an intel at 3Ghz 1Gb Ram and an ATI 1300 256Mb RAM .

hi
i dont think its because d3dxmesh, as i understood its just for filling vb data and rendering.
i'm also rendering md5 but i'm not getting 13 fps, for about 100 q4 models approx 2000 faces gives me 7-10 fps on 3.2ghz 1gb ram and geforce6600 gt.
try doing these things:

1. when doing skinning (Pos, TNB), dont lock vb before and unlock it after all computation is done, use temp buffer for this, and after that just lock, do mem copy, and unlock immediately.

2. for shadow volume, move it to gpu and you get extra boost

3. also, for TNB calc, you only need to compute TN and compute B on vertex shader

4. i dont know how you compute TNB data, but if you'r using the skinnned mesh for that like computing avg normals its not fast, you can compute (using base frame data) transformatino matrix for transforming TNB that you compute for the base frame only and when skinning use that matrix with the right weights.

5. after all, using correct SSE can double you performance

Actually, I've just got MD5 loading working in my engine. I wouldn't use a D3DXMesh, that seems a bit pointless to me. I just maintain a VB and IB myself.
Why do you have 4 or 5 VB switches? Surely you should be using the same VB in all the draw calls?

I get about 2000 FPS (Although FPS is pretty meaningless) on my AMD 64 5600+ 2GB RAM, NVidia 8600 GT, XP Pro, rendering the imp model (Which is something like 800 tris). I also do all vertex animation in the vertex shader, and the VB gets filled with two frames worth of data (I'm doing it in a horrible keyframe like way just now).

I don't see how you could get 13 frames per second unless you're using the wrong lock flags on the VB, or creating the mesh every frame or something.

First thank u very much for the answers!!I have committed all the deadly sins of 3d programming .The shadow volumes are created into the gpu
(create a shadow map on a shader using a renderable surface ).The binormals are
computed by using the tangent and the normals.
I have to admit that i create a mesh for each frame,
there is an array of vertices,indices which i insert into the mesh
i lock for inserting vertex and index data (lock and unlock for each case) then compute normals using D3DXComputeNormals, compute tangents by other code and not by D3DXComputeTangents.This happens for each time i render a model.


Render procedure for each model
1)Vertices indices come ii
2)Create mesh
3)Lock for vertex data unlock
4)Lock for indices ,unlock
5)Compute normals
6)Compute tangents

7)Render once to create shadow map
8)Render model with light

I think that my approach is totally wrong therefore ill try your advice
many thanks

made a mistake I create a mesh for each model (probably thats why my framerate sucks so much )

why you are creating a mesh each time you render?
second, index buffer should remain static (set at once on init or something)
also, compute normals yourself, that way you can optimize it (you dont actually knows what dx doing inside this function)
from my tests using d3dx for matrix/vector math is not a good idea, its very slow comparing to good c/sse code.
the process you wrote isnt so clear, you are doing lock in step 3,4, where you'r unlocking it?
also you didn't wrote any skinning info you'r doing...

Quote:from my tests using d3dx for matrix/vector math is not a good idea, its very slow comparing to good c/sse code.

This seems absurd...

I think your "tests" are flawed.

I agree. The D3DX math stuff is pretty well-optimized. I think I'll call BS unless I see some benchmarks and the results.

Quote:Original post by Matt Aufderheide

Quote:from my tests using d3dx for matrix/vector math is not a good idea, its very slow comparing to good c/sse code.

This seems absurd...

I think your "tests" are flawed.

D3DX uses SSE / 3DNow wherever available, so long as the matrices are aligned to 16 byte boundaries. It doesn't use any special instruction sets for vectors, because a) they're usually 3D, not 4D, b) all the code is inline anyway and c) it's rarely worth the minor performance benifit.

it seems that you didn't understood what i ment by saying d3dx is slow,
i wrote "its very slow comparing to good c/sse code", that means that if your are writing some loop (to do the skinning part for example) and call d3dx functions to do the transformations its slow comparing to writing the same loop in asm and optimized sse code.
function call overhead and cache is very important when you'r optimizing.
this also applied to quaternion math & conversions and shadow volume construction.
anyway, check http://developer.intel.com/ to learn more about optimization.