solved Debug - Physics Collider

[ian]

Does Debug/Inspector has opstion to show colliders in scene?
Is there any plan to add this options to see how meshe's colliders are aligned?

Or is there any javascript function which can enable or allow this capability?

Greetings

Ian

[Gijs]

11 minutes ago, ian said:

Or is there any javascript function which can enable or allow this capability?

I know of @davrous' "very ugly UI":

https://gamedevelopment.tutsplus.com/tutorials/webgl-physics-and-collision-detection-using-babylonjs-and-oimojs--cms-24114

It's at #6

[ian]

aha (set visible)  collider box (if they was inistialize as hidden)

This is fine exajmple (but if we have options in debug/inpector to show each collider as visible/hidden it will be a great thing.
I look all inside inpector and I don't see any physics options to show colliders.
I would like to know their positions rotation and scale. 

What happpen to colliders which are "Apply Object transformations - blender" so that rotation/scale became zero?
Should we "apply obejct transforamtions" over box colliders or not? 
What exactly apply object transforamtions to?
Can anybody explain it? Where/why to use it and where/why not to use it (I meen apply object transformations)?

 

greetings

Ian

[Wingnut]

Hi again, Ian, good to see you.

https://blender.stackexchange.com/questions/7298/why-is-it-important-to-apply-transformation-to-an-objects-data

There is some info there... about when/how to use Blender Apply Object Transformation (A.O.T.)

I am no expert in Blender, but there are many tutorials on the web.

--------------------

On the "visualize physics impostors" subject, there is no mesh.showImpostor(), yet, as far as I know.  MANY PEOPLE have asked for it, but nobody has found/coded the way, yet.

For the OTHER collision system (mesh.ellipsoids/moveWithCollisions)... there is some work underway for mesh.showEllipsoid (lines 2-33).  That's not physics/impostors, though.

Perhaps YOU will begin work on mesh.showImpostor() ? 

Ian, are you having some problems with impostors not being aligned with mesh shape?  We are seeing this problem in some other demos, too.  We're looking carefully at some recent changes made to boundingBox, but the search continues.  Currently, in this CannonJS heightMapImpostor demo, I see boxes resting/sleeping on their edges (after all movement is stopped).  Strange. 

PhysicsImpostor.physicsBody DOES HAVE .position property, and a .quaternion property for quaternion rotation values.  If the framework's physics plugins are working correctly, they will create an impostor body that is exactly the same size as the shape.  But is it scaled, rotated, positioned, origin'd, and pivotPoint'd exactly the same as its "assigned" shape mesh?

Difficult to know, without seeing the impostors, right?  *nod*. 

But you can assume that the impostor is sized correctly (if shape mesh is un-scaled), and you can "read" impostor body .position and .quaternion values from the physics body.  SO, in theory, you should be able to make "another" shape (a ghost shape or impostor token) identical to the impostor/body shape.

Don't give the ghost mesh a physicsImpostor.  Just keep it a regular mesh, but maybe set .visibility = .5, or perhaps wireframed.

Next, in renderLoop, continuously set the ghost mesh rotationQuaternion and position... from values gotten-from the real shape's impostor/body.  Constantly read impostor body .quaternion and .position, and copy them onto ghost shape.  Make the ghost mesh precisely track the impostor's orientation/position. 

Careful here.  CannonJS might have Z-axis as vertical axis.  That is true with CannonJS heightMaps, so it might be true in other CannonJS areas, too.

DO NOT parent the ghost mesh to the original shape mesh.  That is cheating, and it could give you false-oriented ghost-mesh display.  You MUST get ghost-shape orientation data FROM the real shape mesh impostor body... continuously, in the renderLoop.  That way, the ghost shape is always showing a representation of the impostor.  It is "hard-wired" to the impostor/body.

Now you have created your own mesh.showImpostor(), yes?  Having it ON... will likely slow-down the physics speeds somewhat.

Of course, your new .showImpostor() would need to determine WHICH TYPE of impostor is being used.  If it is a boxImpostor, your ghost mesh will be a box.  If sphereImpostor, your ghost will be a sphere.  If CannonJS meshImpostor or heightmapImpostor, your ghost must be a perfect clone of the complex mesh or heightmap terrain (potentially MANY extra verts added to the scene).

Perhaps someone else will have time/expertise to code mesh.showImpostor(), but our power programmers are really busy right now.  If YOU could code-up a basic mesh.showImpostor()... just like we did with mesh.showEllipsoid(), that would be a great start.  Show it to us in a simple playground, and then perhaps other programmers will help us test its precision and find problems if there are some.

Can you (and/or others) create the first ever mesh.showImpostor()?  If it works really good, then I know admin would consider it as a debugger feature.  It would be a very handy thing to have.  We would need to make it available for Cannon or Oimo.  There are significant differences, but the new showImpostor() CAN BE made cross-physicsEngine-able. 

Can you assist us, or spearhead... the development of this new feature?  That would be great.

[ian]

OK, I add some .blender file Like example.

So Path=Model is mesh (rendered). And all Cube.* are boxes like box collidners/impostors (they are invisible hidden meshes).

If we load this model with impostors(Cube* like box impostors). All Cubes* meshes has origin in center of its mesh. This must be so for physical imposotrs!

Should we set all Cubes* meshes as Quaternion in blender or can we live them as Auler XYZ?

Should we (Blender Apply Object Transformation) over all Cubes* ? Or should not? Why?

Now it is possible to meke all Cubes* as box colliders and as children of Path( rendered mesh ). 

If you Imagine that we load this Model and Cubes* as child. And if rotate Model freely and all cubes( intended as calendars) and child of Model.

How should Cube* meshes be set up (expecially scale and rotation ?? should we use Blender Apply Object Transofratnion (scale and rotation) ?? ) or should we not use (Blender Apply Object TRansforamtion) on all of Cubes* meshes ?

Greetins

Ian

AskModel_Colliders_Rotation_Scale.zip

[Wingnut]

erf... complicated blender scene.  Sorry, I can't answer anymore.  Maybe others will understand.  I wish we had SIMPLE .blender file (5 boxes) and playground test.

Let's ping @JCPalmer and @gryff... see if they have comments.  Perhaps someone else knows more about AOT.  Perhaps it is similar to BJS bakeCurrentTransformIntoVertices().

If you make simple 5-box Blender test scene, you could try BOTH ways.  AOT/not AOT.  Make .babylon file for both.  Inspect differences, perhaps in online JSON viewer.

And yes, export Use Quaternions is good idea... when using physics engines.  (I think so.  Physics engines love Quaternions)

I like positioning everything with JS/BJS... and don't care what Blender does, as long as it delivers models to scene.  Once in scene, then move, rotate, set impostors, setPivotPoints, adjust child/parenting, all in JS.  Easier.  More power.  If all mesh have position 0,0,0 after import... so what?  I will be placing them with JS.  I just want the models imported. 

Hopefully, smarter people than I... will comment soon.  Sorry I am not helpful.  I have low experience in these things.

[JCPalmer]

If you using the mesh in a skeleton, you must apply scale transforms prior.  In fact, I got tired of forum problems with skeletons, so I actually check in the case of a mesh with skeleton and blow the export up when found.

I know little about collisions, but from a sanity point of view I always apply transforms.  So whatever they import as scale is 1 & rotation is 0.  I could then just set either rather than add / subtract.  Dragging that info across, while it works, makes no sense.

[ian]

No I do not have skeleton here !

I just want to know what happen with impostor-collider of Cube/Box. (We don't have options to see how hidden impostor-collider of visible mesh Cube/Box.)

Sometimes box impostor-collider is not same as cube/box. I know that we should not change origion of Cube/Box, If we move origin of Cube/Box then box-impostor-colider is not the same as visible Box/Cube !

It will be realy good to add options in inspector/debugger which will allow us to show all impostors of mehes if meshes and impostors are aligned ok or not. If we rotate/scale/move mesh around it will be good to see if impostor is at same position as its mesh and if it is scaled and rotated as visible mesh.

So if we  create Cube/Box (visible mesh) and than if we move around and rotate it around and scale it in blender.  
Should we at the end set this box Apply Object Transformation? (when we should not use this?)
 

greetings

Ian