Problem with mesh collision detection

[Steak]

Playground DEMO: https://playground.babylonjs.com/#Z88Q4W#2

Hi,

this is my first post in this forum. I started with bjs a few weeks ago and I love it! 

I played around with the tutorials and while creating a small project I detected an issue with collision detection (intersects.Mesh).

The sphere's in my demo have different colors, representing their life count. In my example I want to detect the life of an object when being hit by the ShotCylinder and reduce the LifeCount by 1.

Now when I hit the object in my console it decreases the life constantly.

How can I stop the life from dropping ? (Maybe stop the collision, I only need the detection once) It seems like the collision seems to survive the dipose().

Maybe someone could help me. Hope my code readable, I am not a professional coder  please keep that in mind!

Have a great day !  

Nils

[Wingnut]

Hi Steak!  Welcome to the forum... good to have you with us.

https://playground.babylonjs.com/#Z88Q4W#15

Whelp... 13 versions and 6 hours later, I have accomplished nothing.    Ain't I quite the helper?

Quite a drastic re-coding.  I turned off the sphere animations (coming at the camera)... and I just made a single sphere... which appears on-screen after about 5 seconds.

Take a shot at it.  Our "shot" (shotCylinder) heads-out on an intercept trajectory... and when it hits... it just keeps-on intersecting, constantly, no matter what I try to do.

Open console.   Tune your editor to lines 156-159 area.  After the intersect... I try lines 157-159, to STOP the intersecting after the first one.  No joy!

Notice line 160.  It used to be a shot.dispose(), but I decided to change to a shot.setEnabled(false).  I thought it was a good idea, but doing that makes the shot quit flying towards the sphere.  Not sure why THAT is happening, either.

SO, I made a mess of Steak's #2 playground, and I solved nothing.  hmm.  I'll keep thinking and testing... but... let's beg for help from others, too.  (beg, beg, beg) 

Stopping in the middle of intersections has NEVER been a good thing to do, and that hasn't changed.    Darn.  What are we missing, here?  *scratch scratch*

I remember a time... when another user had a similar problem.  It was caused by the animation not being "stopped".  It was still running... being constantly positioned at the final keyframe.  hmm.

[Wingnut]

Okay...  https://playground.babylonjs.com/#Z88Q4W#18

(open console, wait 5 secs for enemy to appear, then SHOOT!)

Yay.  Yes, it was the shot animation... still running... at its last keyframe.  That was keeping it "stuck" in intersection.

Line 99 - create a global-ish var called shotAnim.

Line 133... make shotAnim contain a value.  I believe it is a BJS "AnimatABLE"-type object.

Line 150... stop the animation (after it intersects).

Line 151... now that the animation is stopped, the shot mesh can be positioned OUT-OF intersection status.  I move it to the camera.

I am still having problems with shot.setEnabled(false) [line 152]... and shot.setEnabled(true) [line 107].

My thoughts are... pre-make 10 "shot" objects, and store them in "shots" array.  Then just enable/disable them (and start their flight animations) as wanted.

Each shot now "carries" its .targetMesh WITH it.  So... the shots can be "fire and forget"... and likely, there are options for having all 10 shots in-flight at the same time.

And... yeah... the same "stop the animation" issue... will need to be considered when the spheres (enemies) turn-on THEIR animation (flying towards the camera).

But... meantime, we have progress!  YAY!!!  It's Miller Time! 

[Steak]

Thank you for your inspiration I figured it out! It was due to an issue with registerBeforeRender.

By using an Observable  (Line : 169)

Playground:

https://playground.babylonjs.com/#Z88Q4W#19

Really apprectiate the help of an infamous member of the babylon community like you are 

Thanks @Wingnut

 

[Steak]

Is it possible to move the camera and change the spheres animation to head in the direction of the adjusted camera position ?

I tried requiring the meshes I want to update by using the scene variable, but it does not really work.

https://playground.babylonjs.com/#Z88Q4W#19

[Wingnut]

Hi Steak, thx for the nice words, and I'm glad you are making good progress.

BJS animations are created with a thing called "interpolation".  Essentially, it is a "sequence" of actions, based upon a "run" of time.  Unfortunately, it is "grown" just before an animation starts, and it is not super-easy to adjust that sequence... "live" (on-the-fly), dynamically.  What would be needed... is a NEW animation installed on each inbound-to-camera sphere... after every camera re-positioning (while a sphere is inbound toward camera).

But there's another way.  Say goodbye to BJS Animation system, and hello to Steak's Smart-Spheres Incorporated.    What if there was a function on each enemy sphere... that gets "polled" (runned) once per frame?  ALL smart-sphere-class mesh... have this function.  The first line of that function... might be... if (!this.isFlying) return;

If it falls thru THAT line... then guess what?  Yep.  this.lookAt(camera.position);  then this.translate(axis.z, seekStep);  (that's pseudo code, not actual code, but actual code is similar).  The spheres have on-board "chase-the-camera" software. Cooooool.

The same can be done WITHOUT extending/adding-funcs-to...the mesh class.  Just put an updateSpheres() call inside the beforeRender loop... and inside updateSpheres(), you QUICKLY iterate thru all enemySpheres[] array, re-target all isFlying spheres to aim at camera, move them all one "step" towards the camera, check if it intersected (with an invisible mesh parented to camera?)... and then return... quickly.

Our particles systems work this way.  They have an "update" function that is runned just as fast as possible... and it iterates-through each active particle, and moves each a LITTLE BIT along its trajectory path.  It also checks the particle age to see if it is time to recycle it, and it also checks if an in-flight color change is needed.

In your updateSphereTargetAndPositionAndCheckForIntersect() func, you will do just that.  Re-aim the flight path, move down that flight path one step, and check for intersect with camera (with an invisible mesh parented to camera).  If intersect... you know... move shot to someplace out-of-intersection, make it .visibility = 0 or setEnabled(false) or even dispose if necessary.  If not disposing, set its .isFlying to false... of course.

Polling the enemy's ammo box.     Each frame, look thru the ammo box, find out which bullets/spheres are in-flight... make sure they are aimed at camera, and move them one-step towards camera.  Check for intersection, do business as needed, then get the hell out of there.  You are working inside the renderloop and want to finish REAL QUICK so the framework can get back to rendering.  But, I think you will be pleasantly surprised at HOW MUCH WORK can get done inside an "updatePerFrame" function.  Our particle system can update 100,000 particles per frame, and still do some yawning. 

So, does this give you any ideas?  Perhaps use the same system for YOUR smartShots AND enemy smartSpheres?  What if your shots also re-aimed (every frame) if the enemy sphere started zig-zagging, while inbound? 

SmartShots, and SmartEnemies...  both extensions of SteakMesh class, which is an extension of BJS Mesh or AbstractMesh class.  That would ROCK!

I think extending/overloading mesh class --- into being Steak's Camera-Seeking Intersect-Testing Enemy Class... (smart mesh) would be the most fun.  Also, they would be very re-usable from game to game.  Yum.  Seekers!  oooooooo (scary).  Stay tuned.  Others may have better ideas.