solved Pick Up Mesh with Physics

[Nutiler]

Hello! I am new to these forums and I just have to say Babylon.js is now one of my favorite libraries for webGL.

I have finally switched over from three.js and have to say this has been so much fun to play with.

 

Just recently I am trying to make a physics-based environment where you can pick up and drop objects similar to the old source engine and garry's mod.

I created this playground to show an example of what I am trying to create but some of the bugs are shown in the gyazo link.

 

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

https://i.gyazo.com/bc01aaaced057c158f1c925cfafc06a2.mp4

The object, when held and looking downfalls through the floor. Sometimes when dropped it becomes at a sliding state where it will not stop sliding and on pickup, it will fall through the floor.

 

So my question is, how can I stop the object from going through the floor?

[RaananW]

Hi @Nutiler,

Welcome to the forum!

My first recommendation would be not to recreate the physics impostor every time something happens. Physics Impostor should be set once and used throughout the game.

Your pick mechanism is interesting  You are using the camera as a parent. It would be better if you created a mechanism without the camera as a parent, keeping the object away from it, while setting its own position constantly. This way, the physics impostor will be have the position set and will be able to interact with the rest of the scene.

Does it make sense?

[Aerion]

I've been looking for one of these! Please post a demo when you figure out the problem!

Ty! <3

~M

[Wingnut]

Hi gang!  Welcome aboard, Nutiler.

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

I did a little screwing around.  I removed all pickup/camera parenting, and calculated a diffFromCamera... which is the POSITION "offset" between the camera and the pickup.  In the before-render loop, I'll use that to maintain a "positional relationship".  (fancy-sounding, eh?) 

And, I added an isCarried flag on pickup.  In line 99 in the renderLoop, I check .isCarried to see if pickup.position needs to "track" camera.position (X and Z only, not tracking camera Y position).

I also added canvas pointerUp event as an extra "drop" fallback func.  As Nutiler states, onPickUpTrigger does not work when mesh has departed from beneath/behind pointer. 

I'm not a wonderful coder or idea guy, but it's something to play-with.  You can now use camera cursor keys while pickup.isCarried = true.  Pickup will travel along with camera, without the need for parenting pickup to cam. 

Notice I did not remove impostor for isCarried = true. I just removed the impostor's mass during the carry.  I'm not sure how to allow camera turning-while-carrying, yet.  Perhaps Nutiler's idea of de-impostoring and parenting pickup to cam... is actually a good idea, here.  hmm.  Still thinking. 

This ALMOST seems like a job for... Invisible Camera Spatula V1.0!  Or perhaps an invisible "boom"... like a microphone stand boom-arm.  When user clicks on pickup, an invisible arm that is parented to camera... is created/enabled/sized, and then extended to a position just above the pickup.  Then, perhaps, a physics lockJoint is created between boom-arm end-effector/connector, and top of pickup.  Since invisible boom arm is parented to camera, pickup (when isCarried) should both move-with, and turn-with the camera.  Camera with a crane arm.    hmm.  Interesting challenge!

There is the "smart mesh" approach, too, where the mesh itself has a brain (its own render loop), and knows when it is carried, and knows when it is supposed to adjust its impostor's mass, and constantly watches and matches the camera movement IF it .isCarried.  An extension of standard mesh.  This is a demented Wingnut idea, so perhaps it is NOT a GOOD idea. 

[Nutiler]

Thank you all! I've seen some of your works and they have been helping me learn this library so I'm glad this community is so helpful! 

 

@RaananW
Yeah, I see what you mean by not having to recreate and remove it every time the object is touched. The reason I used the camera as a parent was I wanted to keep the object in front of the players face at all times similar to this:

https://i.gyazo.com/92bc24fe6af5eb7833c2ca09d4c82ff8.mp4

I'm having a hard time understanding how to build the mechanism but I see what you mean by keeping physics intact so I cannot just phase through the ground when looking at it.

