Jump to content

get first contact point on collision with physics


Recommended Posts

Hi @all again,

is it possible to get the first point of contact if two objects with physics collide?:)

Of course i can get the positions of each object by itself, but not the point where their bodies contact at the first time, or?
If yes, how?


Link to comment
Share on other sites

Hm, i tried this code:

meshA.physicsImpostor.registerOnPhysicsCollide(meshB.physicsImpostor, function (main, collided) {
// do something ...

The Problem: I have to know which meshes will collide in the future. In my case are potential unlimited meshes. Is there a way to track one mesh collide with something else?

Link to comment
Share on other sites

Hi Hans!  I was just talking, recently, about the inconsistency of registered physics onCollide... with @enwolveren ... over in the Wingnut Chronicles.  You must have heard me talking.  :D  Too bad it is inconsistent.  I suspect that the inconsistency is related to the physics "timestep" which Fenomas recently taught us some things -about.  I don't have the exact syntax handy... for how to set a physics world's timestep, sorry.

AND, timestep will affect all the physics motions, so, I don't think that is the answer to our inconsistent physics collide-monitoring.

I'm still looking for ANY demo... that changes the color of a mesh... EVERY TIME it collides, high or low velocity... with another physics-active mesh.

Perhaps "workers" are involved, too.  I'm quite sure that "workers" are involved in our non-physics intersection/collision, but I'm not sure about physics intersects.  I doubt they are used, there.

As for getting the exact FACE or POINT of first-contact... phew... I dunno.  Thinkin'.  hmm.

Link to comment
Share on other sites


4 hours ago, Wingnut said:

I'm still looking for ANY demo... that changes the color of a mesh... EVERY TIME it collides, high or low velocity... with another physics-active mesh.

This is possible  with:

mesh.physicsImpostor.onCollideEvent = function (self, other) {...} 

I think this works normal or?  I dont realized inconsistents with this way by now

Problem: I want also the contact point. Above i can just get the positions of both collide elements, but not the point between where there bodies are in contact.

I don't know the physics stuff in BJ. My first idea was to make my own solution to get the contact point: If the collide event is triggerd, I can maybe calculate the contact point for simple mash objects. I think I can ascertain all necessary values from the objects.

Dont sure if this work. Will try it this days.

Link to comment
Share on other sites

based on recent helpful @Wingnut chronicle... possible Playground to test solution. Two things: the "everything is a particle solution", notion around Oimo physics landscapes. And the awesome  Raanan's cloth demo (wingy wireframe).  Perhaps combined...? I'm too new to confirm context-crossover(cloth to particle to what you need). Wingnut mentioned a  particleImpostor(if I'm not mistaken, checking...yep). Causes wonder, hypothetically, if each node of the cloth had it's own impostor. It does.  

-> Would first contact-point vectors of orb to the cloth give us a callback first?  Probably not, but closer perhaps.

Disclaimer: 80% off rocker 90% of the time. Yet, this would be a fun direction to test? A simple-analog to contact-points at a low level. And bonus if Raanan has, perhaps, a stub hiding in there already. maybe commented out....at bottom? Not sure. : )

Update: "Yes, cloth demo is a bunch-o-joints ( distanceJoints hung-from stead-points :) )... and the cloth uses "particleImpostors".  I never knew particleImpostors (point impostors?) existed... until  Raanan used them. " ~ Mr. Wingnut  thx for that.

Me: It would be nice to know of particleImpostors scalability. Example: between 1 and a world-o-particles where might browser barf? : )

Link to comment
Share on other sites

Okay, I guess someone needs to make a playground.


Oimo ball-bouncer, and in lines 46-61, I think I've got all three "known" ways to wedge-into the physics collider... applied on both mesh.

I can't get ANYTHING to trigger myCollide.  Six, count-em' SIX wedge-ins, and no trigger-on-collide.  heh.

Surely I am missing something in this PG.  Anyone have better eyes than me, today?  Can you find my stupidity?  I appreciate the help.

Objective: see if we can get collide event consistency, no matter the body velocities (including simple floor-rolling), and no matter the negative gravity levels (except zero).  Then after that, we'll dive-into the working onCollide, and see what we can harvest from the physics engine... as far as impact points.

@enwolveren - interesting idea - putting a particleImpostor at each sphere vert, (and perhaps at each face-center)... instead-of using a single master impostor.  hmm.  Worth pondering, that's for sure.  :)

Update:  [link] Lines 52/53 method now work. (registerOnPhysicsCollide).  Not sure about consistency, yet.  Those lines are remarked-out, now.  I'm working on getting other two methods operational, now.

(52/53 - I had sphere line... checking for collision with sphere (with itself), and ground with ground.  hehe.  I should read docs, eh?)

(broken links recently repaired)  :)

Link to comment
Share on other sites

On 4/22/2017 at 8:03 AM, Hans said:

The Problem: I have to know which meshes will collide in the future. In my case are potential unlimited meshes. Is there a way to track one mesh collide with something else?

Hans, we will research this, too.  Essentially, you want scene.onPhysicsCollide = function(bjs_event) {...} ...that triggers when ANY physics-active mesh (PAM)... collides with ANY OTHER PAM... and the event object (which automatically arrives as arg[0] to the event handler) ...carries refs to the two mesh that collided.  You can "harvest/glean" info about which two mesh/pams collided... from that event object.

Does that sound correct?  Would that work for your issue? 

Let's all think about that.  Perhaps yet another BJS observable.  :)

Link to comment
Share on other sites

22 hours ago, Wingnut said:

Does that sound correct?

That does!
There is stil a problem. A picture paints a thousand words. I made a picture for the problem. It shows two meshes "on collide event".

I want the contact point (position of the red sphere) on collide event. :)  (But we just get the green ball positions)



PS: @Wingnut here is the your demo for the seconde way (line 55 and 56):



Link to comment
Share on other sites

Ahhh, onCollideEvent... very good. (thx)  2 of 3 ways work, now.  Well done.

Yeah, I realize that you wish to "attain" the point-of-impact.  I did some examining of Oimo internals.  I toured all the methods and properties on the OIMO object, and examined sphere.physicsImpostor._physicsBody rather closely.  Nothing obvious.  Scary stuff.  I'm really not qualified to dig that deep.


Click on object in console... to open browser object inspector... if you wish.  It's ugly.  :D  I'll keep thinking, but, what you ask... phew. 

Hopefully, smarter people than I... will comment soon.  Sorry I have no good news.


Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...