Hello,
I'm having a bit of trouble implementing a new framework. I derived my own class around the btIDebugDraw interface, and everything renders perfectly except for one thing. I only enable wireframe rendering, so AABBs and contact points are not being rendered. I create a static trimesh (using a btBvhTriangleMeshShape) and when anything collides with it my program hangs inside of a platform specific render synchronization call. While I don't expect anyone to be able to debug this specifically, I am wondering what happens with respect to debug rendering when an object collides with another object?
Any advice or insights would be greatly appreciated.
Thanks.
- Alex
Problem with debug rendering
-
AlexSilverman
- Posts: 141
- Joined: Mon Jul 02, 2007 5:12 pm
Re: Problem with debug rendering
Hello,
I've found the problem. When something collides with a mesh, btConvexTriangleCallback::processTriangle() is called several times (as part of detecting overlapping pairs I believe), which renders the mesh an additional time. The problem was that the render calls that I am using inside my derivation of the debug renderers drawLine() relied on these calls coming in between our triggers that rendering is beginning and ending (the equivalent of GLBegin() and GLEnd() ). There was no problem rendering the mesh normally, but as soon as something collides with it, an overlapping pair is detected, and the triangles are rendered an additional time, outside of the aforementioned triggers, causing the hang I mentioned.
I'm not sure how common it is to implement debug rendering the way I have, and I'm no graphics guru (perhaps why I implemented debug rendering this way), but I would think that having draw calls happening implicitly (during collision detection) as opposed to explicitly (as a result of my calling btDiscreteDynamicsWorld::debugDrawWorld() ) could open up the door to more problems like this.
Hopefully this will help others avoid getting hung up on this for 2 days like I did
- Alex
I've found the problem. When something collides with a mesh, btConvexTriangleCallback::processTriangle() is called several times (as part of detecting overlapping pairs I believe), which renders the mesh an additional time. The problem was that the render calls that I am using inside my derivation of the debug renderers drawLine() relied on these calls coming in between our triggers that rendering is beginning and ending (the equivalent of GLBegin() and GLEnd() ). There was no problem rendering the mesh normally, but as soon as something collides with it, an overlapping pair is detected, and the triangles are rendered an additional time, outside of the aforementioned triggers, causing the hang I mentioned.
I'm not sure how common it is to implement debug rendering the way I have, and I'm no graphics guru (perhaps why I implemented debug rendering this way), but I would think that having draw calls happening implicitly (during collision detection) as opposed to explicitly (as a result of my calling btDiscreteDynamicsWorld::debugDrawWorld() ) could open up the door to more problems like this.
Hopefully this will help others avoid getting hung up on this for 2 days like I did
- Alex