Do you know of any playgrounds that use this type of interaction?

@Mythros
Of course! Once I get this functional I'll be sure to post the barebones for this project before making what I want out of this!

@Wingnut

Heya, I tried your playground and it seems to step in the right direction! Similar to what Raanan said where I don't remove the impostor and use a parent. 
The movement of the block is a little strange but seems to work and interact better with the environment.

I think I'll need to add better controls to keep the box in front of the player when rotating the camera.
Another playground I've seen between object collision I think will help me is this one: http://www.babylonjs-playground.com/#OMBOJ
since the object will go through but upon release will update and be like "help I'm trapped inside another object" and shoot out
https://playground.babylonjs.com/#0H29AJ#5

The arm idea sounds great as well, that's almost exactly how I need to do this. I would like to have the ability to rotate the object so if the object is hanging from the arm that would make that job easier as well.

I do like the idea of the object being "alive" when you activate it, as of right now I'm messing with a couple ideas but I need to still look through playgrounds and tutorials to learn as I've only used this library for a day or so!
 

[Raggar]

How about this one?

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

W: Move the mesh farther away from the camera

S: Move the mesh closer to the camera

Q: Rotate the mesh clockwise

E: Rotate the mesh counter-clockwise

Not sure it's the best way of doing it. And quaternions and vectors might be reusable instead of creating new ones every frame.

[Wingnut]

Hi guys.  Good to hear that we're on the right track.

@Raggar, you might have a confused objective.  The camera is the player.  When camera-player picks-up the box (held left button), and then turns the camera with the mouse, the box needs to stay in front of the camera.  No local-to-box translation or rotation is needed, but we need the box to "swing around" when camera turns.  (Effectively, leaving box located at same relative-to-camera place, same distance from cam, same orientation, but setting box pivot point to camera center.)

Pretend there is a crane arm on the front of the camera... with a mesh magnet on the end of it.   In my #4 playground, picking it lifts the box, then cursor keys will move camera left/right/forward/backward, and box is carried-along, as if it were attached to the end of an invisible boom extending outward from the camera.

We need the invisible boom to swing-around left/right, when the mouse turns the camera left/right.  Nutiler might also want the invisible boom to raise/lower when mouse tilts camera up/down, too.  Ideally, no matter what the button-down mouse does, the box stays directly in front of cam, at same distance (only when box is carried).  First-person view, with long invisible arms carrying the box.    No need to adjust mesh local rotation or distance from camera.

The objective is NEARLY... lift box off ground, and parent it to camera - unparent when dropped.  But we're trying to avoid parenting to the camera, cuz parenting an impostor is taking the box's motion... out-of the hands of the physics engine (over-riding the physics engine).  Something we prefer to avoid.  But temporary parenting, then un-parenting... has some possibilities, yet, perhaps.  kbye again.

[Nutiler]

@Raggar After playing with the playground these are great features and I like what you have done! As wingnut pointed out I would really like the object to look back at the player from the same state it was picked up similar to if it was parented. My next goal after that would be to rotate and move the mesh like you have done with WSQE.

I need to spend some time on this when I get home and just try a few of these ideas!
I think right now the goal for me is to prevent the objects from intersecting other objects or phasing through the ground, whilst also keeping its original position from being picked up state face the camera.

I appreciate the overwhelming amount of support I've received so far! 

EDIT:

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

I haven't had as much time to play with this but I really liked Raggar's playground and was testing out lookAt and billboardMode to keep the object looking at the camera which works but isn't as fluid as parenting the object but is probably for the better.

I think the biggest obstacle right now would be to somehow apply the same physics collisions as when the object isn't held. Right now when the block intersects another object it phases through it and moving it out gains this terrible velocity. I would ultimately want the mesh to not go into the object and instead make it kind of like it hits a wall where the player can get closer but the object will stop going into the ground or mesh like this: https://i.gyazo.com/92bc24fe6af5eb7833c2ca09d4c82ff8.mp4

