moveWithColisions() question

[satguru]

All this time I have been treating the "mesh" function "moveWithColisions" as a function which moves a mesh by certain distance along a vector.

But when I look at the class doc,  it is defined as "moveWithColisions(velocity)".

Is it velocity or distance?

[Dad72]

This is a velocity  (vector3)

let forward = new BABYLON.Vector3(Math.sin(parseFloat(this.actor.rotation.y)) / 15, 0.15, Math.cos(parseFloat(this.actor.rotation.y)) / 15);
this.actor.moveWithCollisions(forward.negate());

 

[Wingnut]

I better go fix my other thread, where I said it was a distance. 

[satguru]

how is this velocity?

velocity is speed and direction. What is the speed measured in ? units/s ?

if I do

moveWithColiisions(new BABYLON.Vector3(200,0,0));

The mesh moves  200 units immediately and then stops.

So don't think  the speed is 200 units/s.

 

 

 

 

[Pryme8]

well a vector represents direction and magnitude, velocity is distance over time, and distance is a measurement of length.  Magnitude can be translated to velocity...  I don't know where I am going with this...

Anyways, I think its units per step/frame but I may be mistaken.

you can control it a little better with this though:

var speed = 200;
var direction = Vec3(1,0,0);

moveWithCollisions(direction.scale(speed));

now if you want true "velocity" you need to have inertia and drag play into your calculations at some point unless you are simulating 0 gravity and a vacuum...  

starting to realize I am off topic... uh I think the answer to your question is per step so with a speed of 200 and 60 fps it would be like 12000 units per second (unless you have multiple steps per frame) so then your velocity would be that divided by what ever you scale is.
I hope this is not rubbish, I am like heading out the door and did not read over anything so I hope this helps and is not wrong.

[Wingnut]

I followed a trail... could have been lost... but I found this...

https://github.com/BabylonJS/Babylon.js/blob/master/src/Collisions/babylon.collisionCoordinator.ts#L402

Adding the velocity to the position.  hmm. 

I got there from here...

https://github.com/BabylonJS/Babylon.js/blob/master/src/Mesh/babylon.abstractMesh.ts#L1544

I think the French Fries are asleep right now... it's around 3 AM over there.  Look at dad72... layin' there, snorin', droolin', dreamin' of sugar plum faeries. 

Should we bring the JS source code (for those 2 funcs) into the playground, and start doing demented experiments?    (evil laugh heard)

[satguru]

@Pryme8, Yes it would seem it is units/frame  but you have to keep calling that function every frame. It's not as if you call it once and it keeps moving along that vector henceforth.

If you remove collision from the picture then it same as just setting the position of the mesh every frame.

Calling it velocity is stretching it a bit.

@Wingnut, the code you point out , seems to be just setting the position. Do not see time anywhere.

17 minutes ago, Wingnut said:

I think the French Fries are asleep right now... it's around 3 AM over there.  Look at dad72... layin' there, snorin', droolin', dreamin' of sugar plum faeries. 

Funny!

[Wingnut]

10 minutes ago, satguru said:

Calling it velocity is stretching it a bit.

  I agree.

10 minutes ago, satguru said:

Do not see time anywhere.

Me neither.  I think it's runnin' wide open, and perhaps happening faster than once per frame.    (like I'd know)  Actually, I mean EACH step of a moveWithCollision... might be happening faster than once per frame.  I hear webworkers COOK, speed-wise. *shrug*

[Wingnut]

Wanna go deep on the colliders?  https://blog.raananweber.com/2015/05/26/collisions-using-workers-for-babylonjs/

Barrels Playground - an almost-tolerable testing playground.  WASDQE and shifted-WASDQE... all driven by moveWithCollisions.  Watch out for keypress repeating. 

One more thing you should probably know, if you don't already.  BJS collision system was designed for camera-to-mesh collisions.  Thus... moveWithCollisions() existence, in itself... is a stretch.  It is a mesh mover, not a cam mover.  And with enough testing in the barrels playground, you will see that vertical collision between two mesh... is not accurate.  (bring one barrel down atop another, or bring one up from beneath another - using Q/E or shifted Q/E.)  (It could be a Wingnut coding mistake, too)

I thought you might want to know this, SG.  I'm just talkie today, actually.    Dad72 and Deltakosh were out power-drinking one night, and Dad72 scribbled some mad-scientist idea on a bar napkin, and DK said... yeah, let's go build that... and then they stumbled back to their mad-scientist lab and created moveWithCollisions. (and then all the small animals around the lab... died). 

[Aerion]

@Deltakosh I would seriously LOVE to see a slope controller with a PROPER camera like the exact Camera used in Lord of the Rings Online, created for  the purpose of traversing VERY large terrains without letting the player cheat their way to victory by being able to gain access to certain areas due to "Mountain Climbing / jumping", earlier on in the game! A way to MIMIC the EXACT functonality of the Lord of the Rings Online Camera, and a way to finally CONTROL Terrain-Player influence without sliding all the way OFF the terrain! <3 A way to CONTROL the slope angle & the gravity / slipperiness of the player when ON steep slopes! <3 A small patch to the Babylon.js script would help out SO many people! <3

[satguru]

@Wingnut I remember coming across that link about a year back and making a mental note to revisit that later on but forgot all about it. Thanks for providing the link. I definitely want to understand that better and @RaananW writes well. I also remember reading somewhere on the forum that  Dad72 originally came up with the idea of  moveWithCollision. Nice of him.

Anyway the impression I get is that WebWorker just deals with collision  and does nothing  as far as velocity is concerned. 

@Deltakosh am I wrong in treating velocity as just displacement?

 

 

 

[GameMonetize]

You are not and velocity is probably the wrong word here. It is the distance you want to add to your current position.