Debug visualization and performance

[Starfox]

Are there any plans to introduce a faster debug draw interface in Bullet 3.x? Wireframe drawing of a bvhTriangleMesh for example is painfully slow, if only because it's being processed triangle-by-triangle and line by line. Wouldn't a batch interface (for example drawTriangles(btTriangle* Triangles, int Count) ) be much faster?

I understand the importance of being able to implement a decent debug drawer by only implementing drawLine, but a default debug drawer class with overridable default implementations for drawTriangles that forward to drawLine would probably be possible to add without breaking existing APIs (or might be worth it in case of a major version change like 3.x). With graphics APIs moving exclusively to batch-mode and VBO-like APIs I think this would be better. If I'm missing some way to enable high performance rendering with debug drawing I'd love to hear about it.

[STTrife]

I agree with you, but you can still make VBO's with lines too. What I did was for each object made it only turns on debug rendering for that object, and the debugDrawWorld is called once and the functions in my DebugDraw put the lines that it wants to draw in a VBO. It's kind of a hassle, but it does work fast then.

[MaxDZ8]

I disagree.
Just to get things clear: immediate mode is possibly the cheapest illusion OpenGL created. D3D has banished immediate.
Turning Bullet Immediate in a buffered system is pretty easy to do in my opinion and I really don't think there's much to do here. It's a debug facility.

[Starfox]

I never said you can't get Bullet's current debug drawer to work under buffered modes - I already have it working under OpenGL 3.2 Core and another internal API with both offering no immediate mode facilities. It's that the amount of function calls and cache thrashing that can be avoided using a batch interface is non-trivial, and such batch interface can be implemented without breaking existing code by having the batch drawLines() method have a default implementation in the base debug draw interface that just forwards these calls to the current drawLine() method. I have scenes with dense triangle meshes that are just murder on the function call front.

[MaxDZ8]

Fetching dense meshes to physics? Don't do that.
I still believe debug mode is sufficient. I never profiled it I admit. It just isn't hot code. It's a debug facility which is basically never run for real. Even if it takes 1 minute I'd rather have it spent on other things.

That said, with bullet 3x going massive I suspect we might see some improvements. Rather than having drawtriangles though, I'd be much more interested in intercepting mesh draw calls directly.

[Starfox]

Rather than having drawtriangles though, I'd be much more interested in intercepting mesh draw calls directly.

This.