Ammo Debug Draw

Made a little class that helps to draw the Ammo physics world for debugging.
Also shows how to use PCUI.


Thanks a lot for making this! :grinning:

This could be really useful for people who don’t use the editor.


Super nice code and fun to play with! :sweat_smile:

I turned this all into a standalone repo for testing/comparing the same functionality in ES5 and ES6:



ES6 demo is not fully ES6 tho, e.g. PCUI has no official ES6 build yet, so its mixed ES5/ES6, waiting for this:


As this is like one of the only examples I know which demonstrates non-trivial use of PCUI, I wonder how “correct” it is as a role model:


Is this the code PCUI wants to encourage:


This feels kinda overly complicated to me and should be rather this?


perhaps @Elliott has some thoughts on this?

1 Like

I figured out yesterday that the Debug Draw Layer didn’t work as it used to work and @LeXXik updated the project now. Yet the update is introducing another bug, which I also have in my repo for drawing debug lines, which comes up when you scale the screen to a small width:

Anyone knows why this happens?

Are the two cameras affected in the same way when resized? I don’t think the layer changes are the problem on this one.

Are you using the orbit camera script from the model viewer/tutorial? If so, this is set to true/false pending on the window size


Thank you, @yaustar! Yes, the culprit was the orbit-camera script. This is fixed.


I think you fixed it by just commenting out fov code:


However, anyone has an idea what a nice solution would be considering the _checkAspectRatio method is actually useful? Maybe OrbitCamera should have a child cameras attribute for the case of having debug layers and iterate over all those cameras.

Or the file could contain an AspectRatioCheck script which could be attached to main and debug camera at the same time.

Yep, it was enough for the purposes of the sample project. That orbit camera script is not related to Ammo Debug Draw, so it was enough to simply comment it out in this example, as it fits the purpose.

As for the orbit script, not sure what would be the best way to handle this. Adding a children scan may work, but then it adds an overhead as it is run each frame. Perhaps it could be acceptable, considering the script already adds some.

I would probably update the children but only when there’s a value change to the FOV property on the main camera. Or change it so that the debug camera matches the settings of it’s parent and has listeners for the properties? Either way it’s pretty tricky to keep track :thinking:

What was the issue on having all the layers on the same camera?

The lines were occluded by the objects, regardless of where the debug layer is in the layers composition. Having a second camera makes them render on top of everything.

I wonder if you can use the same layer as the renderLine as I believe that renders on top of everything?


Ah, checked the renderLine sources, it sets the depth test to true by default. That was the reason the lines were occluded. Fixed.


  • Use a single camera for all layers
  • Revert changes made to orbit camera