solved Can You Get Normalized Velocity

[MackeyK24]

Please forgive the 'newbie' question... But...

Can I always calculate a normalized value between -1 and 1 from the the current mesh moving velocity ???

The reason I ask.. I am creating blend tree support for animations (GOING GREAT SO FAR)... but the premise of all th docs for update the PosX and PosY comes

from pumping the "User Input" horizontal and vertical input which will be -1 to 1... Which is Kool for when you are directly controlling the character, but lets say I am moving a character around thru AI and not using user input... I would like to just take the velocity at which I am moving (Which I can now easily get via my new Character Controller component I showed before) which may be larger than 1 because of all the speed and jumping force applied (I THINK ???) and 'normalize' that velocity x and y to -1 to 1 and feed the to the blend tree input as if it came directly from the user input axis device... That what mu Animation State component could just play the 'current movement' animation for both directly controlled and ai controlled movement...  I think... dunno... What do you guys think ???

As Always, pinging @Deltakosh 

[SvenFrankson]

Not sure if I understood your question well. It's a generic question or you have a use case in particular ?

Anyway, when doing this kind of thing (sharing code for animation or physic between human and AI), I'd rather have the AI returning inputs (-1 ; 1 values) than moving the object with translate / rotate / addForce

(the translate / rotate / addForce being the same code for human an AI)

Here, I'm not sure you can tell the object velocity (or normalized velocity) is equal to the input (or input direction), or it would mean your object has no inertia.

[jerome]

velocity.normalize();

 

[MackeyK24]

37 minutes ago, SvenFrankson said:

Not sure if I understood your question well. It's a generic question or you have a use case in particular ?

Anyway, when doing this kind of thing (sharing code for animation or physic between human and AI), I'd rather have the AI returning inputs (-1 ; 1 values) than moving the object with translate / rotate / addForce

(the translate / rotate / addForce being the same code for human an AI)

Here, I'm not sure you can tell the object velocity (or normalized velocity) is equal to the input (or input direction), or it would mean your object has no inertia.

You are probably right about physics vs translate position or even moveWithCollisions might be better for ai... but the vector.normailze() work great and now I know how... even if I move with some other means than physics

I might even add a 'Switch' to the character controller to move with either Physics or Collisions (basically mesh.moveWithCollisions instead of mesh.physicsImposter.setLinearVelocity)

[MackeyK24]

Shit man... I think mesh.physicsImposter.getLinearVelocity is ALREADY normalized -1 and 1... Is that correct @Deltakosh or could it just be the CURRENT values I see even when in running state are less than 1.0

 

[adam]

1 hour ago, MackeyK24 said:

mesh.physicsImposter.getLinearVelocity is ALREADY normalized -1 and 1... Is that correct

No

[MackeyK24]

6 minutes ago, adam said:

No

K.. thanks @adam ... but I can use getLinearVelocity().normalize() ... Right ??

[Wingnut]

Can I butt-in, as always?    Mack... don't velocities have "magnitude"?  If you normalize them, you have nulled their magnitude, I suspect.

And, setLinearVelocity will not STOP moving ever... if friction/mass are low. 

MoveWithCollisions() is not similar at all, except that ITS magnitude is used as a distance-to-move, so you can't normalize that one either.

(Wingy checks Mackey's Normalizer's License to make sure it is up-to-date.)  heh

Ok, I'm done butting-in now, and I hope I didn't say something incorrect.  Be well.

[adam]

2 hours ago, MackeyK24 said:

K.. thanks @adam ... but I can use getLinearVelocity().normalize() ... Right ??

I also don't think you want to normalize velocity itself (in place).

You probably need to use Vector3.Normalize or Vector3.NormalizeToRef:

https://github.com/BabylonJS/Babylon.js/blob/master/src/Math/babylon.math.ts#L1662

[MackeyK24]

1 hour ago, adam said:

I also don't think you want to normalize velocity itself (in place).

You probably need to use Vector3.Normalize or Vector3.NormalizeToRef:

https://github.com/BabylonJS/Babylon.js/blob/master/src/Math/babylon.math.ts#L1662

Gotta .. DONT change the original velocity... Thanks...

I got another one.. I need to set the ZERO the Y angular speed on a Quaternion... I don't want it to have Y rotation...

I can't just set quaternion.y = 0 because that false in computing the matrix... I am still a little FUZZY on my quaternions

 

[MackeyK24]

10 minutes ago, MackeyK24 said:

Gotta .. DONT change the original velocity... Thanks...

I got another one.. I need to set the ZERO the Y angular speed on a Quaternion... I don't want it to have Y rotation...

I can't just set quaternion.y = 0 because that false in computing the matrix... I am still a little FUZZY on my quaternions

 

Never mind .. Im tired I guess... I get em, this works:

 

Quaternion rotation = transform.localRotation;

if (animationState.zeroRootRotations) {

Vector3 vec = transform.rotation.eulerAngles;

rotation = Quaternion.Euler(vec.x, 0.0f, vec.z);

}

 

[MackeyK24]

4 hours ago, Wingnut said:

Can I butt-in, as always?    Mack... don't velocities have "magnitude"?  If you normalize them, you have nulled their magnitude, I suspect.

And, setLinearVelocity will not STOP moving ever... if friction/mass are low. 

