[MDX-C#]Vertives transformation (From Object to World space) slow

Started by
12 comments, last by sirob 17 years, 8 months ago
Tx you very much for the suggestions, they here really nice !

- First, I don't wan't to use the shader method, because to be interesting it will required SM3 to be wide spread. It's not the case at all (mostly because of ATI cards)

- Second, the sprite way could fit my needs, but I try to keep the engine behind as flexible as possible (I have other littles projects with it after, that will required pure 3D dynamic process)

- So the "bad" cpu way is the only one present. I managed to use a Vector3 array to give to possibility to the function Vector3.TransformCoordinate to works on the array, it's really much more faster (4 times faster with a little amount of vertices to transforms). The only draw back is the my objects will use more memory (To balance de data from Vector3 Array <-> CustomVertexStruct). It's sad thats the Vector3.TransformCoordinate doesn't accept custom vertex format structure ...

Now the CPU way (Vertice positions transformed on the CPU) VS the "GPU" way (SetTransform on the device for each object).

Is it bad to think this :

I could "capture" when an object has moved (flagged), so it means that I only have to "refresh" his Vertice positions when the object is flagged has "has moved".
Let's say that 100 objects are moving at 10 moves/secondes. That's already a lot of movement. At 60fps it means that I will have to "recompute" the positions of the vertices 1000 times by seconds, the 5000 other times doesn't need position update. Added to this, I have now the possibility to batches.
Simple exemple : All the Cards background texture are the same, it means that I could (even if they are not at the same position in the world) draw the 100 cards in 1 draw !
Conclusion : Drawing 100 cards BackFace moving = 1000 times position refresh + 1 Draw call.

Now the "GPU" way : It means that no matter what, I will have to set X times the SetTransform on the device where X is the number of frame refreshed by seconds. In this case 6000 SetTransforms. And even if the texture is the same, I won't be able to batch them.
Conclusion : Drawing 100 cards backFace moving = 6000 SetTransform + 6000 draws

What's the fastest method ?


Tx you very much for your help !
Advertisement
Ok, let's say that you don't want to use the shader constant based instancing - which works fine not only With SM3.0

<quote>(SM3 for pure hardware, ~SM1.4/2 for shader constant)</quote>.

I wouldn't care about how many calls you have per second, but per frame.
And that's 100 SetTransform(...)(maybe bad) and 100 Draw Calls(not so bad on "newer" hardware).
And then we're back at using the frametime for measuring the speed of your game.
Do you use the NVPerfHUD to measure the performance?
If not, then do it and look how it goes. You should also keep in mind, that
the debug build and DX runtime are slower than the release when doing so.
And - to remind you - see to it, that your code is working and optimize for speed later. As you could see, only small changes can speed up your code by (in the prior case) four times.
I have to leave for now, but I'll have a look at this thread for a while ;)

Good luck,

Martin
--I love deadlines. I like the whooshing sound they make as they fly by. (Douglas Adams)
I'm interested on the "shader constant based instancing", could you forward me a link where its discused ?

Tx you !
Quote:Original post by SeeMe
I'm interested on the "shader constant based instancing", could you forward me a link where its discused ?

Like I said, it's in a sample in the SDK called "Instancing". This shows 3 ways of doing the same thing, two of which are instancing techniques (True instancing, and shader constant instancing). You can search the SDK documentation for the page explaining the sample, and look at the sample code using the Sample Browser. I figure that's about all you'll need to get started.

Hope this helps.
Sirob Yes.» - status: Work-O-Rama.

This topic is closed to new replies.

Advertisement