Impostor bigger than the mesh after scaling

[Wingnut]

Hi guys.  Sorry to butt in.  Thx for all your good troubleshooting.

Dad72... about float-above-ground place...  let's call it "float height".

If you raise model much much higher, does model drop to previous 'float height'?

Does it act like there is invisible ground above real ground?

Can you applyImpulse on side, and tip-over the model?

Or maybe invert model, and drop from higher?  Any changes seen?

If you could guess, would you say ground impostor too high?

Or mesh impostor too low?

Just curious.  Only answer if you are not busy.  (thx)

[Dad72]

Hi Wingnut,

Yes, if the model goes higher to drop it, it's the same thing.
One could say that there is either a higher ground or an impostor of the model too big or shift. I am unable to tell if one or the other. It may be both.

For the impulse you can try on the demo of the cube (use http to see it.)

I try a lot of things, many models too and it always makes me the same thing. with the same model it does not create this problem 1 years ago, so there is a bug today well hide I think.

All models export with 3ds max seems to have this problem today (even with models export a long time ago, so it's not 3ds max, but something in Babylon because I have the same bug with CannonJS and OimoJS).

 

[Wingnut]

  I removed your recent post, P8.   It looked un-loved. 

Thx for info, D72.  Um...

I noticed strange thing, recently.  Might be normal.

https://www.babylonjs-playground.com/#1ND6TH#90

Pink and blue little boxes (lines 612-642 - called ghost1 and ghost2) are ATOP each other... because...

joint1b (lines 659-671) is set mainPivot and connectedPivot 0,0,0.  It is the joint that lives BETWEEN ghost1 and ghost2.  (ghost2 hangs-from ghost1... via joint1b)

Ghost1 and 2 are currently size 1, 1, 1.

In line 613, change height to .1
In line 629, change height to .1

RUN (for your lives)  hehe.

Notice how it APPEARS that we changed joint1b mainPivot and connectedPivot positions, but we did not.

Something seems wrong, there, too.  Making shape/impostor smaller... should not affect joint1b pivot positions, perhaps.  *shrug*

Just reporting strange things... but could be Wingnut screw-up.    Not sure.

[Dad72]

If I understand correctly, you think that it is the pivot of the impostor who is shifting compared to the model?

I made a test to verify this : 

I use a box made with 3ds max and a box made with Babylon. The box of Babylon enters the box made with 3ds max of the depth which is missing between the ground and the box.

So it means that the impostor is offset with respect to the object. The object does with Babylon its correct, but those export with 3ds max (I do not know to blender) the impostor is offbeat.

http://www.babylonjs-playground.com/#GA8XI#99

@RaananW I think you will better understand the bug on this PG, we can see the offset of the impostor. This happens after you scale the export object.

[Wingnut]

17 hours ago, Dad72 said:

If I understand correctly, you think that it is the pivot of the impostor who is shifting compared to the model?

Not sure.  It appears SOMETHING happened when ghosts changed size.  Even with size .1, .1, .1, (or down-scale them 90%)... the two ghosts SHOULD be atop each other, I think.

Ghost size .01, .01, .01 is size I need them to be...  for the human hip project.  At that size, my box impostors go crazy and out-of-control, which is NOT expected. 

There seems to be FAR too much vertical space between ghost boxes, (between joint1b main/connected pivots) when ghost boxes are real small.  This matches YOUR discoveries/claims, somewhat.

My only limp deduction:  Boxes with size < 1,1,1 ... are making joints act strange on Y-axis. 

Yes, possible pivot-point/impostor-origin issues for down-scaled or small shapes.

I'm glad you were able to find a PG that shows issue.  That's good progress.  Failed for me, though.  Blocked loading mixed active content “http://www.babylon.actifgames.com/anim/house/box.babylon”  *shrug*   I made another one, using your file.  This one works for me.

Previous BJS versions work better, Dad72?   How about previous Max Exporters?

[Wingnut]

https://www.babylonjs-playground.com/#GA8XI#103

New tests.  Same issues.

I had theory that .setScalingUpdated(true) was NOT working while mesh was falling.

So I tried various delays and re-lifting.  No improvements seen.

Notice that the little Babylon-made box... NEVER needs .setScalingUpdated(true).   I do 50% down-scale of little BJS box in line 52.  Little BJS box still hits ground fine.

3D Max mesh (longer box)... not doing as well.  Lines 37 and 65 might not work at all.

Strange things seen at console.  Look at mesh.position.y and mesh.physicsImpostor.physicsBody.position.y  (lots different)

Now disable line 34 (set mesh 100% scale).  RUN. 

Look at console numbers again.  Weird!  I don't understand Y, but there is something Y-strange, there.    hmm. 

Too much diff between mesh.pos.y and physBody.pos.y... me thinx.

[Wingnut]

More: 

https://www.babylonjs-playground.com/#GA8XI#104

It just gets weirder.  We have sunk.   

In line 28, I Y-inverted the 3D Max-imported mesh (make it be upside-down).  I will let others choose to bake that rotation, or not.  (line 29)

Ok, when mesh upright, we have 25% float issue.  When mesh inverted, we have 75% sink issue.  *scratch scratch*

Just for fun, disable line 25.

RUN!  We're floating again.  Hmm.  What the heck is line 25's problem?

I tried:

Line 25:  mesh.rotationQuaternion = new BABYLON.Quaternion.Zero();  (serious problem)
   or
Line 25:  mesh.rotationQuaternion = new BABYLON.Quaternion.Identity();  (no change seen)

What the heck?  heh.  Why is that Quat involved? 

Why did the mesh.rotation change things?  (inverted mesh)

Another oddity:  When typing mesh.bakeCu... normally... playground intelli-sense helps with completion.  For our mesh object, playground does NOT provide intelli-sense choice for .bakeCurrentTransformIntoVertices().  The playground THINKS... mesh is not a standard BJS mesh.  Maybe intelli-sense is not smart enough to KNOW that mesh is a BJS mesh... because it was imported.  OR, something else.

According to my sucky new Firefox 57 object inspector, .bakeCurrentTransformIntoVertices() is not available on our 3dMax-imported mesh.  hmm.

I hope a professional steps-in soon, before Wingnut gets lost in the woods.    I'm beginning to feel disoriented.  Fun tests/riddles, though.

[Dad72]

19 hours ago, Wingnut said:

Previous BJS versions work better, Dad72?   How about previous Max Exporters?

It is not the export that creates the problem, because I have a model that I export from old version that produces today the same problem.

I think it's in Babylon's plugin, the impostor is not resize properly. its pivot is no longer in the center of the object I imagine when it is redimentionner.

Thank you for your tests and confirm the problem.

[Wingnut]

*nod*.  But... plugin might cause same problem for BJS standard box, though.  No problems seen... with BJS basic box. 

Also, no re-dimension done.   In theory, if .setScalingUpdated(true), plugin installs NEW impostor.

Maybe Blender import has same issue.

Perhaps problem is with de-serializer (mesh loader/installer).  hmm. 

Sorry for so much talking in your thread, D.  I am slow at making progress. 

[Dad72]

27 minutes ago, Wingnut said:

Perhaps problem is with de-serializer (mesh loader/installer).  hmm. 

Yes it is possible, it can be a lot of things. this bug is very sneaky. 

[Wingnut]

https://www.babylonjs-playground.com/#GA8XI#105

I started new playground version.  Oimo plugin and BJS physicsImpostor... inside playground.

Some annoying console reports are inserted by me.  I am checking .setScalingUpdated(true)... making sure forceUpdate is called... which calls _init (makes new impostor for scaled mesh).  setScalingUpdated() near line 206.  ForceUpdate() near line 214.  _init() near line 181.

So far, so good.  Not much learned, yet.  I am building a big and ugly PG experimenting laboratory.  heh.

Aside:  Is Babylon GUI an extension, now?  If not, who votes-for mesh.showBoundingInfo = true; ?     mesh.getBoundingInfo().boundingBox.whatever... is SO MUCH TYPING.    Or perhaps... .showBoundingBoxWithValues = true?  heh.  Maybe Babylon.Tools.Measure(mesh, x) ?  Or how about mesh.span(x) -> returns length of mesh bbox x-axis. 

Wingnut - professional bad-idea consultant. 

[syed samoon]

i'm also facing this same issue.

 

if anyone have solution for this??

 

[syed samoon]

if i use to export the model in blender. is this same problem will be occur?

[Dad72]

@RaananW is on it, he should fix it soon. I think the problem this will also produce on blender but I did not try.

[RaananW]

PR submitted, there was a missing scaling factor when calculating the mesh's delta position.

[Dad72]

I see that it refocuses the imposter in relation to the pivot, but if the pivot is not in the center of the object, it will work? for example a door has its pivot at the hinges.

[RaananW]

This is done since a physics engine has no understanding of pivot points of the mesh itself. a physics engine is always under the assumption that the object is centered. If the object is not centered then it will have a problem placing it correctly.

It has nothing to do with the pivot points of joints and so on, this is a completely different thing.

[Dad72]

Ok, ok, thanks for the information.

[Dad72]

Ok, it works with the fix. Thank you

[Wingnut]

23 hours ago, RaananW said:

a physics engine is always under the assumption that the object is centered.

Interesting statement (thx).  And thx for fix, too, R-man.  I still need to check the PR and see exactly what you did.... so I can learn.

Damn, I REALLY need "Quick Flowcharts/Diagrams" BJS GUI "behavior" system, to help me illustrate something, here. 

Let's see, in BJS basic shapes, origin == pivot point, yes?

So, if a basic mesh offsets it's PP/origin, is the impostor also created with an offset PP/origin?  (I guess I could test it... geez I'm lazy)