[Raggar]

6 hours ago, Nutiler said:

@Raggar After playing with the playground these are great features and I like what you have done! As wingnut pointed out I would really like the object to look back at the player from the same state it was picked up similar to if it was parented. My next goal after that would be to rotate and move the mesh like you have done with WSQE.

I need to spend some time on this when I get home and just try a few of these ideas!
I think right now the goal for me is to prevent the objects from intersecting other objects or phasing through the ground, whilst also keeping its original position from being picked up state face the camera.

I appreciate the overwhelming amount of support I've received so far! 

EDIT:

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

I haven't had as much time to play with this but I really liked Raggar's playground and was testing out lookAt and billboardMode to keep the object looking at the camera which works but isn't as fluid as parenting the object but is probably for the better.

I think the biggest obstacle right now would be to somehow apply the same physics collisions as when the object isn't held. Right now when the block intersects another object it phases through it and moving it out gains this terrible velocity. I would ultimately want the mesh to not go into the object and instead make it kind of like it hits a wall where the player can get closer but the object will stop going into the ground or mesh like this: https://i.gyazo.com/92bc24fe6af5eb7833c2ca09d4c82ff8.mp4

You could do the same with, by simply setting the pickup's rotationQuaternion to that of the camera. But yeah, it won't take the current rotation of the impostor into account.

You could calculate the distance between the camera and the pickup when you pick it, to keep this distance, instead of using a fixed distance like I do. I'm not sure how that would work with the Y-axis, though

 

9 hours ago, Wingnut said:

Hi guys.  Good to hear that we're on the right track.

@Raggar, you might have a confused objective.  The camera is the player.  When camera-player picks-up the box (held left button), and then turns the camera with the mouse, the box needs to stay in front of the camera.  No local-to-box translation or rotation is needed, but we need the box to "swing around" when camera turns.  (Effectively, leaving box located at same relative-to-camera place, same distance from cam, same orientation, but setting box pivot point to camera center.)

Hmm. I'm pretty sure that's what my playground does. At least the first part, and with a fixed distance, and not one calculated based on the positions of the camera and the impostor. I might very well be wrong, though

 

On 10/5/2017 at 9:52 AM, RaananW said:

This way, the physics impostor will be have the position set and will be able to interact with the rest of the scene.

When setting the position, the interaction with other impostors is minimal. I guess you could use forces or impulses, but I tried with velocities, and it does seem to be a lot better at interacting with both static and dynamic bodies.

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

[Wingnut]

5 hours ago, Raggar said:

Hmm. I'm pretty sure that's what my playground does. At least the first part, and with a fixed distance, and not one calculated based on the positions of the camera and the impostor. I might very well be wrong, though

Uhn, yes you did.  Nevermind me... I'm recovering from some kind of hallucination or something.  hehe.  Sorry about that.  Apparently I didn't investigate your demo sufficiently.

Well done, Rags!   A little pickup.lookAt(camera.position) in the renderLoop, as an option, perhaps.  You bet!  I'll try to pay more attention, I promise. 

[Raggar]

4 hours ago, Wingnut said:

Uhn, yes you did.  Nevermind me... I'm recovering from some kind of hallucination or something.  hehe.  Sorry about that.  Apparently I didn't investigate your demo sufficiently.

Well done, Rags!   A little pickup.lookAt(camera.position) in the renderLoop, as an option, perhaps.  You bet!  I'll try to pay more attention, I promise. 

Could just as well have been me, dude

This is a fun project, though. #12 has the correct distance between the impostor and the camera, and #11's interactive physicsy handling with other impostors.

I'm using the camera's quaternion on the impostor. I'm unsure of how to keep the original rotation, while still rotating it accordingly to the camera. In a non-parenting way.

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

[Nutiler]

@Raggar

