I just created an empty class that's using btIDebugDraw interface, when I set the debug draw mode to btIDebugDraw::DBG_DrawWireframe, I get very slow rendering, 4-6 frames per second, otherwise I don't have this problem.

// Init Physics
debugDrawer = new DebugDrawer(device);
debugDrawer->setDebugMode(btIDebugDraw::DBG_DrawWireframe);
mDynamicsWorld->setDebugDrawer(debugDrawer);

// Rendering
float ms = GetTickCount();
mDynamicsWorld->stepSimulation(ms / 1000.0f);
mDynamicsWorld->debugDrawWorld();

Maybe the slow(er) framerate is because installing a debug drawer (*ANY* debug drawer) requires extra work from the Bullet library. I assume you are implying in your post that you provided an empty implementation of the debug drawer class and are surprised it was still slow(er) framerate.

Can you give an exact measurement in milliseconds per frame as to how much slower it is to enable debug drawing in Bullet?

Also, don't leave debug draw on for the whole frame ...imagine the routine below is called each frame right before the g_pD3DDevice->EndScene() call.

void

CPhysicsEngine::DebugDraw( bool debugDraw )

{

//

// Optional but useful: debug drawing

//

if (debugDraw)

{

m_dynamicsWorld->getDebugDrawer()->setDebugMode( btIDebugDraw::DBG_DrawWireframe );

m_dynamicsWorld->debugDrawWorld();

m_pDebugDrawer->DebugPresent();

}

m_dynamicsWorld->getDebugDrawer()->setDebugMode( btIDebugDraw::DBG_NoDebug );

m_pDebugDrawer->m_vertices.clear();

}

FPS is a flawed metric, please provide milliseconds per frame as requested.

http://www.mvps.org/directx/articles/fps_versus_frame_time.htm

I think you have a serious communication problem and helping you is very difficult because of it. I have observed this on all of your posts. You neither listen to the people who offer you help nor work to clarify your own problems.

When you experience slowdown using the debug drawer, do you have a non-EMPTY implementation of the class? If so, you need to share that code, if you aren't batching the vertices for a single large draw call later on then you will experience slowdown.

If you have an EMPTY implementation of the debug drawer class and still experience slowdown, you should expect that this is because Bullet does extra work when you enable debug draw. You can validate this for yourself by measuring frame time in milliseconds per frame and running an experiment. Also you can trivially inspect the Bullet code and see that it does call some extra routines (even if they are EMPTY) when you enable debug draw.

The problem is caused by the terrain, when I turn off debug draw for the terrain and only debug draw others meshes I don't get this problem.

So, the question is: Can I debug draw the terrain without making the rendering slow down? Notice that the terrain is 40803 vertices.

Again ... it depends on how you implement your debug draw code. Can you share your implementation? If you don't batch the lines, then I believe each triangle amounts to 3 draw calls. That is not likely to be fast.

As I told you, this problem occur with EMPTY debug draw class.

You asked me how many milliseconds per frame, I don't know how that would help to resolve the problem.

class BulletDebugDraw : public btIDebugDraw
{
int m_debugMode;

public:
DebugDraw(LPDIRECT3DDEVICE9 device);
virtual ~DebugDraw();

virtual void drawLine(const btVector3& from,const btVector3& to,const btVector3& fromColor, const btVector3& toColor);
virtual void drawLine(const btVector3& from,const btVector3& to,const btVector3& color);

virtual void drawContactPoint(const btVector3& PointOnB,const btVector3& normalOnB,btScalar distance,int lifeTime,const btVector3& color);

virtual void reportErrorWarning(const char* warningString);

virtual void draw3dText(const btVector3& location,const char* textString);

virtual void setDebugMode(int debugMode);
virtual int getDebugMode() const { return m_debugMode;}

};

No .cpp file, just empty class.

Did you try my suggestion of only enabling debug draw for a brief function call and then disabling it for the rest of the frame? I don't know why I even bother typing replies to you ...

Well, yes, I tried that, whenever I call mDynamicsWorld->debugDrawWorld(); even with brief function call I get very slow rendering with empty debug draw class.

As you know the problem disappear when I don't debug draw the terrain.

I think maybe the thing you aren't realizing is that even with an empty implementation you don't want to just call debugDrawWorld(). If you want to opt out of displaying physics debug information, simply avoid calling debugDrawWorld(), don't call it with an empty implementation class.

P.S. Read the code for DebugDrawWorld() do you want to do all those steps just to draw nothing extra on the screen?