hhmm... I don't know if physics engines "query" the standard BJS boundingInfo in order to create the correct impostor size/centering, or if it does it's own measuring of the shape, internally.

I need to learn learn learn.  But, if the physics engine DOES use our BJS boundingInfo... to do it's impostor-sizing... then... what?  We can "hack" the mesh boundingInfo BEFORE adding physicsImpostor, and "fool" the physics engine into making ANY size impostor for our shape. 

And if the physics engine uses OUR boundingInfo localCenter (or offset origin/PP) to determine where to put ITS new impostor's center/pivot... then... we can fool the impostor generator (actually, physicsBody generator), there, too. 

I think the physicsEngine does its own measuring, thus not dependent upon any boundingInfo provided by frameworks.

I better go study, before I talk out-of-my-butt any further.  AND, I'm off-topic.     Wingy hi-5's Dad72's player character for finally having his feet on the ground.  Change to stable to see pre-repair version.  PARTY!

[RaananW]

1 hour ago, Wingnut said:

Interesting statement (thx).  And thx for fix, too, R-man.  I still need to check the PR and see exactly what you did.... so I can learn.

I just realized I wrote a bit too abstract  it should have been - "The physics engines we are using are" instead of "a physics engine is". I can only assume other physics engines do support pivot positioning of meshes.