WISH : "Base" input for all transform components

I find myself jumping through hoops to make transformations that are relevant in a specific base, but not in the world base.
Wouldn’t it be much better to have a “Base” input for all transform components ?

By the way, it would be nice to choose once and for all between the “Base” and “Plane” term.

Which transforms dont have base/planes?

And “frame”…

2 Likes

So Move for example would be a vector plus a plane as inputs?

I can see the sense in doing this consistently, I have myself just never run into this. Can you give me an example of a work-flow where this would occur naturally?

You are right to ask : some do, some don’t.

Most importantly, I’d say “MOVE” because the most relevant vector is sometimes best expressed in a specific base.
Then you’ll notice that “Scale NU” has a base input but not “Scale” : so if you want to use a center point with coordinates related to a certain base, you need to fiddle with a “Point Oriented” component (you know, the super-confusing one with “u”, “v”, “w” inputs).
Same can be said of “Camera Obscura”, “Bend”, “Stretch”, …

The component “Point deform” , for example has both points and vectors as inputs, making it all the more interesting to specify the base in which their coordinates were expressed.

The “Base” input would just specify that the vector or point coordinates used as inputs are relevant to that base, thus avoiding to convert all the time into “World” coordinates beforehand.

Scale has a point to scale from. A plane wouldn’t matter cuz scale is uniform.

Scale has a point to scale from. A plane wouldn’t matter cuz scale is uniform.

I’m realizing that if you have the coordinates of a point in a specific coordinate system, you NEED to use “Point Oriented” first anyways because “Scale” (and others) input points, and not their coordinates.
Which make me think that a “Construct Point” component with a base input would replace advantageously the “Point oriented” component.

My point is still valid for transforms involving vectors though…

I use move mostly in combination with vector2pt, line SDL, or normal vectors combined with amplitude so I haven’t noticed any issue. I did get tired of vec2pt combo and made a Move2pt component in Pufferfish which moves things from point A to point B.

Aha… Move2pt… that makes sense.
Thanks for this component.

@DavidRutten
OK, just to summarize here,

since I find myself moving lots of stuff in reference to custom bases, I feel that both “Construct Point” and “Vector XYZ” should have a “Base” input specifying which base the X, Y and Z coordinates relate to, the output being a point and a vector in the “World base”.

I’m still not happy with the idea that a transformation based on a vector should necessarily use vector coordinates in the “World base”.
No reference frame is special, remember ?

There used to be plane inputs on Construct Point, but I removed those and instead now you’d use the Point Oriented component for that, and I’m not sure why you don’t like it as it does exactly what you want. There’s no direct equivalent for vectors though, there probably should be.

Be glad that space in Rhino is not Relativistic, that would be exceedingly uncomfortable.

I do get that the idea of local coordinate systems is useful. I think @RIL came up with a suggestion to have custom axes per Grasshopper group, and there have been other suggestions as well. I believe coordinate systems are an integral part of Generative Components as well, requiring you to always specify what system you want to work in at any given time. Having them as an ad hoc notion is somewhat dangerous I feel in that it very easily gives rise to confusion.

Yes, that would solve so many problems when doing (for example) continous measurements on parts in motion (need to measure both in “local plane” and World at the same time, using the same basic logic for both (for example a cluster would be “contaminated” by the GroupPlane its inserted in and the implicitly perform its thing in that local plane).

// Rolf

There used to be plane inputs on Construct Point, but I removed those and instead now you’d use the Point Oriented component for that, and I’m not sure why you don’t like it as it does exactly what you want.

Hmm this is an acute case of redundency.
Lots of components have a base input which is set to “XY” by default, and most of the times, there’s no need to change it. That’s fine with me. But making a component impotent, and cloning it’s original version with a new name is kind of slushy.

There’s no direct equivalent for vectors though, there probably should be.

Thus my above suggestion !

There’s another way of dealing with this :
Maybe points and vectors should “embed” a duet of data:
-Coordinates
-Coordinate system in which the coordinates are expressed

There is a similar issue with angles : most people like to read angles in degrees, but radians are more “pure” mathematically.
So why not create an “Angle value” component, also with a duet of data :
-Angle value
-Unit in which the angle value is expressed.

In both cases, the idea is to make mathematical objects which can be processed by any downstream component without having to do messy conversion noodle’o’ramas beforehand.

For me as it is done now is perfectly well, base transformations are changes that I prefer that are well visible and represented in the same way as any other transformation. But anyway, I wanted to comment to suggest adding non-ortonormal bases and also points and vectors of n-dimensions for GH2, both are very useful for engineering, machine learning and in general they allow to represent linear transformations in a simpler way for some cases.

Dani, to me, the “Orient” component is a Base transformation ; that’s not what I’m talking about.
I’m just pointing to the fact that the “World” XY is OK for basic stuff, but when you start working on say, complex façades with many components having a local logic, converting points and vectorcoordinates back to the global (arbitrary) coordinate system is a useless hassle.

I strongly feel that at least these 5 components should have a “Base” input, (set by default to XY) so as to let one work in local coordinates in a natural fashion :

I agree on your other requests.

You mean Rhino’s XYZ system? It’s not arbitrary, it’s a standard.

I don’t understand why you have to go back if you don’t need it.

Correct me if I’m wrong, but all the ortho-normal base changes you refer to, going from global G{x,y,z} to local L{x,y,z}, or vice versa, are actually L = T(G) or G = T’(L), where T is an orient type transformation (moves from this origin to this other origin, rotates from this X axis to this other X axis, this Y axis to this other Y axis, and so on). Rhino can’t escape the XYZ standard, and you can already create oriented points as David suggested, I agree it would be nice to include the vector version btw. With my previous answer I meant that it is the same vector space but with a transformation, and to include that in a point constructor is what Point Oriented does.

Think that you take the definition of another person, and move a point, you see the coordinates of the direction of movement and you do not fit with the global XYZ result, you, that you know, can deduct that the base plane parameter has been changed, someone who does not know about vectors (which are many that start in GH and do not have an architectural background for example) will not understand what happens with the simplest operation of all, moving a point, until he/she understands some of vectorial algebra, I don’t see it as a rational problem, I see it as an emotional problem. GH already fails a lot in this sense.
On the other hand, if you keep it as it is, or use the specific components for it, or apply the transformation in another way, it is something that leaves a visual record in the definition at least. There is no need to modify these components, other can be created.

I’m ahead of you there, I’ve added an Angle type in GH2 which can be specified in degrees, radians, turns, slope-percent, and spreads (from rational trigonometry).

In a way yes, the construct point component is however so ubiquitous that I didn’t like having that fourth input there all the time. I still have to decide on a general strategy regarding ‘splitting’ and ‘lumping’ in GH2. Haven’t settled yet.

Unless you are modeling lego bricks, you don’t give a damn about Rhino’s world XYZ at some point.
What you want is to juggle effortlessly with the many local coordinate systems that are relevant to the geometric masterpiece that you are generating.