How to make mesh move along the ray or curve?

[Wingnut]

Hi S.  Our pleasure.  CCD is continuous collision detection... you can read about it on the web (search for physics engine CCD likely).  Worldwide issue, I think.

With animation... phew.  We have seen in the past... that animations are rather difficult to interrupt.  To maximize their speeds and fluidity, by default, we don't want to stop between interpolation value-steps.. to check anything.  I think it will require some deep hacking of animation class.  Not sure.

BUT... there is another possibility.  Building your own observer... or assembling an observer... that watches for changes in bullet.position property.  In that observer... if it triggers... check for intersection.

If intersection... ummm... I dunno.  Stop/Destroy the animation in any way possible.  Just thoughts.  Others likely have better/other ideas... let's listen. 

  https://www.babylonjs-playground.com/#91I2RE#69 has some "observe" stuff on it... for it's value property.  You might try to borrow some of that code.... to add to bullet and to observe its .position.  Not sure, I have no experience with custom observers.  http://doc.babylonjs.com/how_to/observables

Warning:  I said animations are difficult to interrupt, and that might prevent observables from being checked... during an animation run.  Not sure.  Info welcome... from everyone.

[Raggar]

1 hour ago, splash27 said:

Btw, what is CCD?

Couldn't quite get it to work using the impostor system.

Look at this PG ported to native CannonJS:

https://playground.babylonjs.com/#0H29AJ#40

You see, the sphere is too quick to be registered at the physics steps.

Now try this version with the updated version of CannonJS(You might have to CTRL+F5 + RUN for it to properly run the new CannonJS file):

https://playground.babylonjs.com/#0H29AJ#39

Even with a power of 500, it registers the hit.

[Wingnut]

Hi again, R.  On #39 PG, maximum power 100... to get intersect reports (2 each time)... for my FF ESR 52 and my IE 11.0.9600.18097.  hmm. 

Anything over 100, and no intersect reports.  What the heck?  Caches cleared.

Dell XPS 8700.  *scratch scratch*  (Thx for the CCD-active Cannon, though, for sure.  A nice thing to do.)

[Raggar]

Hmm. Maybe it due to the speed of the physics stepping, and the intersection happens outside BabylonJS's own loop? I'm not sure, though.

Here's an example using the beginContact, endContact and collide events. bodyA and bodyB are both null in the returned object, though. I have this issue in my project as well, although both bodies are registered correctly in NodeJS, which is weird

https://playground.babylonjs.com/#0H29AJ#41

[splash27]

Ok! Thank you again! 

Seems like I have to learn this field more carefully before proceed.

Is CCD-active CannonJS some kind of fork of official CannonJS? Where can I get the last version of it?

Also are there some tutorials how to use BabylonJS with native CannonJS? Since the Impostor system doesn't work here.

 

[splash27]

What about collision detection in animatable object, I made the following solution: http://www.babylonjs-playground.com/#RS8SCE#3

It works and it's pretty stable. It should has a less amount of bullet-thru-wall issues, because animation and collision checking occurs in the same rendering loop.

However it may cause performance issues in case of big amount of meshes in the scene. We could try to reduce intersection loop. For example, we can exclude walls, floors and ceils from the loop and check intersections with them by checking current coordinates of the rocket. Its possible, because walls stay still. If, for example, rocket flew below y-coordinate of the floor, obviously the floor was intersected. Yeah, the situation might be much harder with mutli floor and multi room scenes. Maybe there is no universal solution. Each scene should be optimized individually.

[Wingnut]

Hi S.  I don't see any shots happening in that PG.  No errors.  Annoying pointerLock happens, but no shot.  hmm.  I must have broken something.  ?

So, your bullet has physics AND its being controlled by an animation... at the same time?  Does gravity ever work?  Doesn't the animation's forcing of positions... keep the bullet from having any downward gravity curve?  hmm.

IF you DIDN'T use a Babylon.Animation, and instead animated using the renderLoop [ if bullet.isFlying -> move bullet a tiny bit more forward during THIS frame ] ... THEN you could do "move it a tiny bit forward AND move it a micro bit downward" (gravity pull).  AND you could do "move it a micro bit down-wind", too.   AND... "move it a little LESS forward than last move forward"... because we are slowly diminishing the bullet's momentum.  That would give you some powers, eh?

