If the line direction is changed, the correct result is reported.
Line direction should not affect the angle
Angle 001.gh (6.3 KB)
If the line direction is changed, the correct result is reported.
Line direction should not affect the angle
Angle 001.gh (6.3 KB)
please internalize the curves !
@HS_Kim thanks !!
I think he is reporting a bug, or at least unexpected behaviour. A direction of line should indeed not affect the angle in between them. Even worse that both angles are almost similar… I would have expected 360 - 82.34 but not 180 - 82.34 as output. And why do you need a plane for this? The cross of two non-parallel vectors give you the normal and so an indication of the plane.
@HS_Kim explain that in the curves both vector should start form one center point then only angle is calculated properly if they are different or opposite direction it wont calculate
this is miss understanding happen cos we are plugging the curve into the vector if its properly check the vector and plug into input of angle component it will work perfectly …
its my understanding !!
Take the closest endpoint and subtract it from the other endpoint and you get the correct tangent. If its unclear then please return a warning that it cannot guarantee to return the correct result. A plane should only be required if the angle should be determined by a view. Computing like this is a grave error from a users perspective. It would mean a user has to double check any output. Just saying
The angle is based on two vectors.
So if you flip 1 of the curves, you will get 180 minus the angle of if the curve is not flipped.
So it will take the start of each curve and get the vector from start to end and then find the angle. So in the diagram above, the left curve is the horizontal line in direction 1 while the right curve is the same curve but flipped, hence the 180-angle.
I know, but about which input are we talking about ? Finite Line input or Vector input? If you allow geometry casting like this you should thread the line input as line and not as vector. Or prohibit it.
So you could say that this error is the result of wrong input types. The angle component requires vectors, but if you feed in a line it automatically retreives the vector from it without any relation to the component.
I would assume the correct answer then is always feed in the correct input types, otherwise you cannot guarantee the computation makes sense. I assume the casting happends before the actual computation takes place. A perfect example why this is rather dangerous than beneficial.
I did !!!
EDIT
Oh blast, well l clicked all the right buttons to internalize both curves so I obviously dont understand the logic for updating a curve once it has been internalized.
Do you proceed straight to select one curve again, or must your first UN internalize the orignal selection, then select a new curve, then internalize again?
Angle 002.gh (8.2 KB)
Guys come on… Theres 2 and only two angles between those lines, neither of them is 97.6 deg
Its not a bug, its an undocumented feature you need to know about
@TomTom as far as my understanding the curves plugged in to vector of angle calculation
instead of curve if its line then chances of error is less this what i felt
that is why i always insist to plugin the exact data to make things work more accurately !!
translation please )
two lines, 2 angles… what am i missing?
direction of line is irrelevant. a line is a vector with distance value…
It is clear, direction is not irrelevant when the operation you are using is speifically looking at vector angles. A vector is not a line with a distance, it is a direction with a distance(amplitude). When a vector becomes a line it gains the property of having a literal location in space.
The vector you should be using is {-0.992,-9.765,0.0}, but by having the line facing the flipped direction you are actually using the vector {0.992,9.765,0.0}
This is what you wanted
But if you look at the line directions you will see the vector direction
Now the component says “compute the angle between two vectors” so it is looking at the vector information of these lines, not their literal spacial location. So now imagine the measurement is vector to vector originating from the same start like below.
So just keep in mind that this is a mathematical angle calculation between vectors, not a geometric one between line locations.
Now whether or not the component should make you aware of your potential user oversight is another story…
If you hover over the A and B input it will say it expects vectors. You feed in Linear Curves it makes it a Line and then a Vector and then it computes the angle between two vectors. This computation is correct, because a vector doesn’t know a location (= its just a direction). Still to be able to plugin in a curve or line component to an “Angle between Vectors computation” is the real root of evil. When looking at this thread at first I wasn’t aware of this either. But still, that you can do so is really an issue, because a casual user would likely not be aware of this circumstance, and even pro users may trap here.
Well perhaps, but wny? I didnt specify a T inersection of curves nor did I ask for the adjacent angle. The vector is a LINE. it stops at the intersection.
If the module is calculating vectors without length then I would argue that is not helpful, and the question becomes how does it choose which of those two angles to evaluate?
My preference would be the plain, predictable, intuitive design.
A vector is NOT a line
Well ok, a LINE is a vector with the distance specificed. The undelying vector can be extracted from a line. You are correct.