Poor performance

Sairon

01-05-2007 16:50:07

Hi, I'm not using NxOgre, but I'm guessing this is where all the experts on using PhysX with ogre hangs out. I'm having a scene with 63 actors in it. 62 of these actors use NxTriangleMeshes and are static. Looking at the NxSceneStats reveals that there's 0 contacts, which I presume is collisions. Now the problem is that running a simulation with all these actors makes my FPS go down to bellow 60, this is in an application without any game logic and is simply only rendering a GPU constrained scene. My computer is pretty good and without the "physics" simulation I'm at 250~ FPS. with 200k tris.

Any input appriciated.

Sairon

01-05-2007 19:22:45

Switching to for example convex shapes grants reasonable performance, however it doesn't reflect the geometry very well at all. However, geometry which doesn't have anything which can even collide with it in the general vicinity seems to eat performance like crazy.

betajaen

01-05-2007 20:55:16

How many triangles are used with the meshShapes, you said 250k is that with PhysX or DirectX/OpenGL?

If it is with the meshShapes, thats way to much for a real-time simulation. I'd optimise it to 1/10th of it's triangle count - if it's possible.

[Edit]

You could also implement some sort of paging system, that would work pretty well. At least then you could have 250k triangles, but not all at once.

Sairon

01-05-2007 21:00:05

Thanks for the reply!

The entire level uses ~200k tris for the meshes in Ogre. I don't know the poly count of the ones resulting from the cooking, but I'd hope it's less. I don't see how it can affect performance in such a drastic way when there's nothing even potentialy colliding with it though. I'd hope that there's a bounding box check before the heavy per poly tests.

I'm doing a software simulation btw.

[EDIT]

I've thought about a paging system of some sort, but was thinking that PhysX would handle it for me in a much more optimal way hehe.

betajaen

01-05-2007 21:14:57

I would assume it does at least a bounding box detection before going to a triangular level. But facts are facts.

There are a few things you could do, to speed it up.

- Work in release mode when evaluating, Debug mode really slows down the application. I usually get 1500 FPS in Release mode, when I get 50 in Debug.

- Cook the meshes to disk, then read them back in from the disk. Instead of loading them in and cooking. This will save a LOT of time.

- Turn off the flag, for mesh visualation. Even if you don't use the PhysX debug line system, certain time is dedicated to the rendering and processing of the debug system. It really speeds up when used with heightmaps, I imagine the same is with meshShapes.

- Optimise the mesh, Optimise the mesh and Optimise the mesh! It really does help.

- Turn "off" any NxActors that not in the active scene. Delete any NxActors that aren't used at all, you can always create them again. It is a primitive paging system, but it does help. If you do need some sort of detection far away, you could always use a LOD version of the mesh, and switch to the high res. one when you approach it.

- Optimise the mesh. I know I'm repeating my self but it's the best way to gain FPS.

Sairon

02-05-2007 09:48:33

Found the problem, it's a bit embarassing that I didn't test it before I guess. But the problem was that I used the debug flag for visualising shapes in the remote debugger. Which means a huge extra overhead even if the debugger isn't used. Thanks for the help though :)

betajaen

02-05-2007 09:59:26

No problem. I'm curious; What FPS are you getting now?

Sairon

02-05-2007 11:41:09

Since I don't have much out yet that can collide with the geometry I'm getting max FPS, it's entirely GPU constrained. I'l post an update once I get some stuff running around on the geometry and actually colliding with it. I've sliced it up into neat little pieces so I'm hoping that it will scale pretty well.