Move Box Along FreeCamera Direction Vector

[nicktendo]

I am creating a script that will move a box along the vector in front of the center of the camera:  https://www.babylonjs-playground.com/#KWD0E1

Apart from the textures not loading, why does this script seem to not process the collision of the box falling onto the larger box in BJS Playground? The box upon which the smaller box falls seems to flicker, then disappear entirely after the smaller box lands. It works fine on my server.

Also, is there a more elegant way to accomplish this in BJS?

[GameMonetize]

Quote

 that will move a box along the vector in front of the center of the camera

Why do you need physics for that? You can register the scene.registerAfterRender and move your box manually.

 

Can you try to simplify your PG to highlight the issue?

[Wingnut]

Hi guys.  DK... this is the same gentleman who wants a physics-active camera.  He is building a physics-active camera-holding robot/gizmo.

Nicktendo is working with physics... on purpose.  It is a requirement of his project.  He wants his camera mounted onto a bumper car. 

He IS moving box manually in a beforeRender with lines 128-132.  I have been telling Nick that it is best to move physics-active mesh... with setLinearVelocity and/or applyImpulse.  I told him to avoid force-moving.  But he is having good success with force-moving, so far.  Fun experiments!

 

Nick, @Deltakosh ... this is a BJS 3.0 problem ONLY.  2.5 is fine. (almost)  (some box sinking into floor)

Nick might not be using BJS 3.0 alpha on his server.  Perhaps that's why it works, there.

Here's another version:  https://www.babylonjs-playground.com/index.html#KWD0E1#1

You can alternate between two cameras... using C and V keys. 

