Tying a Camera to a Bounding Box

Questions
1

So after creating this (please excuse the ridiculous amount of commented out code):

And reading this (and many, many, many other forum posts):

I came to the conclusion that I am going to need to implement physics for the FPS player. I too was running into a similar issue where my camera just kept sliding down slopes and it was very annoying. I want to somehow bind the camera to an invisible ellipsoid with a bounding box such that I can add friction to it (I think?) but for the life of me I cannot find an example doing this and have been slamming my head into my desk for a couple of hours now trying to think about how to approach this.

Would any of you fine folk happen to know how to attach a camera to an object? I am well aware that this means disabling the nice functionality provided by the camera movement and will have to implement my own in regards to moving the bounding object but I am willing to tackle this challenge.

Sincerely,

Tyrfull

2

Hiya Tyrfull! Ok, you found the sliding slopes thread… which @givo and I and others got brain tumors -with… good good good.

And, you’ve seen https://www.babylonjs-playground.com/#IFN77Q#33 I suspect… camera attached to physics active box… with testing ramp. In fact, that whole 77Q series of playgrounds… is full of experiments… likely well-past #33.

My initial advice is to NOT think about bounding boxes… but instead… think about regular physics-active box… with box.visibility = 0;

That playground… in which Givo turned-on some pointer-locking and some other strange mousemove listener… is a good test scene. It has an extra side-view cam… so we can watch the primary cam (with physics box)… as it does ramp-climbing/descending duty.

WASD keys move the cam-box, and so does mouse panning. Use the W key to drive the box up onto the ramp. Notice the limited backsliding… sort of like… if player stands real still on the ramp, they might not backslide. Press A or D or spacebar… or pan camera left/right while on ramp… and they WILL start backsliding. THAT… is pretty close-to real life standing-on-a-ramp characteristics, eh?

When everything feels good, and ramp angle tests are done, along with whatever applyForce/applyImpulse “thrust power” feels right… you simply set box.visibility = 0.

This is NOT a simple project… and before Givo requested it… I have never seen it… much. I think… @raggar did some work on climbing/back-sliding our “Dude” model… up a ramp… some time ago. Maybe that was @fenomas. Hopefully these guys will come visit the thread and teach us what they have learned.

Also, I think fenomas was working on something here: https://www.babylonjs-playground.com/#U4F9K1#4 with a thread on our old forum… here: Physics Movement - Questions & Answers - HTML5 Game Devs Forum @MackeyK24 was involved, too, of course.

Now, are you going to allow follow-cam/third-person-view/chase-view… of your player? In other words, will the player be seen walking, so it needs to be an animated armature human-like complex model? If so, this whole cam-box idea… might suck. But maybe not. Maybe just parent the animated character to the invisible box, change the camera to chase/follow position, and things will be fine. Not sure.

The challenge might be… changing the speed and footstep stride-distances of the player armature/animation… based upon the linearVelocity of the physics box… which we could call the ‘p-box’ to make typing easier. During times of full thrust (physics applyImpulse/applyForce/setLinearVelocity)… the player’s legs will be moving fast and with long strides. When we kill the thrust, the player should use shorter and shorter step-strides… until the p-box and the player’s leg animations… stop completely.

THEN… the backslide (if player is climbing a hill). For the p-box… it’s just a friction-active (and gravity affected) physics slide… box against ramp/heightMap. But for a player armature/anim… backsliding COULD use little foot-shuffles. When a real human starts sliding backwards on a hill, their legs and feet are often moving frantically, trying to get a better toe-hold to stop the sliding. This is not easy to sim. A REALLY good simulation… would constantly watch the p-body’s linear and angular velocities… and move/animate the armature’s legs… based upon those values.

In a way, it is like “castoring”. The movement force… comes from an external source. The armature animation… reacts to those external forces. It will take some heroic armature animation coding… to get that looking good.

FPS - first person shooter… is easier. No viewing player from follow/chase view.

@dad72 went down this trail… too… but without using a physics engine. He and Deltakosh invented the mesh.moveWithCollisions() method… for use with the built-in collision system… and it was never really meant to be used like that. It can get stuck in collision state, and/or jitter when pushing against a collider. It has some issues. Nobody has been able to get rid of those problems… yet. Nobody works on them, as far as I know.

The built-into-BJS freecam->anymesh.checkCollisions = true system… was ONLY meant to be used for freecams colliding with collide-active mesh… and NOT for colliding mesh against other mesh, like .moveWithCollisions() does. Also, the built-in collisions system… uses ellipsoid-shaped colliders… which will try to climb over low-height obstacles… but scene gravity pulls it back to ground… over and over… causing jitter… for freecam and for mesh.moveWithCollision. IF the collider shapes were cylinders instead of spheres, that problem would be gone. Not sure if possible. AND… CAN a cylinder-shaped collider go up a ramp? Maybe not… unless the ramp has a gradual/smooth entry onto it. Otherwise, bottom edge of cylinder collider… might “catch” on ramp-edge… reading it as an obstacle collision (all stop).

