Better physics debug view added to Engine

Hey,

the physics debug view was not very good and it also messed up some dependency trees in the bullet implementation. It was introducing Spatials to the base physics objects which should not really need to know about anything but jME math. Furthermore the debug view showed only physics objects that were actually being used with spatials and controls, giving the impression that removing a spatial does remove the physics object as well (because its debug shape is not rendered anymore). Finally it used an ugly way to render the debug objects and it did not display a see-through wireframe like most debug views do.

All that has been cleaned up now :slight_smile: The debug happens in a separate AppState that constructs a debug view directly from the PhysicsSpace data. So all objects that are in the physics space show up and I can even add things like display of forces and other things later easily…

For the user nothing much changes, PhysicsSpace.enableDebug(AssetManager) has been deprecated in favor of BulletAppState.enableDebug(boolean) which attaches the needed DebugAppState automatically but the old method still works. While I was at it I also made the PhysicsSpace avoid double-adding/removing mistakes by the user by checking if the object was added already.


Cheers,
Normen

11 Likes

You’re on a roll :slight_smile:

As always, good work normen =)

Good work !

I wonder if it is possible to enable debug shapes only for a subset of geometries ? For example, only a collision group… or object per object.

yeh wicked! :slight_smile: debugging in physics is always required, glad to see the shapes improved! although they were already pretty good :slight_smile:

also when do you sleep? :open_mouth:

Thanks :slight_smile: Forgot to add, I also added an AbstractPhysicsControl so you can easily implement your own PhysicsControls to manipulate spatials now while having the same lifecycle as the other PhysicsControls (remove from physics space on disable etc) :slight_smile:

Edit: Also updated the physics docs in the wiki a bit, especially the overview:
https://wiki.jmonkeyengine.org/legacy/doku.php/jme3:advanced:physics

1 Like

Thanks for the improvements.

Do you know if it’s working on Android correctly now ( see http://hub.jmonkeyengine.org/forum/topic/physicsdebuggeometry-drawn-solid/ ) ? I can test this in the coming days if you haven’t done this.

The android “filled quad” issue is a material/display issue, I guess wireframes generally don’t work on Android.

@yang71 said: I wonder if it is possible to enable debug shapes only for a subset of geometries ? For example, only a collision group... or object per object.
Sorry, missed this. Well, in theory its possible now as theres a separate scenegraph for the debug display but its generated on the fly and theres not really a good way to access or separate it built in. I could add something to go debugAppState.getSpatialFor(PhysicsRigidBody) so you can then setCullHint(always) for example.. But you would have to do that for every PhysicsRigidBody, PhysicsGhostObject, PhysicsCharacter, PhysicsJoint and PhysicsVehicle separately.. :)

Maybe a filter interface on the physics stuff?

So you can do debugAppState.setDebugFilter()…

And then the interface just has a shouldShowDebugFor(PhysicsRigidBody prb);
etc.

Would basically sum up to the same amount of code for the user, wouldn’t it?
The content of this post is meant to be read as a straight information or question without an implicit dismissive stance or interest in having the other party feel offended unless theres emotes that hint otherwise or theres an increased use of exclamation marks and all-capital words.

No, since you can just implement generic rules in your filter. For example all objects called “bob*” get shown or all rigid body only, etc.
Rather than having to parse through the scene graph and then decide what to call for each object you just implement the filter and set it.
It also copes with new objects being added/removed/etc without needing to go through and reparse all the time.

Maybe we should keep it simple… Do not forget that debug shapes are only for debugging.
Implementing a full regexp matching is interesting, yes, but is it worth the burden ?

I really think the proposal of @Normen, (de)activating just one control at a time, may be sufficient. After all, most of us simply activate the whole thing or not at all.

Cool Stuff, however @zarch idea is really interesting…it’s justly for debugging…it will be really useful if we could only track characterControl without all the big overlapping ghostControl for example or a particular collisionGroupe like @yang71 said. When we have a lot of physics objects it quickly becomes ugly, and so hard to track for our eyes.

@yang71 said: Maybe we should keep it simple... Do not forget that debug shapes are only for debugging. Implementing a full regexp matching is interesting, yes, but is it worth the burden ?

I really think the proposal of @Normen, (de)activating just one control at a time, may be sufficient. After all, most of us simply activate the whole thing or not at all.

Who said anything about regex? It’s just an interface - people can implement whatever they want in the interface. All the framework has to do is call it if it exists.

@zarch said: No, since you can just implement generic rules in your filter. For example all objects called "bob*" get shown or all rigid body only, etc. Rather than having to parse through the scene graph and then decide what to call for each object you just implement the filter and set it. It also copes with new objects being added/removed/etc without needing to go through and reparse all the time.
Like I said its about the mentioned objects, they don't have names or anything they can be identified by apart from the object link to the spatial (if thats there). So I guess finding that RigidBody or whatever will always boil down to being able to directly reference it. Also thee easiest filter is your eyes, just don't look at the object in question. I never saw such a separated debug mode in general though, its kind of strange to only observe the object that collides and not those it collides with. At any instance both is easy enough to implement so I'll probably go for the filter interface, then people can create these themselves. It should even be a bit easier. The content of this post is meant to be read as a straight information or question without an implicit dismissive stance or interest in having the other party feel offended unless theres emotes that hint otherwise or theres an increased use of exclamation marks and all-capital words.
1 Like

Sorry, I misunderstood what you said. In fact I read it too fast. (Speaking of Zarch post)

The debug display now changes the color of RigidBodies when the “active” state changes, so you can see which of your physics objects go to sleep:

I also experimented with display of forces but I think I will not add that for now even though it would be a simple change, I simply think theres not much information to be gathered from these arrows… If the thing moves its got a linear velocity, if it rotates its angular… Nothing much to read from the vectors in the display, they look kind of pretty though :wink:

4 Likes

I might actually jizz everywhere, too many awesome changes! Slow down normen, I can’t keep up!

I suspect normen either
a) got rid of a girlfriend
b) lost his job
c) somehow invented a way to double the 24 hours of a day

=P