angle of mesh intersection

[Ghostdog]

Hi,

I need help to write a solution determining the angle of intersection between surface of a sphere and the inner surface of a sphere segment.

.. with the goal to let the sphere, that is moving towards the segment, be redirected as its outgoing angle as with the incoming angle.

 

If i am right I need to calculate the angle of the normals vectors of the intersection faces...

 

I need your help about the how to get the normals of the faces that are aligned to the intersection point.. if indeed this is the right way for my goal??

 

Thanks and with best regards,

Ghostdog

  

[GameMonetize]

Hello and welcome!

Do you mind creating a simple repro in the playground with the maths that you've already done? This is going to be easier for us to help you

[Ghostdog]

Thanks!

 

I now added something- ..

http://www.babylonjs-playground.com/#1R1AA2#1

As is it may to see, this ball that flys around had several errors .. the render error .. the intersections error

and the error that the incoming and outgoing angle are the same ... and they should'nt of course. In the scene and if the ball hit this sphere segment the ball should fly away a down-direction.

Coming back to my question ...

 

Quote

I need help to write a solution determining the angle of intersection between surface of a sphere and the inner surface of a sphere segment.

If i am right I need to calculate the angle of the normals vectors of the intersection faces...

I need your help about the how to get the normals of the faces that are aligned to the intersection point.. if indeed this is the right way for my goal??

 

I am thankfull for every help!

 

Thanks!

[Wingnut]

Hi GD.  Okay, allow me to reword.  You want ball to rebound from curved surface... in a direction that considers two factors...

1.  Angle of incoming ball.
2.  Angle of the face that it impacts.

*nod*  Like tossing a ball into a bowl.  Ball rebound angle should "honor" inbound ball trajectory-angle AND impacted face-angle.

There is likely some other formula... to find the worldspace orientation of a point-of-impact face.  hmm.

You want "realistic" ball rebound-angle... when the ball is tossed into this kind of bowl. 

First problem... getting a useful "angle" of the impacted face.  hmm.  Your pictures in your earlier post... are very good, GD.  How do we get the angle of the impact point inside the bowl?

Or how do we get the "angular relationship" of the ball impact angle... to the impacted face.  When all is perfect, ball tossed into bowl... should do in-bowl ping-pong-ing until ball loses all energy.  (and without a classic third-party physics engine).

@jerome recently added mesh-intersecting to his Solid Particle System (SPS).  So, just for fun, I modified one of his demos... and angled all the bounce platforms.

http://www.babylonjs-playground.com/#PBVEM#18

I wanted to see if the ball's bounce "restitution" trajectory... took particle rotation into consideration. 

I don't think it does.  I think his bounding areas are "loose" and do not rotate along-with the particle. Not sure.

I just talk talk talk, and I have no answers, eh?  I am SO helpful!  (not)     Hopefully, smart people will answer soon.  Face angle at intersect point.  Hmm.  *scratch scratch*

[jerome]

to compute a bounce after a collision (incoming angle == outgoing angle around the impacted surface normal) , the 3D formula in 3D is in this post  : 

 

[Wingnut]

Oh yeah, thx @jerome.  I was thinking lighting normals... at each vertex of the face.  But the face itself has a "normal", too.  Not stored.  Need to be calculated.  It's orthogo-noodle to the face.  *nod*   Perpendiculoid.  I'm going to learn this stuff someday, even if it kills me! 

Quote

incoming angle == outgoing angle around the impacted surface normal

I'm not sure I understand the word "around", used there.  But maybe ghostdog understands... and that's what is important.

I'm goin' to The Wingnut Chronicles to play (and to avoid going way off-topic, here.)  I want to do demented bounce experiments.  But I'll still be nearby here, helping ghostdog stay confused.    I sure wish I had BJS as a visualization tool... when I was trying to learn high school math.  Comprehending this stuff... would be easier, now.

[jerome]

yep, lightning normals are vertex normals...

to get a facet (ABC) normal, you could just normalize the cross product of AB ^ AC

if you don't want to compute all this by your own, you could also clone once the mesh, then convert it to a flat shaded one and get in some array its lightning normals what are then also facet normals and finally dispose it (it was just here for computanional purpose)

 

"around" is certainly not the appropriate term, but I usually don't know how to translate some french maths word to right english. It's rather the symetric vector of given vector along the axis defined by the normal vector... something like this ;-D

 

[Wingnut]