Side-learn: The user-setable float value of a property called engine.collisionsEpsilon is involved with those jitter-causing “collider scrub-off angles”. Example… you nav a freecam into a collide-active wall… at some angle that is NOT 90-degree perpendicular/orthogonal. THEN you keep pushing forward with the cam collider. Does the camera “scrub” or slide along the wall… in near constant collsion? Or does the camera refuse to move… blocked by the wall? The NEEDED ANGLE to start “scrubbing”… is set by engine.collisionsEpsilon. Careful. This value ALSO affects the scrub-off angles for the top and bottom of player/cam collision ellipsoid (duck-under and climb-over scrub-off angles).

Ok, I guess I’ll stop, here. I’m far from a pro, and on THIS subject, there may be no pro’s in-sight. I would say… go find the lead programmer for a game that “does it right”… and just blatantly BEG them for the likely-not-JS code… which you will need to convert to slower JS. Problem is… this might be one of the more difficult things to do in a third-person shooter (such as Serious Sam in follow-view mode). THUS… the lead progger might not let others see/have that code. And it might be too slow for a JS version of it. Dunno.

SO much to think-about, eh? nod. I hope I’ve been helpful. Stay tuned, maybe others will comment soon. Here’s a link to a search for ‘ramp’ on our old forum.

1 Like
3

@Wingnut,

Wow, thank you so much for taking the time to answer my question and so thoroughly. I had not seen that 77Q series! That will help a lot. I am mostly doing FPS without third person or over the shoulder view. More in line with what @TiagoSilvaPereira did in his FPS. I might have to go beg the people over at bluewizard.com for some advice.

I think this was very helpful. Thank you so much!

Sincerely,

Tyrfull

2 Likes
4

Cool. Yeah, I would take some time to learn about the non-physics engine free-camera-based built-into-BJS collision system, if I were you. Yes, it makes freecams slide down almost EVERY incline, based upon scene.gravity.

But let’s say you left collisions ON, but turned OFF gravity. THEN… how do you keep the user from flying the freecam… without gravity holding it to the ground?

By force, that’s how. :slight_smile:

scene.onBeforeRenderObservable.add(function() { 
    // maybe best to use a ray... for distance from surface to surface... but... 
    var distanceToMeshBelowCam = camera.position.distance(ground.position); // (something like that)
    camera.position.addInPlace(-distanceToMeshBelowCam);
}

That probably won’t run… untested… but… you get the idea. You force the camera to stay on the ground, or on the box that the player is standing upon, or whatever. You could use a BJS “ray” to shoot downward under the camera, reporting what mesh is under the camera, and maybe even get a “face normal” (the angle of the facet that the ray hit).

I think @jerome has a .heightAboveGround() thing here somewhere, too. I can never find it when I need it, cuz I can’t remember its name. But its a fine-working function… might work on freecams.

If you keep camera collisions ON… you might have handy camera.collider.onCollide event/observable to use, too. You could set ground.checkCollisions = false. THEN… you can move the camera.position in any way you like, and never worry about it rubbing against the ground. You’re only concerned when it rubs against a telephone pole, right? So, camera.applyGravity = false, camera.checkCollisions = true, scene.gravity = null, ground.checkCollisions = false. THEN, YOU take over all gravity and sliding done by camera-against-ground… all faked. :slight_smile:

All sorts of advanced “test the mesh under the camera” can be done… each renderloop frame… Tyrfull’s Custom FreeCam Gravity’n’Friction System v1.0 (with new tumble-a-freecam-down-a-hill feature) :slight_smile: You could become famous! FreeCam Bowling - a motion-sickness-inducing game! :slight_smile:

PS: In case you get the idea to use a sphereImpostor as your physics thing for the camera… remember that sphereImpostors have very little surface-area touching the ground’s impostor, so friction… essentially, doesn’t work at all. For sphereImpostors that just won’t stop rolling or sliding… there are linear and angular “damping” available on our physics plugins… and maybe even a fixedRotation to stop the sphere rolling. BUT… setting a fixedRotation or high angularDamping on a camera-holding sphereImpostor… CAN prevent the camera from panning and tilting. Lots to learn… if you feel you need to use a sphereImpostor under the camera.

5

Alright so I have been working on this slowly over the past few days so please pardon the late (reeeeeally late) response. I have abandoned the idea of slopes and instead just made stairs that are small enough for the camera to just kind of jitter over them (eh I’ll fix it later…)

So now I have a new question. But I will post it in another thread. Thanks for the help though! It was a cool thought experiment and maybe later when I am not pressed for a deadline I will implement it.