MoveWithCollisions() is not similar at all, except that ITS magnitude is used as a distance-to-move, so you can't normalize that one either.

(Wingy checks Mackey's Normalizer's License to make sure it is up-to-date.)  heh

Ok, I'm done butting-in now, and I hope I didn't say something incorrect.  Be well.

 All I'm really trying to do is get the Blend Tree input PosX and PosY to come the character controller ( horizontal and vertical input direction) instead

of just coming from the user input device ... it is expecting things to be in the -1 to 1 range., thats all... just plain around to see what works

 

[Wingnut]

*nod* thx.  Direction is cool, I can understand why that might be normalized.  But "moving"... that's thrust... and thrust needs a magnitude.  I can turn my outboard motor in some direction, and normalized or not, it will be the very same direction.  But when it comes to adding +25 thrust on the z-axis, perhaps avoid changing that +25 thrust... to +1 or less. 

I would immediately check if my propeller fell off.    (Wingnut, you're SUCH an idiot.)

[MackeyK24]

11 minutes ago, Wingnut said:

*nod* thx.  Direction is cool, I can understand why that might be normalized.  But "moving"... that's thrust... and thrust needs a magnitude.  I can turn my outboard motor in some direction, and normalized or not, it will be the very same direction.  But when it comes to adding +25 thrust on the z-axis, perhaps avoid changing that +25 thrust... to +1 or less. 

I would immediately check if my propeller fell off.    (Wingnut, you're SUCH an idiot.)

Yeah you know I should have clarified that... I am really trying to use the current movement velocity (normalized) as a direction instead taking the direction only from user input... I don't give crap how much velocity ... but so I can tell in which direction and use the for PosX and PosY input on the Blend Tree

 

[Wingnut]

On 8/30/2017 at 7:53 AM, Wingnut said:

MoveWithCollisions() is not similar at all, except that ITS magnitude is used as a distance-to-move,

I was wrong about that.  It is a velocity, not a distance.  Sorry.  I should read the docs someday. 

Update:  Now I have discovered that it IS a "distance" but it is simply named velocity.

Admin:  Delete this post at will.   

[Pryme8]

velocity : "the speed of something in a given direction."
moveWithCollisions fires once right and is a set distance when it does?  I do not think the wording in the docs are correct then to establish speed you need time, otherwise you just "teleport" something instantly which technically is happening between frames.  You only simulate it having speed when you do it over multiple frames, because if I move something 100 units in one frame that's like a ton of units per second in speed but if I move the it over 1 second that 100 units its 100 units per second.

 

I mean eh its kinda velocity, but at the same time its not but it is but its not.  I would need to do drawing to demonstrate this better...

[GameMonetize]

Please dear friends, can you fix the documentation? I'm gonna rename the parameter to direction

[jerome]

mmmh... what I read/understood so far in some physics doc, etc would be rather imho :

velocity : a vector with a direction of a magnitude of the speed

speed : the magnitude of the velocity vector

direction : the normalized vector of the velocity

actually this is how we would also say in french

[EDITED] this one doesn't require any translation :

//  assuming that direction is normalized
velocity = direction.scale(speed);

[Wingnut]

Are we exercising DBC?  (decision by committee)  The world's slowest and most-emotional (yet fairest) decision-making system known to man? 

I abstain. 

Actually, direction doesn't feel right.  Over in another thread, satguru called it a displacement.  I thought that was an interesting term... and quite apropos.  But, it might not fit 3D world "conventions".  Perhaps offset?  *shrug*    Should I shut the heck up?   I'm thinkin' "yeah".  heh

 

[satguru]

When I used the term "displacement"  I did not realize it then but now when I google it up I find it has a very precise definition
"Displacement is a vector. This means it has a direction as well as a magnitude and is represented visually as an arrow that points from the initial position to the final position. "
from https://www.khanacademy.org/science/physics/one-dimensional-motion/displacement-velocity-time/a/what-is-displacement
I would think perfect for moveWithCollision
I suspect those physics lessons from school are still floating around somewhere in my subconscious mind.

[MackeyK24]

6 hours ago, jerome said:

mmmh... what I read/understood so far in some physics doc, etc would be rather imho :

velocity : a vector with a direction of a magnitude of the speed

speed : the magnitude of the velocity vector

direction : the normalized vector of the velocity

actually this is how we would also say in french

[EDITED] this one doesn't require any translation :

//  assuming that direction is normalized
velocity = direction.scale(speed);

except I want the direction from the velocity ... Is guess that would be direction = velocity WITHOUT the magnitude ... so could you 'SCALE' the other way

direction = velocity.scale(someSpeedScale) or what ever to take of magnitude and end up with direction from -1 to 1 ???

 

[MackeyK24]

Shit... I put this code in for connivence 

 

public getDirectionVector(owner: BABYLON.AbstractMesh | BABYLON.Camera, vector:BABYLON.Vector3):BABYLON.Vector3 {
    return owner.getDirection(vector);
}

 

 

I think I can just use that to get the direction of the 'vector' that hold the velocity... Right???

 

[satguru]

@MackeyK24 don't see whats wrong with doing "direction=velocity.normalize()" 

[Pryme8]

And 

magnitude = velocity.length()

i think...

[jerome]

yep, all are equivalent

velocity = direction.scale(speed);
speed = velocity.length();
direction = velocity.normalize();