#12 looks fantastic! Wow. Thank you so much.

Everyone has had such good ideas this is exactly what I need to progress!

The only thing I'll be tweaking is making the object hold it's rotation on pickup but for now, it's a minor detail.

 

@Wingnut Thank you for your contributions as well, I've used so many playgrounds you've posted to learn, I'm starting to love this community.
 

 

[Aerion]

@Nutiler please release a #13! <3

[Nutiler]

13 hours ago, Mythros said:

@Nutiler please release a #13! <3

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

It's tons of fun to play around with!

QWER now rotate the object in hand, spacebar throws the object in front of the player.

On 60/FPS it feels very slow, so feel free to crank up the velocity & speed.

Line 135 applies the rotation I desire but I haven't had time to look at how to allow rotation while doing so!

 

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

Demo 13 wasn't enough fun... so enjoy playing a rigged game of basketball. I didn't actually hollow out the cylinder, which I should use createTube instead... but for now, enjoy the carnival game!

 

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

EDIT: It wasn't fair to post a broken game... I couldn't sleep so here's bowling. Walk back and then forward and release the mouse to roll it, or lob the ball with space.

 

I'll be sure to post a final demo once I get everything I have planned for this done.

Huge thanks to @Raggar and @Wingnut I really appreciate how much you have helped me!

[Wingnut]

Nice, nice, nice, Nutiler!  You're a natural with the physics.

I decided I would "attempt" a CannonJS version of the basketball game... so I could see if Cannon meshImpostor would work on the CSG-made rim (the hoop).

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

I changed all the xxxVelocity.set occurrences... to setXxxxxVelocity... so Cannon would be happy.  I have the meshImpostor on the rim.  But, the pick-up is not doing so good, yet.  Ball goes somewhere upon pick-up... not sure where. 

Anyway, in theory, the Cannon meshImpostor will work fine... for the rim.  MeshImpostor ONLY interacts with sphereImpostors... no problems there.

I don't know if anyone has ever tried a Cannon meshImpostor upon a CSG, or upon a tube.  Generally speaking, tubes have a difficult time activating physics on their inner walls (as far as I know).

I remember Raanan saying that he once "lined" a basketball rim... with many little impostors.  I think that was before we had a working Cannon meshImpostor.

Anyway, if anyone would like to repair my pick-up problems on this latest version of (Cannon) basketball, then we could see if the ball will actually go thru the hoop (the rim)... via using meshImpostor.  Then its onward... to the Mousetrap Game simulation.    Hey, meshImpostors only like sphereImpostors... so... we're in good shape.

Somebody... I can't remember who... did a LOT of work (and forum talk) on a ping-pong/table-tennis game, using Cannon meshImpostor modeled paddles and a nice table.  Each paddle was bound to have three variables involved in its rebound/restitution...  up/down tilt, left/right tilt, and forward/backward movement... for ball spiking/thrust.  It was a major, and tough project.  I think that coder is in a mental asylum, these days.  I MAY HAVE helped put them there. 

Congrats on your successes, Nutiler!  I hope you continue to hang-around with us.  You seem like a nice person with excellent creativity, tech-smarts, and dive-right-in gumption/spirit.  That's pretty cool!  I think you have done some of this stuff before.

We're going to start building (for-) you... a nice little mansion on Lake Babylon - well insulated for year-round residency. 

[Raggar]

You're very welcome, dude. It's always fun to play with demos like these.

And I've learned quite a bit myself playing with it, so it's a win/win

2 hours ago, Wingnut said:

Nice, nice, nice, Nutiler!  You're a natural with the physics.

I decided I would "attempt" a CannonJS version of the basketball game... so I could see if Cannon meshImpostor would work on the CSG-made rim (the hoop).

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

I changed all the xxxVelocity.set occurrences... to setXxxxxVelocity... so Cannon would be happy.  I have the meshImpostor on the rim.  But, the pick-up is not doing so good, yet.  Ball goes somewhere upon pick-up... not sure where. 

