Jump to content

angle of mesh intersection


Recommended Posts


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,




Link to comment
Share on other sites

  • 2 weeks later...



I now added something- ..


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

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 ...



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!



Link to comment
Share on other sites

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.


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*

Link to comment
Share on other sites

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!  :D


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.

Link to comment
Share on other sites

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


Link to comment
Share on other sites

:) Its all cool, Jerome.


(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.  :)


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.


Link to comment
Share on other sites

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


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

Link to comment
Share on other sites

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).  :)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

@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



Link to comment
Share on other sites

:)  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.  :o

Link to comment
Share on other sites


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. 

Link to comment
Share on other sites

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


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...


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...


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...


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:


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) 

Link to comment
Share on other sites

EXCELLENT!!!  Thx Adam!

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


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.  :o

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"  :o  (My dog looks scared.)

Link to comment
Share on other sites

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 ...

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

  • 4 weeks later...

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 :P

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


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 :




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...