Mesh keeps being confined in the other mesh (moveWithCollision)

Hi, i am having trouble with using moveWithCollison method.
moving internally generated knot -> works well
-> moving imported box mesh -> moving is weird and stuck at wall

I checked face normal, wall thickness, ellipse size.
what’s happening here?

Hi S!

Forum friend @peoro may wish to read/participate in this, so I will ping him/her, here, too.

Ok, let’s see. The type of collision system you are using… USUALLY doesn’t use a mesh parented to cam. The camera has its own collision ellipsoid, so we can simply set camera.checkCollisions = true.

Side note: We also have camera.applyGravity = true available on this camera… and there’s a secret private property… umm… camera._needMoveForGravity = true… which will start the camera falling when the scene is loaded (fall to floor/ground at scene-startup). Research this before using… I could be wrong… and private property usage (prop names with underscores) is discouraged… but it’s fun just the same. :slight_smile:

Anyway, I disabled the ‘character’ in line 111, so we could test the freeCamera’s ellipsoid. Seems ok. Feel free to adjust the camera.ellipsoid (size) and camera.ellipsoidOffset (position shift)… as wanted. I believe the values used in camera.ellipsoid x/y/z… are “radii”. Half-diameters. Research, as needed.

Other things done:
Lines 3-57 - testing some mesh & camera showEllipsoid funcs. Ignore or delete… they don’t work well.
Line 71 - set smaller camera.minZ to eliminate camera-frustum “get too near” clipping.
Line 72 - turn off WASD keys - we’ll use cursor keys.
Line 74 - turn on freeCamera collision checking.
Lines 102-104 - enable edgesRenderer so we can see some room “corner lines”.
Lines 107-108 - expand the house :slight_smile: Nice if REAL houses expanded this easy, eh? :smiley:
Line 111 - disable the character mesh.
Line 148 - delete this please. It was an attempt to make the camera.ellipsoidMesh (part of disabled showEllipsoid() tests)… move WITH the camera. Not needed.
Line 151 - testing line… remove as wanted.

The most important improvement? No “stuck in collision” problems. Getting “stuck in collision” is fairly common with this type of collision system… but… so far… in this adjusted playground… I see no sticking. YAY!

Do you ever wonder HOW MUCH camera-angle is needed (after camera->wall collision)… before continued up-cursor makes camera “slide” along wall?

You know… what angle makes camera stop, and what angle allows it to slide? THAT value… can be adjusted (maybe)… with value of engine.CollisionsEpsilon .

IF you would have used a physics engine (we have interfaces for Oimo, Energy, Cannon, Ammo), THEN you would need to parent a mesh to the camera.

For your type… (free cam-based with built-into BJS collisions system)… no need to parent mesh to cam. Cam IS the player. Later, if you allow “follow view” in your game, we will need to re-think player-mesh and collision systems, again.

Ok, I hope I have been helpful. Feel free to comment and ask more things… no problems. At least you have another version of the testing playground. :slight_smile: Party on!

PS: .moveWithCollision() MIGHT be able to be removed, as that is a mesh-mover. You can probably use ONLY the camera’s cursor-key movements. In other words, you can remove the entire scene.registerBeforeRender() (pg #14)

Tech Note: There is a newer way to do scene.registerBeforeRender. It looks like this:

     put stuff here...

BJS “observables” system… is super nice… you’ll love it, eventually. :slight_smile: We have LOTS of observables, and you can even create your own custom observers and observed-event listeners/notify-lists.


Thank you so much.
i’ll review code line by line. :smile:

1 Like

I sensed that you were working on jumping. :slight_smile:

Spacebar to jump. :slight_smile: scene.gravity, camera.applyGravity, and camera._needMoveForGravity… all active. I’m not too good at these gamer things… so perhaps better methods are available. :slight_smile: This currently allows multiple spacebar presses… and player could accidentally be hit by an airplane… if jumping too high. :slight_smile:

I used a cute little camera-overload animation method (moveTo) up in lines 3-7. Probably dangerous. :slight_smile: The last number in line 74 set the upward animation speed, and scene.gravity.y sets the fall speed. Line 74 also sets the height of the jump… currently at 20.

Line 5 EASEINOUT could maybe be changed to EASEOUT. Most jumps start at high speed but taper-off at top of jump. Currently, it also eases-into the jump, so the jump ends AND starts slow. You might want it to only end slow… but start fast.

1 Like

You are surprising me. Thanks!

1 Like

For jumping, changing scene.gravity.y and applying acceleration worked.
(Although it has potential problems) :smiley:

1 Like