Its all cool, Jerome.

http://tinyurl.com/h8nu3uc

(Lots of pictures).

Ghostdog actually needs the "negate" of the impacted-face's normal.  The normal inside a hemisphere. (a bowl)

Not my picture... just web-found.

If ball tossed-into bowl, Ghostdog wants inside-the-sphere/hemisphere... face normal (at ball impact-point).  It is needed for calculating proper ball rebound inside the bowl. 

Oh, I forgot that Jerome helped us to make hemispheres.  Duh, Wingy.  Ok, here is one ready for in-bowl ball bouncing. 

http://www.babylonjs-playground.com/#PBVEM#23

I don't think mesh cloning is going to work.  Ghostdog needs the surface normal of the impacted face (inside the bowl).  Then, I assume, he wants to calculate the ball rebound angle... using that (negated?) normal.  Does that make sense?  He needs the inside-the-bowl normal... of the ball-intersected face.  Difficult to explain.

Another example.  @jerome, in your cool click-to-explode playground demo, you are NOT using the face normals on the mountainsides... to calculate box bounce, right?  You are using only heightmap heights, yes?  You never derive the surface normal of a mountain mesh facet-of-impact, correct?

IF the mountains were a bowl/hemisphere (not a height map), then you WOULD need to derive the normal of each impacted face... to get realistic boxes movement?  I think so.   Sigh, 3D geometry terminology.  I really need to learn it better.    Jerometry?  heh.

 

[adam]

To get the correct normal I'd get the vector from the sphere to the center of the sphere segment and normalize it.

edit:

Then I'd do what Jerome described.  

-use that normal to construct a coordinate system / space

-rotate the velocity of the sphere to that space

-negate the y velocity

-rotate the velocity back to world space

[Wingnut]

Yeah, that sounds right (after negating it).  But how does a person DO that? 

Perhaps... onIntersect... shoot a ray from big sphere center... to impacting ball center?  (and then negate the direction vector)

All Ghostdog has... is the faceID.  In fact, I don't know if faceID is available... with intersectsMesh.  (Sorry, I'm not very experienced with collisions/intersects, yet.  Working on it). 

[adam]

Just now, Wingnut said:

Perhaps... onIntersect... shoot a ray from big sphere center... to impacting ball center?  (and then negate)

Check the distance from the sphere to the center of the sphere segment.  If the distance is longer than the sphere segment radius minus the sphere radius, then we have hit or gone beyond the sphere segment.

[Wingnut]

Continuously firing the ray... to check for collision?  Erf.  Create our own .checkCollisions system?  Ow.    My dog just ran under the fridge again.

But yes, I think I understand.  No need for boundingBox/boundingSphere, and no need for "precise" and all that bounding crap.  hmm.  thx Adam.

[jerome]

@Wingnut in the BOOM demo, I don't compute the ground normals... because the Ground Mesh has a special dedicated method (from your servant) called getNormalAtCoordinates(x, z) : http://www.babylonjs-playground.com/#1RLVRZ#4

Just have an accurate look  at the line 175

The ground heights and normals are computed and stored for you by the mesh itself. Better, if you update the mesh, you can just refresh them with this one : https://github.com/BabylonJS/Babylon.js/blob/master/src/Mesh/babylon.groundMesh.ts#L107

 

 

[Wingnut]

  Yeah, thx Jerome.  Sorry if I treat you like a servant, Jerome.  My apologies.  You make it look so easy, though.  But if I would take the time to learn it... then I could make it look easy, too. 

I think I have a "complex"... a phobia... a self-inflicted wall... a personal mental issue.  I should not be trying to help Ghostdog.  I am not yet qualified for this level of helping.

I need to code-up mesh.getNormalAtFaceId(id).  Possibly use Adam's idea... extend ray from hemi center... to faceId.

I wonder how slow getVertexPositionsOfFaceId(id) would be.  Once I have those 3 vert positions... I (a smarter I) can calc the face orientation/transformation.  Easy. 

[jerome]

no worry... another bad translation of mine from the very polite french : 'de votre serviteur'

[Wingnut]

Thx! 

Hey, there's another thread... that did this...  http://www.html5gamedevs.com/topic/26225-find-which-face-of-mesh-was-hit/?do=findComment&comment=150773

pickingInfo.getNormal()!   Might work, but maybe not.  hmm.