A few changes... same problem.  Physics problem, I think (what's new?).  In BJS 3, box is sinking into floor, and there is some kind of spastic movement.  In 2.5, box is still sinking SOMEWHAT, but no spastic collision jitters.  AND... it looks like your W key is indeed working... and moving box in direction of camera.  Nice work there, Nick!

I'll keep working.  Try not to get frustrated or discouraged, Nick.  Stay with 2.5 until we get this all sorted-out, please.  Thx.

[Wingnut]

Ok, here's another version.  C/V keys still swap cameras.  W for forward movement on little box... as before.

I removed some stuff... and suddenly, the 3.0 version started working better.  Box is staying atop ground box!  YAY!   Why differences between 2.5 and 3.0?   I dunno.

I can't remember what I removed/changed... but maybe Nick can figure it out.

Nick is still looking for a more-elegant way to derive/move-along camera-forward direction. 

Testers:  Press V key to choose the player camera (on the little box). 

Then press W to move the box/cam forward.

His system is working well, but he would like a cleaner way... than using forwardbox.  Let's help him out with some apropos playgrounds or magic code.

[nicktendo]

Thank you for the great work @Wingnut!

@Deltakosh The main reason I'm arranging the scene in this manner is to ultimately implement "artificial gravity" on a spacecraft relative to the "down" direction on the ship as the craft moves/rotates throughout space.  The gravity force vector will be constantly translated to directly below the player so they are pushed towards the floor of the spacecraft.  When they exit the spacecraft the gravity force will be turned off.  There will be many other objects floating in space that I can't have affected by the same artificial gravity that is implemented on the player when they are aboard the ship.

The main thing for which I was looking for a more elegant solution is the following:

            // Calculate Z rotation of 'forward' vector.
            newX = .1 * Math.cos((camera.rotation.z) + 3.141592654 / 2);
            newY = .1 * Math.sin((camera.rotation.z) + 3.141592654 / 2);
            forwardbox.position.x = newX + box.position.x;
            forwardbox.position.y = newY + box.position.y;
            
            // Calculate X rotation of 'forward' vector.
            newY = .1 * Math.cos((camera.rotation.x) + 3.141592654 / 2);
            newZ = .1 * Math.sin((camera.rotation.x) + 3.141592654 / 2);
            forwardbox.position.y = newY + box.position.y;
            forwardbox.position.z = newZ + box.position.z;
            
            // Calculate Y rotation of 'forward' vector.
            newX = .1 * Math.cos(-(camera.rotation.y) + 3.141592654 / 2);
            newZ = .1 * Math.sin(-(camera.rotation.y) + 3.141592654 / 2);
            forwardbox.position.x = newX + box.position.x;
            forwardbox.position.z = newZ + box.position.z;
            
            if(moveForward == true){
                box.position.x += forwardbox.position.x - box.position.x;
                box.position.y += forwardbox.position.y - box.position.y;
                box.position.z += forwardbox.position.z - box.position.z;
            }

I didn't know if BJS had a more efficient way to accomplish the translation for the "forward" box in front and center of the FreeCamera.

[nicktendo]

Would it be more practical and predictable to utilize the linear velocity of the physics imposter of the player to implement the gravitational "force"?  I.e. gravity is implemented by adding the vector of the artificial gravity to the current linear velocity of the player.  I have a feeling that may play more nicely with the physics engine?

[nicktendo]

Update using linear velocity to implement gravity: https://www.babylonjs-playground.com/index.html#KWD0E1#6

[GameMonetize]

Ok gotcha

It always tough to help with physics as we are not controlling the simulation (which is done by cannon or oimo).

 

Nevertheless, can you try to summarize in the simpler possible way what is the problem here?

[Wingnut]

Quick interrupt:  Nick, don't forget about "faking it".    When player is on-ship, turn-off his physics and just keep his footHeight == shipFloorHeight.  Besides, you don't want him to slide into a spaceship wall... when ship thrusts, right?  heh.  *shrug* 

Are "purist tendencies" in your personality... preventing you from doing sneaky tricks?  If so, I can understand that, too.  Don't forget the physics joint and its springs, too.  If you attached player to inside of ship, with perhaps 6 joints with springs... then player would "skid" some distance with fast ship moves... but not too much.  Adjustable bungee cords, in a way.     Perhaps doable with ONE joint... into top of head, or up player's butt... then set fixed rotation (so he can't tip).  He will stay standing upright, but might skid position-wise... a small amount... when ship moves.

PS: Why worry about gravity calcs?  Just give the impostor some mass, and scene.gravity will automatically be calc'd-in by the physics engine.

Ok, back to "turning/moving box in same direction as camera view" thing... if that is the issue.  I think we had TWO issues/challenges happening here.

[Wingnut]

No movement here, huh?  Sorry Nick.

https://www.babylonjs-playground.com/#15U9CT#21

There's another playground I found laying in Playground Park.  Besides being @Raggar-grade power-code (and who knows who else has had their fingers in this)... I wanted to show you something.  Line 290:

groundBody.quaternion.setFromAxisAngle(new CANNON.Vec3(1,0,0),-Math.PI/2);

This is "native" Cannon lib code.

.quaternion is the NAME of the rotation-setting property on Cannon p-bodies.

Yum!  What a nice physicsBody rotater, eh?  I think you could use this.  Now you don't NEED your camera to pan and tilt anymore... because you can pan and tilt the camera-carrying robot, if you like.  (But maybe that is unnecessary)

Anyway, that playground there... is full of LOTS of cool (Quaternion) physics crap.  When you're dealing-with physicsBody rotations, you'll ALWAYS be dealing-with Quaternions.  International law, I think. 

Scroll down down down... the delicious code just keeps rolling-on-past.  Just a great big pile of demented physics experimentation.  Gotta love it!  Lots to be learned in there.  WASD keys drive the "physics sphere" around.  Notice the cool little "hop/bounce" that the camera-carrying robot does... at the top of the ramp.  Fun!  Be well.

[Raggar]

The prototyping is strong in that one

And yeah, I believe it has pieces of code from all around the place

I would advice against moving the physics body using units, and instead use proper velocities. This was an old test of mine, but I still use pretty much the same way of doing it myself. The reason why is, that it is the only way (At least that I know of, after countless tests) of getting smooth, predictable movement for multiplayer projects. You can't step ahead or instantly reapply inputs using Cannon, and Cannon is not deterministic when it comes to different browsers and architectures. This is far from perfect, but it's the best at least for me. Enough hijacking of the thread

Using velocities instead is trivial and takes seconds to implement. I'm not quite sure what he is after, though. I have a hard time wrapping my head around it.

[Wingnut]

Thx R.  I think Nick is after exactly what you built... camera on a bumper car.  Oh, I guess that was in a different thread by Nick.  This thread just wanted to find more-elegant ways to move the physics impostor/mesh... in the same direction as the camera is aimed.  Your demo does that nicely, too.  Even if we don't exactly understand what Nick wants, everything he could possibly need... is inside that demo... somewhere.  It's good stuff... thanks for making it.

Speaking of physics-active spheres...

    ...we sometimes see them guys in bars/taverns... with the really big beer-belly.  When they walk-up and start talking to you, their belly arrives first, and it knocks the drink out of your hand, and might even bump into YOU, and send you flying across the bar. 

Belly-Bumper v1.0.  Physics-active beer belly.  It can actually blaze a trail through a jungle... if you can get ol' beer-belly to run a little... get some momentum going... for knocking-down the BIG trees.   

Others... tilt the camera down... in Raggar's demo.  You'll see the beer belly sticking-out, there.  heh.  Use @JohnK's fur shader to put some hair on it. 

[nicktendo]

@Deltakosh Yes, I will summarize my intentions more clearly in a following post with an updated example

@Wingnut Thank you for the amazing feedback, incredibly comprehensive and useful!

@Raggar Great advice to use velocities instead of units