koobas.hobune.stream
Calculating endpoints of directional vector
I have the feeling the solution is horribly obvious, but I'm having trouble understanding a bit of vector math: if I want a vector representing the distance between two points, I do something like this:
Vector3 origin;
Vector3 destination;
Vector3 direction = (destination - origin).normalized * Vector3.distance(origin, destination);
So here's where I'm confused: if someone hands me direction without any of the accompanying values, how would I calculate origin and destination? Would origin simply be direction.normalized?
In addition to @Optrix answer:
you can simplify this to the following:
Vector3 direction = destination - origin
This is equal to the line you posted. Normalizing does nothing else but to reduce a vector to length 1. So multiplication by the distance of origin and destination will only result in the same vector again.
So in other words, normalization is nothing else but dividing by the length of a vector.
You shouldn't think of the vector you get by subtracting destination from origin as a "direction vector". It's more than that. It's a vector representing the relative positions of the two points or "how to get from origin to destination". The direction vector is what you get when you normalise the relative position vector.
For any such relative position vector, there are an infinite number of origin-destination pairs that would give the exact same relative position vector when you subtract them. This is obvious from the fact that whatever your origin, you can add the relative position vector to get a new destination.
Therefore, you can't go backwards and what you ask for is not possible.
Another way to look at it is that you start with 6 pieces of information (2 sets of 3D coordinates). When you subtract them to get your relative position vector, you end up with just 3 pieces of information. Information must, therefore, have been lost and you cannot expect to be able to reconstruct the 6 that you started with.
So, what you ask for is not possible. You can't work out the origin or destination from such a vector.
Hmm, that makes complete sense but it leaves me unsure how to proceed- the reason I'm asking in the first place is because I'm working on an algorithmn which, given a 2d polygon represented as a collection of Edges where each edge is a Vector3 start, Vector3 end pair, bisects the polygon along its longest edge. After finding the longest edge, I can calculate the exact line along which I want to bisect it by doing this:
Edge longestEdge;
Vector3 bisecting = Vector3.Cross(longestEdge.endVector - longestEdge.startVector, Vector3.up);
Now that I have the bisecting segment, I need to portion one polygon into two by iterating through each edge and moving it to one poly or the other based on which side of bisecting it's on. However, there's one last, critical step: since bisecting has become a new outside edge in both polygons, I need to add its start and end points as vertices on each polygon. That's why I was trying to calculate the start/endpoints.
I suppose as a workaround, ins$$anonymous$$d of a single longest edge I could try to find the longest pair of roughly parallel edges, find the midpoint of each edge, then draw a vector between the two midpoints, but that doesn't seem as clean as the single bisection.
Your bisecting is just a Vector3 so cannot represent a line or line segment (only 3 data points). It's actually just giving the direction of the bisecting line .
To define the line itself you also need a position on it. That'll be the midpoint
0.5f * (longestEdge.startVector + longestEdge.endVector).
So now you have one point on the line and its direction. To find the other end of the line, you could go through the other edges seeing where it crosses them. If the polygon is bisectable from the longest edge then there will only be one (unless it happens to hit a vertex in which case you'll get a hit from 2 consecutive edges, but you can check for that).
Hope that makes sense, I may not have 100% followed what you're doing. You don't seem to be catering for the possibility of the bisecting line dividing another line in 2 as well, which seems to be quite likely to me unless you're constraining your polygons in some way.
Ooh thank you! That's definitely enough to fix what I was brain-stuck on- and yeah, I'm going to have to deal with the second line as well, but that's reasonably straightforward in comparison- thank you for the really helpful feedback! :)
A ray or line is an origin and a direction - you CAN'T build a true line without the other, and you can't calculate one without the other.
But without knowing your application, you might be able to assume one. A direction vector that is used as a speed has its origin at the object. So sometimes the context lets you know what the origin is supposed to be.
Care to offer some more detail?
This is wrong, it may be a language thing but the meanings of works matter here. People being sloppy about word meaning is what leads to people not getting it.
1) A ray is an an origin and a direction but the OP is not talking about rays. They're talking about lines defined by two points. Such a line is given by origin, direction, and distance (or, equivalently, by the start and end points).
2) You cannot "use a direction vector as a speed". Speed is a scalar so what would that even mean?
3) You could "use a direction vector as a velocity", but it would be a velocity of 1.0 so not very useful.
1) Yes, I agree. You need all three or endpoints - I was not accurate there.
2) That's technically correct (the best kind of correct?) but extremely pedantic, isn't it? Often "velocity" and "speed" are used interchangeably in most conversation. But yes - speed is the scalar magnitude of your velocity non-unit vector.
3) I did not say 'normalized' or 'unit' vector, so if we are being rather pedantic here allow me to reciprocate :) A unit vector would be quite useless for velocity, but since RigidBody stores velocity as a non-unit vector, I'd imagine it's evident that you can represent velocity as a vector. Even if it couldn't, the fact that Unity uses a Vector3 to represent velocity in Unity, it would still be an acceptable term.
Velocity is a vector, I never said anything different. What I said was that using a direction vector (which is a unity vector) as a velocity would be odd.
