Sphere.physicsimpostor.registeronphysicsCollide function not workin in visual studio

[Abdullah]

Hello Everyone.. hope so everyone is fine. 

Actually i want to check the collision of two imposters and i am using this code below.

  sphere.physicsImpostor.registerOnPhysicsCollide(floor.physicsImpostor, function (main, collided) {
                main.object.material.diffuseColor = new BABYLON.Color3(Math.random(), Math.random(), Math.random());
            });

it is working too inconsistently in my code. sometimes it change colour and sometimes not...!!!  
i don't know whats the issue. So kindly help me out..

Thank you...!!!
 

@Wingnut @Dad72 @getzel .... any help please??? 

[Wingnut]

Hi Abdullah.  I'm not a VS user, and I have never monitored physics collisions in that way.  But, you know how it works around here.    Please create a simple playground demo that reproduces this issue.   Then it is easier for all of us to help.  Thanks.

Aww heck, I'll make one for us.  http://www.babylonjs-playground.com/#1AAQUN#21

The time step value in line 27 is likely important.  And yes, I see some "misses", where the sphere collider function does not trigger.  But perhaps I am seeing happenstance repeating random colors, instead.  Not sure.)

I'm not sure there is anything that can improve it.  JS-based physics engines have some inconsistencies and "slop".  I think it is because computer physics needs to run REAL fast, for the most-accurate reproduction.  JS does not run real fast.  But I'm speculating.  Watch the sphere carefully, and you will even see inertia/energy inconsistencies and anomalies, where energy is ADDED to the sphere bounce.  Not perfect, and I'm not sure why.

It is likely we will see physics engines built-into the hardware of future consumer-grade computers.  That will be a wonderful day, but then we will push them harder, and find more inconsistencies, I suppose.  ie. "Why won't the colors change on ALL 1000 bouncing spheres?" 

We have a playground example, now, so others can test easier, and comment.  Let's see what others have to say. 

Addenda: Here is an OIMO playground where the author used a world object (line 29) and then "stepped" the physics within the render loop (line 125).  Not sure what THAT is about.  Cannon has a world object, too... but there is no step() func on Cannon's world.  Both Cannon and Oimo are 3rd-party apps, essentially not part of BJS.  We could use more experts, so teach us things that you discover, okay Abdullah?  (thx)

[Abdullah]

hey @Wingnut... thanx for your reply first of all...
now i think the issue is that in my main index.html file.. i am doing so many things like mesh loading and collisions and keyEvents etc. 

so i think this is the issue that collision function is not working very consistently...  

i just make one file separately in separate project in visual studio.... and then i just put one ground and one sphere in that and that works very fine.. 
so may be it is a issue of threading.... means in one thread physics engine is not able to do all that things.... 
these are my point of views... i need yours..

[GameMonetize]

Hey @Abdullah! can you reproduce the issue in the PG?

 

[Wingnut]

Hey @Deltakosh, we already have a PG for this issue, but, as you can see, restitution is inconsistent and the sphere never sleeps.  Brownian jitter (no-sleep) has been an issue in our physics engines for a long time, and I'm not sure "isSleeping" EVER goes true (except maybe with restitution set 0.1 on both colliding bodies).  But bounce-inconsistency and no-sleep jitter... is not the issue, here, of course.

I think... when Abdullah has more activity happening in his scene, this OnPhysicsCollide (line 29) fails to trigger much more often.

Let's load-up.  http://www.babylonjs-playground.com/#1AAQUN#24  

Darn, I was hoping to bog-down into the 30 fps range with this test... but I only bogged to 45 fps area, for my Firefox.  Collide still seems consistent. 

Maybe I should have loaded-up the scene with more physics activity. 

Abdullah... POSSIBLY... it is this failure of physics engine to .allowSleep that is causing OTHER physics activity in your scene... to make this collider fail more often.  Try to ensure that your physics engine is never "loaded-down" with any continuous collisions or continuous physics body overlapping.  (Avoid physics bodies "rubbing" on each other, and physics bodies NOT going to sleep when movement is tiny).  Try to learn the "rules" (criteria) used by physics engines to determine WHEN they "sleep" a physics body.  Avoid continuous "rubbing" to maximize physics engine performance, I'd say.

