Jump to content
  • Advertisement

Archived

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

Mephs

D3DXIntersect ate my FPS

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

As the title says, I use the D3DXIntersect function to determine placement of items upon a terrain mesh. Each terrain mesh is a 32x32 chunk and chunks are frustum culled before I perform intersection tests (avoiding several unnecessary calls). However D3DXIntersect, even when only called once per frame, wrecks my frames per second. I originally thought my multiple pass, multitextured terrain was what was killing speed, but through heavy testing I've narrowed it down to D3DXIntersect being the worst culprit for lowering speed. My average FPS when not using D3DXIntersect, is 50-60fps, when I use it, the FPS lowers to 10-15 FPS. Nothing else in the engine is giving that kind of performance hit. So I'm wondering, am I best off writing my own intersection testing routines or is D3DXIntersect about as good as it's going to get? Cheers, Steve Oh, I should also make note that I only perform intersection tests when placing objects in my level editor, not in general navigation, so the function is only used when absolutely necessary. [edited by - Mephs on April 20, 2003 12:18:58 AM]

Share this post


Link to post
Share on other sites
Advertisement
I don't use mesh objects for my terrain, instead I use a collection of VB's, but I came up with exactly the same problem. The way I solved it was to do quad-based ray-picking (so, instead of using the rayintersect on your 32x32 meshes, do it on 1x1 quads that cover the same area as your 32x32). If you record a hit, then you can use the 32x32 mesh to get an accurate hit for the ray.

This works very well at minimum speed loss. The only downside is that the detection on a quad may record false hits (which you can ignore if the more accurate hit on the 32x32 mesh fails), or it may miss valid hits if the geometry is significantly deformed.

RayIntersect is very fast, but in your case you are using it for hundreds of meshes (assuming you are looping through each visible mesh to see if there is a hit) which will cause slow-downs no matter what method you use.

I would recommend writing your own Ray-Intersects-Triangle routine. It'll help you immensely. For example, you could sub-divide your entire rendered terrain into two triangles, and do some hit detection. This would immeadiately disqualify half of the terrain. Then you can sub-divide the remaining half-terrain into two tris... etc... etc... etc..

Learning to fly is easy, but as a tortoise, the landings are really rough.

[edited by - SoaringTortoise on April 21, 2003 5:02:56 AM]

Share this post


Link to post
Share on other sites
Write your own functions. That way you can customize them towards your app and you got the code so any bug fixes are done quickly unlike ms. I went with gl after using d3d for four years and at first writing my own functions was pain but I''m glad I did it. I''ve also learned whole new stuff and I optimized the crap out of my math routines in the process. Who knows how ms coded their stuff. I heard there is a bug for intel cpus in one of the d3dx math routine, xform coord array or some such. If ms had a bit of brain they would have provided source code to their d3dx lib routines which is sorely needed. Maybe if people here wanted they could have flooded ms mailboxes with requests for source code and convince some boneheaded bean counter to release them. So much for customer is always right mantra.

Share this post


Link to post
Share on other sites
Hmm... I hate to necro threads, but I just had a new thought about my problems here. I''m just wondering if D3DXIntersect locks the mesh vertex buffer.... I suppose to get the information, it must do, and of course reading from video memory is a bad bad thing causing much slowdown. So would I be correct in assuming that if I retained a system memory copy of the vertices, and performed an intersection test using this data (probably using D3DXIntersectTri), rather than letting D3DXIntersect do it''s thing, that it would be much quicker, as it does not have to read info from the video memory??

Share this post


Link to post
Share on other sites
D3DXIntersectMesh is a fairly optimized routine, but it is only optimized for checking a ray against an arbitrary mesh. Anything like a ray-tracer or normal map generation tool will need a better acceleration structure to take advantage of known bounding boxes, etc. The overhead for creating the required acceleration data structures is not practical for lone ray tests, but is quite useful when you know that a lot of tests will be performed

It is also a good idea to use a quick bounding sphere/box test if possible before using D3DXIntersectMesh. No reason to go for triantle accuracy if you know that the ray will not intersect easily.


For the posts original comment about hurting performance, I would be curious to know how many ray tests are happening per scene. Even if you wrote your own, it would be a good idea to see if they are necessary (in addition to making sure that the memory read from for the tests is not in vid-mem ;-) )

Craig Peeper
Microsoft, Direct3D

This posting is provided "AS IS" with no warranties, and confers no rights.

Share this post


Link to post
Share on other sites
The triangle level intersection tests are a definite necessity, any less accuracy will not suffice at all. The reason being, the intersection test is being used to place item meshes onto a heightmap mesh. Framerate is not too important, but it would be nice if the editor didn''t come grinding almost to a complete halt when placing items. I suppose I could check for intersection every few frames, rather than every frame that the object editor is in use for... but that would lead to jerky object placement, meh.. it''s a tradeoff I suppose, but loss of accuracy isn''t, otherwise items will be floating in mid air, not registering intersections that should be, and so on, which just wouldn''t do.

As a side note, the mesh objects are only to provide a brute force alternative, once they go through my octree process, they are rendered as indexed triangle lists instead. It''s just handy to keep them as meshes for the D3DX functions. I think I''m gonna hafta do away with the meshes though as I plan to alter my octree process, allowing for huge maps, doing so will make it futile to store all my geometry as meshes because there will be a lot of it wasting a lot of video memory. Instead I''m going to be creating one large dynamic VB and copying the data into it at runtime.

I''ve pretty much decided to go with storing a second copy of the full set of geometry in system memory, as there are other things I can use the data for that would benefit from not downloading geometry from the video card. My worst case scenario is that the geometry is too large to store in RAM (I''ve not decided on a definite FVF size yet as I may switch texture blending methods), in which case I''ll resort to loading from disk, but only as a worst case scenario, cause obviously that would also slow things down (or impose loading times).

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!