Just leaving this as a resource for future self. If anybody else wants to add some goodies please do.
Also, if anybody might know of more references like this, please share. Right now, I only have a few youtube videos but I hate having to go scrub through them for reference. Seeing blueprints helps me a lot more than any descriptions or academic examples, hence I try to compile a little collection for myself.
First example isn’t vector math, but helpful anyway:
I have a lot of confusion with some of this terminology. The way it was described in some video I watched was also calling it local to world. But to my mind, this seems to be the opposite of what is happening.
Not saying I am correct - I am almost certainly not - but I just can’t understand this terminology, I guess.
Here is how I see things working:
So Vector offsets position is relative to the parent.
But debug sphere interprets it as world space, so if I don’t add the parent actors location back to offset the difference, it would just be drawn in world space.
So, it seems to me that I am telling unreal to convert that local vector to a world vector? When I do the addition, what I am essentially saying is, “add the parents location as an offset” which sort of describes the parent/child relationship mathematically?
In other words, maybe disregarding the debug sphere stuff, if i parented ActorA to ActorX - meaning ActorA is ActorX’s child and should follow ActorX - then what basically happens is that each tick, ActorA’s gets ActorsX’s world location added to their own, resulting in the offset from the parent being maintained?
So here, if I did not add the parent actors location, then the Line Start location would be somewhere out there with no relationship to the parent actor.
Therefore it seems to me that this addition is adding an offset which converts from some arbitrary world location, to a new location that has relationship to the parent (the offset that has been added).
this is wrong… adding vectors will always result in another vector in the same frame you are applying it. Transforming vectors involves their respective rotations.
In my game, I adjust the player characters movement speed based on the slope of the terrain they are moving over.
If you go up or down a steep hill, that slows you down.
If you go down a slight hill, that speeds you up.
The slope to speed ratio is defined with a curve.
But a problem arises. If the ground slope is read in relation to the characters forward vector, then a player can easily walk sideways or backwards and suffer no speed penalty.
This problem is what motivated me to learn about Cross Product. In my solution I do not actually use a cross product node directly, however, understanding the nature of orthogonal vectors allowed me to come up with this solution:
The result is that no matter which direction I move in, forward, backward, strafe left or right, the Pitch output is always in relation to my direction of travel.