I think this issue is solved, as best it CAN be.

For those who might want to continue investigating sphere.physicsImpostor._physicsBody.sleepState, here is a playground that prints sphere's sleepState on the PG toolbar once per frame.  It is NOT in continuous collide, or we would see the scene color flashing.  But it won't sleep.  This PG is a good place to play-with restitutions and other physicsImpostor._physicsBody properties... such as .sleepTimeLimit, .sleepSpeedLimit, .timeLastSleepy, and .allowSleep  (see console).   First person to make the sphere sleep... without using force... gets the "BJS Golden Puppy-Stool Award" !!  YAY! 

Back to the original PG demo (bouncing)...

...sphere energy roll-off is terrible, eh?  Sphere bounces higher, then lower, then higher, etc.  Darn.

On another subject... if I change line 14... to 110 lights, Firefox bogs, ground material disappears, and I get a big shader-fail dump to console.

BJS - [07:24:14]: Error: ERROR: 0:? : '' : syntax error 
babylon.js:3:25521

BJS - [07:24:14]: Vertex shader:defaultbabylon.js:3:25521

BJS - [07:24:14]: Fragment shader:defaultbabylon.js:3:25521

BJS - [07:24:14]: Trying next fallback.babylon.js:3:25521

Error: WebGL: shaderSource: Source has more than 262143 characters. (Driver workaround)babylon.js:4:7591
BJS - [07:24:14]: Unable to compile effect: 

(and lots more)

I am having the same issue with a LiteBrite demo that I have been working-on... in the Wingnut Chronicles.

Add too many lights, and a shader fails.  It's a higher number of lights allowed, in IE, but material fails for IE, too (but no shader error dump.) 

This is off-topic for THIS thread, so perhaps I should start a new forum topic, or remain in the Wingnut Chronicles.

[GameMonetize]

Ok regarding the physics, let's bump @RaananW

(regarding the shader error, this is expected as there is a limitation to the number of instructions per shader. But the new webgl2 runtime will help increasing this number ;))

[Wingnut]

ahhh, I dunno, DK. 

Did you visit the Firefox version of my LiteBrite demo?

http://www.babylonjs-playground.com/#18TRYT#24

In FF, the 3rd light... (add another "o" to line 65) ...causes the shader crash and box material loss.

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

Now for the IE version...

http://www.babylonjs-playground.com/#18TRYT#25

86th light bulb... causes material loss on "box".  (but no shader error dump)

Add one "o" to line 76 - box material is gone. 

Here's the post about it...  http://www.html5gamedevs.com/topic/2571-the-wingnut-chronicles/?do=findComment&comment=156976

Anyone else getting same indications?  Maybe not, eh?  Maybe I'm broken, locally, or mentally. 

No hurry to address this, but... I think there's more happening here... than a webGL limitation.  *shrug*

[GameMonetize]

I filed a bug for Firefox:https://bugzilla.mozilla.org/show_bug.cgi?id=1329051

For Chrome and IE this is shaders limitations  (try it on Chrome with WebGl2 enabled in about:flags)

[Wingnut]

Wow, cool.  Thanks.  Now I wish I would have provided a simpler playground.  My code is all messy and stinky. 

[Pryme8]

Wait hold up we have 2.0 access now? 

[GameMonetize]

Yep  (Check my announcement in Announcements section)

[Pryme8]

Y'all might lose me for a few days now. Lots of reading to do.

[RaananW]

Hi Guys,

a note about the physics part - 

I didn't quite understand what the problem is. Is it:

1) Sometimes the event doesn't trigger?

or

2) The event is triggered too often, even when the sphere is not jumping anymore?

Whether 1 or 2, the answer is kind'a the same - the physics engine is responsible for this. we are just a proxy.

Having said that - if it is 1 - I would be very happy to see that reproduced!

if it is 2 - The sphere doesn't stop. it keeps on jumping we are talking about very very low values, but it simply colliding with the ground constantly. You could check if the velocity is smaller than a predefined alpha, and not change the color. Or reset the velocity and it will stop jumping.