Shoot ray from invisible mesh at hemisphere origin.... to hemisphere/sphere inner surface.  BUT... hmm... the ray must pass-thru the ball origin (onIntersect)... and hit the surface of the hemisphere.  How the heck?  hmm. 

Ok, here's an idea.  TWO rays.  Shoot a ray from hemisphere center to ball (when impact with hemisphere face happens).  Get the direction to the ball (onIntersect), then set ball.setEnabled(false).  Then shoot ANOTHER ray... using the exact same angle as the ball ray.   The 2nd ray shot will hit a face on the hemisphere.  Then getNormal on that face, then ball.setEnabled = true.  Wow.

I don't know if a ray can be shot along a certain direction (the 2nd ray).  hmm.  Darn. The answer is here somewhere, I can smell it.    I bet I am over-thinking (and over-talking) it. 

[Ghostdog]

Oje, I see the point now .. I*d neer should ask that question     .but who not ask get no anwers - right? 

 

Anyway.. THANKS for the all the rays and shoots on me (:  ..  the solution is realy very close now!! 

[adam]

On 11/14/2016 at 9:47 AM, Wingnut said:

Continuously firing the ray... to check for collision?  Erf. 

Nope, just:

var distSq = BABYLON.Vector3.DistanceSquared(pos1, pos2);

var maxDist = radius1 - radius2;

if(distSq > maxDist*maxDist){

   //we are hitting or outside 

}

[Wingnut]

Okay, good, we are close, then... maybe.  Fun challenge.  DistanceSquare - excellent, and thx for code snippet.

http://www.babylonjs-playground.com/#PBVEM#25

It works perfect!  We got intersect, without using intersectsMesh or bounding boxes.

Now...  what?  heh.  Now we shoot the ray between ball and origin (green box), and use the pickInfo.getNormal()?  Let's try some stuff in the onCollision() function, using some code found in THIS POST.  Here we go...

http://www.babylonjs-playground.com/#PBVEM#26

Check console.  I got some vectors!  YAY!  They look... umm... okay, I guess.

But I think there is still trouble.  I am getting the normal of the ball-face that is opposite of origin, but then I am ONLY negating that value.  In doing that, I am not truly getting the normal of the hemisphere point-of-impact.  Instead, I am faking it.  IF the hemisphere were low-rez, then the "inverse" would be quite inaccurate.  hmm.  I still got issues, here.  Tweaking...

http://www.babylonjs-playground.com/#PBVEM#29

Here, I shoot two rays, and experiment with "predicates?".  That might be the wrong term.  Perhaps... "conditionals" is the correct term.

Lines 77-84 is the first ray shot.  End of line 78 says item must == ball.
Lines 86-92 - shoot same ray, with predicate conditional in line 86 says item must == hemisphere

At console... I report normal and other normal.  Other normal STILL could be the hemi's normal that is facing OUTSIDE-OF the hemisphere, and thus needs a negate().  Hmm. Or perhaps normal needs a negate().

Ok, here we go again... http://www.babylonjs-playground.com/#PBVEM#30

Ball drop straight down the Y axis.  Console:  normal.y (ball) looks... reversed.  So does other normal.y.  More tweaking...

http://www.babylonjs-playground.com/#PBVEM#31

There.  Console reports look good.  Ball normal is reporting almost straight down Y axis.  Hemi is reporting almost straight up Y axis.  Yay.

In theory, making the hemisphere be REALLY HI-REZ will cause the X and Z values (axial deviations?) of the hemi values (as seen on console)... be MUCH lower numbers.  Let's see if that is true:

http://www.babylonjs-playground.com/#PBVEM#32

Yep.  Cooooooooool.  I think the green box origin can be eliminated.  Not sure if it is wise, or if it causes trouble. 

Another interesting thing is seen, here.  For my computer, line 103... 1.826 causes ball come THROUGH the hemi a small amount.  1.827 causes the ball to be a bit high, appearing not to be intersecting.  Interesting (at least to me).

Who wants to put a Cannon meshImpostor on our bowl, and watch the ball roll around in it?  It almost BEGS us to do it, eh?    Swimming pool skateboarders, eat your hearts-out. 

What's that?  Put the car inside the bowl, too?  Okay.  Pardon?  You want the cloth, too?  Okay.  (seriously off-topic) 

[adam]

http://www.babylonjs-playground.com/#PBVEM#38

[Wingnut]

EXCELLENT!!!  Thx Adam!

That is using faked/ball-derived hemi face normals, though.

http://www.babylonjs-playground.com/#PBVEM#40

The ball is rolling rather smoothly across the low-rez hemi.  Hemi resolution is set with line 52 segments: parameter

The ball-bounce pattern is identical, no matter the resolution of the hemi.  I imagine the same is true about the ball. 

Ideally, with a low rez ball, the ball should jitter/vibrate as it rolls. 

That is why I did the twin picking rays... to try to derive those facet angles.  Scary. 

I don't know if those two impact-point normals can be honored/considered in the ball bounce-angle and roll movements. 

Ghostdog made it sound like he was open to other ideas (besides collecting normals).  But it would be triple excellent if those two normals were considered/honored during the ball movements.   

We need SOME method of "getNormal", and that's either with a ray, or possibly with a "derive face normal by querying face's vertices" method.  erf.

I think we need two rays on EVERY FRAME... if ball is rolling.  If ball is bouncing, then two rays at intersect time.  It might require a constant transforming... of Line 86 "up"    (My dog looks scared.)

[jerome]

Writing a getNormal() method is not that complex (I'll probably do it for you next week, too busy currently). What's more complex is to find what facet of a mesh is collided the ball, or anything else. Actually using the ray approach will solve the problem any time, but the ray method is not that performant.

What I have in mind would be to compute at will an array, facetData, of normals and positions per facet of a mesh (in the local mesh space).  No need to compute it each frame, only once before starting to computing some collision, and maybe again each time you update/morph the mesh.

ex : facetData[facetId] = {facetNormal: Vector3, facetPosition: vector3}

Positions would be each facet barycenter position. With both these data, you can then compute a collision :

if distance(ball, facet) < ballSize then computeBounce(facetNormal)

distance is computed from the ball and facet world positions, itself computed from the array facet position. facetNormal is the normal of the facet in the world system, computed from the array facetNormal value.

If we don't want to use rays, the problem then is to test the distance against each mesh facet, what can be quite long. So we need first to store the facetData element in an octree and then only test the distances between the ball and the facets of the octree block where the ball currently is. This would be really faster because the test would only concern really few facets.

But that's not enough... Imagine that some part of the mesh were very sharp, the ball would be near (distance lower than its size) two facets simultaneously. How to choose the one we would use its normal to compute the bounce ? Maybe we need to compare also the distances of all the facets near enough to the ball and just keep the minimal one to determine the facet of impact.

 

Not sure I'm very clear ...

[Wingnut]

Yeah, that's a good idea.  Pre-process the mesh at scene start.  Gather an array of ... umm...  { faceId: normal, faceId: normal, etc }  Interesting!

And yes, I understand that we still need to determine which face impacted-with which face (preferably without using slow rays).  hmm.

Keep in mind that Ghostdog might not NEED this.    He might be satisfied with Adam's bounce method.

Advancing further... could be Wingnut Weirdness... and perhaps not necessary.  I hope I am not causing un-needed headaches.  heh.

Still, my curiosity pushes me.    Don't do work on this... if the work is not enjoyable.  No need for stress.

Thx for your thoughts/ideas, @jerome and others. 

[jerome]

Well, this is an old post, but I've been quit busy these last weeks...

So here am I back with this : http://www.babylonjs-playground.com/#WOFCL

tl,dr;   facet normals and facet positions ... will be useful for custom collision computation or anything else from your crazy brains, guys

var facetData = mesh.getFacetData();       // returns an array of facetDataElements
var i = 10;                                // the tenth facet
var normal = facetData[i].facetNormal      // its normal (Vector3)
var position = facetData[i].facetPosition  // its barycenter position in the local space (Vector3)

If, for any reason the mesh is morphed afterwards, then

mesh.updateFacetData();

will just do the job

 

It's NOT implemented in the BJS core for now, it's just a work prototype.

Please have a look at the code :

the scene part starts from the line 80 and it's quite short

the facetData part is from the line 1 to the line 75

 

Of course, it should work with any mesh type :

http://www.babylonjs-playground.com/#WOFCL#1

http://www.babylonjs-playground.com/#WOFCL#2

http://www.babylonjs-playground.com/#WOFCL#3

[jerome]

the same with a naive octree implementation : http://www.babylonjs-playground.com/#WOFCL#4

the console should give the number of facets in the same octree block than the ball

 

Wait for some days until I get this work back