Imported Model and generatingGeometry

Troubleshooting physics
1

So I have my model built, with a minimum of vertices (only 108 here), with the idea that I could use the mesh itself as the physics object.  However when I use generateGeometry( true ) the volume seems to collapse to zero.  When I use generateGeometry( false ) a physics bounding box does show up in the correct manner.



Here is a screenshot using false…

 







Here is a screenshot using true…

 

(I circle the TINY green crosshair, in the same position as the previous pic, in red)









Also notice that the center of mass seems to be at (0,0,0) in both pictures.





here is the code I am using



    private Node getSlate() {
        Spatial model = getModel( "/className/models/Table_Model/model.obj" );
       
       
        StaticPhysicsNode modelPhysics = jme_Driver.getPhysics().createStaticNode();
        modelPhysics.setName( "slatePhysics" );
        modelPhysics.attachChild( model );
       
        modelPhysics.setMaterial( tableMaterial );
        modelPhysics.generatePhysicsGeometry( false );
       
        return modelPhysics;



I have also tried creating a physicsMesh and adding the TriMesh directly to it.  But the physics bounding box shows the same 'collapsed volume' using both true and false for generateGeometry().  Which makes me think the problem might be with the model... but I have no idea  :|

2

TriMesh physics geometries are not visualized! So everything might be fine.

3
TriMesh physics geometries are not visualized! So everything might be fine.

Oh dang! Thats good to know.
4

HaHa, I had the SAME exact thought as I went to sleep :slight_smile:





However, the trimesh physics don't work. 

Using generateGeometry( false ) --> balls collide with table when dropped

Using generateGeometry( true ) --> balls fall through with table



I am going to set up a collision callback to test the physics, but I don't think the callback is going to even fire



:expressionless: :expressionless: :expressionless:

5

Yup, just as I thought



Using generateGeometry( false ) --> contact listener fires correctly

Using generateGeometry( true ) --> contact listener never fires





So does this mean that the geometry is not getting computed correctly??



I have also tried the Maggie.obj model and that one works correctly.



So the problem MUST be in my model,  but I have no idea what it could be.



Arggh  :?

6

Hmmm,

puzzling…



when this line is added

modelPhysics.setActive( true );



the physics are correct,  but why do I have to do that with ONLY this one model?!?



I have tested a couple of other models from blender and they work fine.



Could it be, because this one has 2 open faces out of 6??

7

setActive(true) should not be needed. Can you provide a short test case?

8

Thats a bummer, it's such a powerful and easy technique for OpenGL but I suppose your right since I can't get the graphics model normals correct either (for mirrored meshes).



Oh, well I will just remodel in halves I guess, the complete model should still come in under 500K :D.





What about reading the model in multiple times, would it be more efficient to instantiate meshes from the first instead?

9

Hmm,  I must have done something weird before, cant seem to replicate now.



However one of the changes that I did make was to import the model twice, once for the graphic model and again for the physics (is this very efficient?).  After that a lot of my issues went away…



I was then able to scale by a negative value successfully (other post) but I get this issue





The red line is where the model is copied and mirrored (scaled by -1 on the z axis)

Left: Normal model

Right: Mirrored model



The balls to the right of the line are exactly in the middle vertically as shown in this image





I would like to keep the model as a quarter of the actual one but I think scaling the physics mesh by negative values is bad juju.

10

yep scaling with negative values in not a good idea (not only for physics).

11
basixs said:

would it be more efficient to instantiate meshes from the first instead?

sure
12

So after re-doing my model the TriMesh physics don't work :slight_smile:






        StaticPhysicsNode physicsModel = jme_Driver.getPhysics().createStaticNode();
        physicsModel.setName( name );

        model.setModelBound( new BoundingBox() );
        model.updateModelBound();
       
        SharedMesh originalMesh = new SharedMesh( name, (TriMesh) model );
       
       
        System.out.println( "SharedMesh verts: " + originalMesh.getVertexCount() );
       
        PhysicsMesh rotatedMesh = physicsModel.createMesh( name );
        rotatedMesh.copyFrom( (TriMesh) model );
       
        rotatedMesh.setLocalRotation( new Quaternion().fromAngleAxis( FastMath.PI, Vector3f.UNIT_Y ) );
       
        System.out.println( "PhysicsMesh verts: " + rotatedMesh.getVertexCount() );
       
        physicsModel.attachChild( originalMesh );
        physicsModel.attachChild( rotatedMesh );
       

        physicsModel.attachChild( model );
       
       
        physicsModel.generatePhysicsGeometry( true );
        physicsModel.setActive( true );
       
       
        System.out.println( "Total verts: " + physicsModel.getVertexCount() );
       
        return physicsModel;



Output:
SharedMesh verts: 216
PhysicsMesh verts: 0
Total verts: 216

So, physicsMesh doesnt seem to have any verticies and the sharedNode only works when  is used generatePhysicsGeometry( false ).
When the model is set to just a Box, then everything works great; generatePhysicsGeometry( true) and the PhysicsMesh.

ANY pointers as to what might be my issue would be very appreciated, BTW I am using an OBJ model from Blender.
13

generatePhysicsGeometry does not work with shared meshes, yet. Use PhysicsNode.createTriMesh and yourPhysicsTrimesh.copy(originalMesh) instead.

14

I am not seeing a createTriMesh() method, just createMesh() under StaticPhysicsNode and DynamicPhysicsNode.  Which I am already using :slight_smile: and doesn't seem to want to work properly.  The physics from pMesh.copyFrom( model ) don't work no matter if generateGeometry( false ) or  generateGeometry( true ) is used.  However, If I add the spatial directly to the StaticPhysicsNode then generateGeometry( false ) works but not generateGeometry( true ).



        PhysicsMesh rotatedMesh = physicsModel.createMesh( name );
        rotatedMesh.copyFrom( (TriMesh) model );
        rotatedMesh.setLocalRotation( new Quaternion().fromAngleAxis( FastMath.PI, Vector3f.UNIT_Y ) );
       
        System.out.println( "PhysicsMesh verts: " + rotatedMesh.getVertexCount() );



Hmm, but it always reports 0 as the number of verts no matter what the spatial, so I guess thats not a good test.

frustrated....

The hardest part of this issue is the lack of feedback (visual, number of points, etc) breakpoints don't even help me out.
15

So does the pMesh have to be manipulated (scaled rotated) separately from it's parent node?  I was previously getting model -> adding Graphic meshs -> adding physic meshes -> manipulating.



When I manipulate each mesh separately before adding to the model the physics are correct.  :expressionless:

16

I meant to refer to createMesh, yes.


basixs said:

The hardest part of this issue is the lack of feedback (visual, number of points, etc) breakpoints don't even help me out.

yes, it's a pitty - sorry about that, I didn't take the time to visualize physics trimeshes :|  (patches welcome as ususal ;))

basixs said:

So does the pMesh have to be manipulated (scaled rotated) separately from it's parent node?

yes!
And there seems to be a misconception with generateGeometry:
- generateGeometry calls create* methods and transforms the created geometries appropriately
- create* method do not transform anything
- if you use create* directly you should not call generateGeometry
17

OOOOHHHHH!



You know now that you said that I took anouther look at testTriMesh() and realized thats exactly what you were doing there…



I guess I'm just dense sometimes.







Thanks so much for all your help and hard work, in fact that goes for the entire jME team; you guys truly rock :D.



BTW. this is one of the most civilized forum I have been to, kudos there also.