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.