Better physics debug view added to Engine

Home Forum Development Engine Development Discussion Better physics debug view added to Engine

This topic contains 27 replies, has 8 voices, and was last updated by  Normen Hansen 1 year, 7 months ago.

Viewing 15 posts - 1 through 15 (of 28 total)
  • Author
    Posts
  • #203672
    +11

    Normen Hansen
    2778p
    Keymaster

    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 :) 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

    #203675

    zarch
    690p
    Keymaster

    You’re on a roll :)

    #203678

    kwando
    264p
    Keymaster

    As always, good work normen =)

    #203684

    Laurent
    83p
    Participant

    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.

    #203685

    Wesley Shillingford
    833p
    Participant

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

    also when do you sleep? :O

    #203687
    +1

    Normen Hansen
    2778p
    Keymaster

    Thanks :) 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) :)

    Edit: Also updated the physics docs in the wiki a bit, especially the overview:

    http://hub.jmonkeyengine.org/wiki/doku.php/jme3:advanced:physics

    #203747

    Vortex
    26p
    Participant

    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.

    #203750

    Normen Hansen
    2778p
    Keymaster

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

    #203754

    Normen Hansen
    2778p
    Keymaster

    @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.. :)

    #203756

    zarch
    690p
    Keymaster

    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.

    #203759

    Normen Hansen
    2778p
    Keymaster

    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.

    #203798

    zarch
    690p
    Keymaster

    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.

    #203808

    Laurent
    83p
    Participant

    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.

    #203814

    haze
    64p
    Participant

    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.

    #203815

    zarch
    690p
    Keymaster

    @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.

Viewing 15 posts - 1 through 15 (of 28 total)

You must be logged in to reply to this topic.