Anyone done any analysis of D3DXIntersect() in regards to performance? I am considering using it for terrain geometry collision but I have a feeling that the function would not internally use spatial division so every call will test against every tri. But then again, if its fast enough then that may not be as big a hurdle as I imagine. As a fall back I would move to either my own rolled tri intersect or D3DXIntersectTri.

Quote:Original post by Byron
I am considering using it for terrain geometry collision but I have a feeling that the function would not internally use spatial division so every call will test against every tri.

I'm not aware of it using any spacial division at all. It should test against each triangle seperately.

For heightmap-style terrain, I think you could easily write a solution that would work better, and it would probably be worth the time.

Also, if you're using a physics engine of some kind, most of them include collision and intersection tests of different kinds, and they would likely use spacial division and be quite efficient. If you plan on eventually using an external physics engine, this might be a good place to pick one and start using it.

Hope this helps.

Quote:
For heightmap-style terrain, I think you could easily write a solution that would work better, and it would probably be worth the time.

Sorry, I should have specified that by terrain I don't literally mean an outdoor environment more a sectored room system with uneven floor. My idea would be that I would supply a collision mesh that is a simplified view of the room.

Quote:
Together with the DirectX SDK there should be a program called "PIX for windows". It can show you how long each DirectX call took to execute together with some other statistical information.

Yes, quite right. However I am slightly spoiled by using Pix for another platform.

Besides I would have thought that given what I am doing is essentially a CPU task that VTune would be more appropriate here - and holy hell do I hope I never have to use that app again :)

My main concerns with doing my own measurement this early is that any case I come up with will be artificial whereas other people might have used D3DXIntersect() in anger in their apps for real world situations and found it wanting - in which case that kind of knowledge is far more useful to me than any small tests I can do at this precise moment.

Thinking a little further about this though the actual code to use D3DXIntersect() is not that big so I think I could simply suck-it-and-see for the moment.

Quote:Original post by Byron
Thinking a little further about this though the actual code to use D3DXIntersect() is not that big so I think I could simply suck-it-and-see for the moment.

This would be my advise. Using the D3DX functions is definitely quicker (in the development sense) and easier - might as well implement the code in simple terms and optimize it later if needs be. Ever heard the saying "Get it right, then get it tight"? [smile]

I would imagine D3DXIntersect() wouldn't be close to a hand-rolled and fine-tuned custom implementation, but until it shows up in your profiler as a worst offender you might as well invest your time elsewhere...

hth
Jack

You have a point. Cheers.