You have to pick *some* standard axis system, even if only to define *other* axis systems within it.

Awww anthropocentrism again

Please make it easier to define vectors and vector translations in any reference frame.

Yeah that’s a legitimate issue with a good, known solution. A consistent implementation of custom axis systems needs to be part of Grasshopper 2.

By the way, how do I get the coordinates of an **existing** vector in a specific frame ?

Something like “Plane Coordinates” which does this for points, but for vectors.

This is a thing that Rhino should then learn from grasshopper …

No answer ?

**And how would you work your way around moving an object using a vector whose coordinates are defined in a specific base ?**

GH seems to favor using geometry to define transformations, but in my particular case, using vectors is so much more elegant.

Please ?

GH seems to favor using geometry to define transformations, but in my particular case, using vectors is so much more elegant.

Vectors are also geometry right?

By the way, how do I get the coordinates of an

existingvector in a specific frame ?

Something like “Plane Coordinates” which does this for points, but for vectors.

I find it a lot easier to use lines for this purpose, and use generic orient transformations. This way it’s trivial to debug it’s correctness.

Otherwise you would want an orient transformation where you take out the movement, so you should place the plane you’re transforming from and transforming to at the same location, and the use a regular orient transform.

Perhaps you can share what problems you’re encountering to which this should be a solution?

Gosh… let me rephrase this : vector transformations in GH could be improved.

I find it a lot easier to use lines for this purpose, and use generic orient transformations. This way it’s trivial to debug it’s correctness.

OK fine, so you’re happy with the way you do stuff, but that’s not my question.

Let me give you a very concrete example : I have those beams following a wavy façade, and each one of those has it’s own reference frame.

Since these are straight rectangular sections, It is super practical to add all the features and construct support plates, etc. by using these reference frames… except you can’t easily :

-Move geometry along a vector specified in a custom frame

-Get coordinates of a vector in a different reference frame

Eh depends on your definitions. They cannot be previewed, they do not exist anywhere *in* space, and they transform in different ways than points.

I think the only way is to set up a plane-to-plane transformation between your local plane and WorldXY, then transform the vector using that orientation.

I think the only way is to set up a plane-to-plane transformation between your local plane and WorldXY, then transform the vector using that orientation.

I don’t think so.

Orient transforms the coordinates of what he interprets as a point.

To transform a vector, you need to use the purely rotational transform matrix from one frame to the other.

The following example illustrates the problem :

Nope.3dm (51.7 KB)

Nope.gh (11.5 KB)

When you implement the proper vector transform tool, be sure to call it “Olivectorize”.

@DavidRutten

Thinking a bit more about it : I feel it would be **much** better to have a “base” input on the move transform than converting a vector coordinates from a custom base to the XY base.

The whole idea is to avoid “falling back” to the XY base because that’s just geometrically meaningless.

the global XY is like comfort food : you crave it, but it makes you fat and lazy.

Making the “Move” transform work in any base is more Gali**lean**.

See what I did there ?

You made the last 4 letters of that word fat and lazy? Bold move! (;

I was so proud of my silly pun that I was worried some folk might pass it over.

In fact, I’m looking for something more complicated.

Here’s how I really meant to state my request : how do I get the coordinates of an **existing** vector **defined in any frame** into another frame.

Here, you are assuming that the initial vector is defined in the “World” base.

My reproach to the present way GH handles vectors is that it coaxes you to always go through that “World” base, which is mostly convenient in very trivial cases.

Hi Emilio,

This is a fluke.

Your method does not work in the general case.

Not the right method for vector base change.gh (11.9 KB)

I think you need to go through the matrix calculation described here.