The render loop can be used as a step-by-step bullet flyer... without using Babylon.Animation (which is a forceful bully and doesn't like being told to calculate gravity, windage, and momentum-losses.)    If you are going to use Babylon.Animation, you might as well turn OFF physics, because all physics forces are being ignored (I think).  The Animation likely overrides any physics forces. 

BUT... I can't be sure.  Rarely do people try BJS Animation on physics-active objects.  Perhaps I am wrong.  Common for me. 

Perhaps a weirder idea... animate an invisible mesh (placed slightly above the real bullet mesh) that has a physics lockJoint extending down to the real bullet.  This allows that somewhat-flexible lockJoint to be a buffer between the animation-forced invisible box, and the physics-forces-influenced real bullet.

https://www.babylonjs-playground.com/#15AFCG#31

There's a demo.  The cursor keys "force-position" the little gray ibox, just like a Babylon.Animation would do.  But a lockJoint is connected from the gray ibox, down to the green player box.

The ibox.. would be invisible... in the end product.  If you Babylon.Animated (fire) the gray invisible ibox, the green player box would fly along... but its semi-flexible .lockjoint would increase in length... because of gravity pull on green box.  Doing this... you MIGHT successfully mix "hard animation" with physics engine "soft animation".

Weird, eh?  I hear ya.  Same with cross-winds (sideways gravity).  The length and hang-angle of the invisible joint between ibox and player... would change... during a crosswind.  The hard-animated gray box could be Babylon.Animated, or renderLoop translateALittle() animated... and green player box would NOT PRECISELY take positioning orders from gray box.  It would mix those hard-positioning orders... with orders coming from physics world, too.  Dual influence.  Fancy, huh?

This is mainly for precise ballistics work, and certainly not necessary for video game indiscriminate blasting/mowing.  Just Wingnut thinkin' and inkin'. 

Note: If you DO try a fly-a-physics-mesh-with-render-loop method, don't use .moveWithCollisions or .position or .setPosition().  Only use mesh.translate()  (a coding secret I heard... which seems to have some truth.) 

[splash27]

Hi, Wingnut.

I don't know why you always have troubles with pounterLock. This part of code allows me to use free mouse look. 

Now what about Long Range Weapons (LRW). I can mark 3 following approaches (or even archetypes).

1. Laser. Instant damage at the point of intersection, or projectile teleportation. It's pretty good for laser cannons or probably sniper rifles. But it's not suitable for rockets, fireballs and other slow projectiles. Also I don't want to use it for regular firearms. Because even in real life you're still have a low chance to evade from pistol bullet. So, I didn't try this approach.

2. Rocket. Moving projectile along straight line. Very common approach. Suitable almost for every LRW. Except grenades, maybe. In this case projectiles just fly straight and ignore any forces. This approach especially good for rockets, since rockets have engine to compensate any force. For regular firearms this approach might be odd, however it's still ok for arcade shooters. I tried to implement it using physics engine and setLinearVelocity but failed with gravity compensation. That's why I tried to use Animation. I faced problems with collisions detection but solved it in my last playground.

3. Grenade. Projectile loses altitude because of gravity. Closer to reality approach. It works pretty fine with CannonJS. Despite the strange collision detection handler attachment (bullet.physicsImpostor.physicsBody.addEventListener('collide', function(){console.log("collide");})). The only problem here is bullet-thru-wall issue. Because bullets should fly pretty fast. It can be solved by using CCD-active CannonJS. So, it's a little bit hard for me at this moment, because I should use native CannonJS interfaces instead of Impostor system. I should learn a lot about it. Also I don't know where to get this modified version of CannonJS, except extracting from Raggar's PG example. So, this is the last obstacle on my way to success.

Of course all archetypes could be modified and extended. For example, one can use delayed damage in Laser approach or collision loop reduction in Rocket approach.

[Wingnut]

I don't have troubles with pointerLock... I just dislike it... unless actually playing the game full-screen.

Main thing is... no shooting happening in your last PG.  Not sure why, yet. 

Anyway...

https://playground.babylonjs.com/#0H29AJ#44

That's all physics, and two-of-three intersect testers are working consistently for me, with no thru-targets... at 350 power.  [ ActionManager onEnter (lines 113-122) and intersectsMesh precise (line 142) ].  Both are reporting intersects... consistently to console.

That's not bad, is it?  350!  That's cookin'!  Love your physics engine, and all that?    C'mon... kiss the Cannon... it's trying really hard to please you. 

Crank-up line 15 value to .2, we might make 500 power.  Rockets, grenades, bullets, all physical objects... needs physics engine to be realistic.  Laser... completely different... not apropos to be part of a projectile launching package, right?

By the way, you asked about where to learn CannonJS native calls.  I would start here... https://github.com/schteppe/cannon.js

Visit demos and examples folders... tour some code.  Grab some terms from there, and search for those terms in the playground in-code searcher.  That should help you find some playgrounds in-which others have done native calls.  Generally speaking... native calls are often adjustments done to mesh.physicsImpostor.physicsBody. 

I don't know of any tutorials specifically to teach native calls.  Physics engines can do LOTS of things and be configured very strangely.  A comprehensive tutorial might require some serious text... and would likely need editing/updating every 13 hours.  :)

I've done some "native" work, but mostly in Oimo. 

Ok, that's all I got.  Hope everyone's well.