Anyway, in theory, the Cannon meshImpostor will work fine... for the rim.  MeshImpostor ONLY interacts with sphereImpostors... no problems there.

I don't know if anyone has ever tried a Cannon meshImpostor upon a CSG, or upon a tube.  Generally speaking, tubes have a difficult time activating physics on their inner walls (as far as I know).

I remember Raanan saying that he once "lined" a basketball rim... with many little impostors.  I think that was before we had a working Cannon meshImpostor.

Anyway, if anyone would like to repair my pick-up problems on this latest version of (Cannon) basketball, then we could see if the ball will actually go thru the hoop (the rim)... via using meshImpostor.  Then its onward... to the Mousetrap Game simulation.    Hey, meshImpostors only like sphereImpostors... so... we're in good shape.

Somebody... I can't remember who... did a LOT of work (and forum talk) on a ping-pong/table-tennis game, using Cannon meshImpostor modeled paddles and a nice table.  Each paddle was bound to have three variables involved in its rebound/restitution...  up/down tilt, left/right tilt, and forward/backward movement... for ball spiking/thrust.  It was a major, and tough project.  I think that coder is in a mental asylum, these days.  I MAY HAVE helped put them there. 

Congrats on your successes, Nutiler!  I hope you continue to hang-around with us.  You seem like a nice person with excellent creativity, tech-smarts, and dive-right-in gumption/spirit.  That's pretty cool!  I think you have done some of this stuff before.

We're going to start building (for-) you... a nice little mansion on Lake Babylon - well insulated for year-round residency. 

Seems to be due to the SetXVelocity function expecting a Vector3 instead of float/int values:

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

It does seem to work with the MeshImpostor. So no need to try out compound shapes or even convexpolyhydrons(Which I haven't played with yet. They scare me :O).

 

[Aerion]

Can you stop it from behaving irrationally when purposely trying to drag it through the floor?

[Nutiler]

12 minutes ago, Mythros said:

Can you stop it from behaving irrationally when purposely trying to drag it through the floor?

In #13-14 I haven't been able to shove the object through the ground with the current controls. 

With: distanceFromCamera = 4; It seems I cannot push the object through the floor, the farther away the object is the easier it is to push it through.

It kind of works as intended? In the Source engine prop killing was a problem due to this same effect when the object wants to go into the ground it'll eventually shoot out with a velocity when the environment says 'THE BLOCK SHOULDN'T BE IN HERE' and applies velocity to get it out.

https://i.gyazo.com/92bc24fe6af5eb7833c2ca09d4c82ff8.mp4

This is an issue right now and when I get it sorted out I'll be sure to post another, perhaps with another dumb physics game.

I think the object should react by retracting it's distance to the camera when it realizes it has nowhere to go. If you add collisions to the player you've essentially recreated prop-surfing.

The other issue is the rotation not looking at the player, it's difficult to tell when the object is a sphere though!
 

@Raggar I'm glad you've had fun with this! Playing your version on a higher refresh rate monitor makes it feel like light speed haha! I should have a toggleable FPS lock on this.

@Wingnut Just messing with this one project has me getting ready to drop everything I've worked on in three.js - this community itself is so great and I'm trying to learn the more in-depth tutorials and solved questions so I can help others on this forum!

[Raggar]

39 minutes ago, Mythros said:

Can you stop it from behaving irrationally when purposely trying to drag it through the floor?

What's irrational about a box jiggling a little when trying to force it through a solid ground?

[Nutiler]

1 hour ago, Raggar said:

What's irrational about a box jiggling a little when trying to force it through a solid ground?

I read this and immediately thought of "can I get a hat wobble box jiggle"

[Aerion]

Har har... Now back to being serious. the ability to stop objects from going completely haywire when accidently being drug across the floor can really come in handy for those of us that are serious about this demo.