IV'09 & VBA - Convert Point to Vector and vice versus, the easy way?

[Anonymous]

What is the easiest way to get a Vector from a Point and vice versus? I don't really want to handle the data back and forth. Why aren't the methods defined?

Function Point.AsVector() As Vector

and

Function Vector.AsPoint() As Point


Maybe I'm missing the easy way?

[Anonymous]

Also, why isn't the TransientGeometry.CreateVector method overloaded to accept a Point as input, and the TransientGeometry.CreatePoint overloaded to accept a Vector as input? It seems like the following would be defined:

Public Function CreateVector(Optional ByVal oPointTo as Point, Optional ByVal oPointFrom as Point) As Vector


Then the user could pass in one point if they wanted the vector from the origin to the point, or pass in two points to make a vector. Since the Inventor.Vector and Inventor.Point objects are defined to be 3 elements in length (as opposed to arbitrary vectors in the mathematical sense), it would be nice to have some higher level operators instead of having to go down and deal with arrays of doubles. In fact, an overloaded = for the Vector and Point, that would accept the other as input would also be welcome.

(Again if I am missing something easy and obvious, please enlighten me 🙂 )

[Anonymous]

Attached is the function I was writing. Note I was trying to eliminate the dCoords(3) As Double

[Anonymous]

Josh,

Not sure I understand what you are trying to do, but anyway:

A vector from 0,0,0 is simply the x,y,z data of the point.
A "Unit vector" is the same xyz data scaled so that it's length from
the origin = 1 unit.

A vector between 2 points is calculated by subtracting one point from
the other, basically giving you a "delta" value. SImply subtract x from x,
y from y, z from z. Then use the same method above to convert to a unit
vector (I forget the exact formula, but I think IV provides that function,
or a simple search on google should turn it up.

Hope that helps a bit.

Bob

Josh_Petitt wrote:
> What is the easiest way to get a Vector from a Point and vice versus? I
> don't really want to handle the data back and forth. Why aren't the
> methods defined?
>
> Function Point.AsVector() As Vector
>
> and
>
> Function Vector.AsPoint() As Point
>
>
> Maybe I'm missing the easy way?

[Anonymous]

Bob, thanks for the reply. I understand what "vectors" and "points" are and what Inventor Vectors and Points are. However, my post was pointing out the need for better (i.e. higher level) operators and methods so that a user of the API don't have to resort to a double array to move data around or convert between types.

The Inventor Vector and Point objects have different specialized methods, but the data for both is three elements (X,Y,Z). A point could be interpreted as a vector (i.e. the vector from the origin) and you can see in the example I provided that the Matrix.SetTranslation method needs a Vector (not a Point). So I had to convert a Point to a Vector. I would have liked to done either:

oPoint.AsVector()

or

oTG.CreateVector(oPoint)


This would have eliminated the need for the double array.

[Anonymous]

It would be handy to have a way to create a point
or vector given the other one.  However, they are conceptually quite
different things but just happen to contain 3 doubles.  We
would have to add new Add methods to support this because an Automation
interface doesn't support overloading.  It's also not that common of a
need, although I have needed it before myself and this is what I've done
instead.

Assuming I already have oPoint that's been created
earlier and need to create a vector that defines the delta from the origin to
the point I would do this.

Dim oVec As Vector

Set oVec = oTG.CreateVector(oPoint.X, oPoint.Y,
oPoint.Z)

--
Brian Ekins
Autodesk Inventor API
Product Designer

href="http://blogs.autodesk.com/modthemachine">http://blogs.autodesk.com/modthemachine

[Anonymous]

Thanks for the reply Brian,

"However, they are conceptually quite different things"

Yes, I realize what they are conceptually (I am an engineer) and how they are implemented in Inventor. (One could argue that theoretically a "vector" can be any length, not just restricted to 3 elements in a Cartesian coordinate system, but I digress).

"an Automation interface doesn't support overloading."

I was afraid of this. It is too bad because it would be very nice to have some operators like += and -= for Vectors and some binary operators for handling Points and Vectors.


"Set oVec = oTG.CreateVector(oPoint.X, oPoint.Y,
oPoint.Z)"

yes, this is another way, but so much typing! And it requires another line of code.


I'm guessing the TransientGeometry manager is there to handle small objects (make them faster, better memory usage, etc). However, do we really have to go thru the TG to make any object? (This is a policy question, not a current implementation question). The method I suggested:

Public Point.AsVector() As Vector

could work thru the TG to create a new Vector object and return it to the user. It would act like a type cast, but really you would get a new object.

Or if that is not a "likeable" solution, why not have

Public Function VectorFrom(Optional ByVal Point As Point) As Vector

I would use the VectorTo method, but then I have to reverse the direction! Also, the Vector could have:

Public Function PointTo(Optional ByVal Point As Point) As Point

This would return the Point equivalent to moving the Point passed into the function by the vector. If no Point was passed in, then the origin would be used.


Just some ideas Brian. As an engineer that is pretty familiar with matrix algebra, transformation matrices, etc., it would be great if using Point, Vector and Matrix objects looked more "algebraic" and required less lines of code.

[Anonymous]

There are some restrictions with an Automation
interface that won't allow most of what you suggested.  The easiest thing
we could do is support an AsPoint property on a Vector and an AsVector property
on a Point that would return a Point or Vector.  I think there are a lot of
little and a few big things we can do to make the transient geometry objects
more useful and easier to use.
--
Brian Ekins
Autodesk Inventor API
Product Designer

href="http://blogs.autodesk.com/modthemachine">http://blogs.autodesk.com/modthemachine

style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">

"Josh_Petitt" wrote in message
href="news:6211501@discussion.autodesk.com">news:6211501@discussion.autodesk.com...

Thanks
for the reply Brian,

"However, they are conceptually quite different
things"

Yes, I realize what they are conceptually (I am an engineer)
and how they are implemented in Inventor. (One could argue that theoretically
a "vector" can be any length, not just restricted to 3 elements in a Cartesian
coordinate system, but I digress).

"an Automation interface doesn't
support overloading."

I was afraid of this. It is too bad because it
would be very nice to have some operators like += and -= for Vectors and some
binary operators for handling Points and Vectors.


"Set oVec =
oTG.CreateVector(oPoint.X, oPoint.Y,
oPoint.Z)"

yes, this is
another way, but so much typing! And it requires another line of
code.


I'm guessing the TransientGeometry manager is there to handle
small objects (make them faster, better memory usage, etc). However, do we
really have to go thru the TG to make any object? (This is a policy question,
not a current implementation question). The method I suggested:

Public
Point.AsVector() As Vector

could work thru the TG to create a new
Vector object and return it to the user. It would act like a type cast, but
really you would get a new object.

Or if that is not a "likeable"
solution, why not have

Public Function VectorFrom(Optional ByVal Point
As Point) As Vector

I would use the VectorTo method, but then I have to
reverse the direction! Also, the Vector could have:

Public Function
PointTo(Optional ByVal Point As Point) As Point

This would return the
Point equivalent to moving the Point passed into the function by the vector.
If no Point was passed in, then the origin would be used.


Just some
ideas Brian. As an engineer that is pretty familiar with matrix algebra,
transformation matrices, etc., it would be great if using Point, Vector and
Matrix objects looked more "algebraic" and required less lines of
code.