Decompose Point location in user-defined plane?

Hello,

Is it possible to retrieve the x, y, and z values of a point in relation to a user-defined plane?

For example:

if I create a plane with user-defined x and y directions, and I have a point which moves back and forth across the x-axis of the plane, and I would like to retrieve the x-component of the point based on the plane's coordinates (not world coordinates) to see when it is positive or negative... can I do that?

Thanks,

-Brian

Replies to This Discussion

Permalink Reply by Evan Bauer on November 28, 2011 at 11:36pm

Could you just remap all the points relative to your new surface/plane origin and do the test from there?

Permalink Reply by Brian Harms on November 28, 2011 at 11:50pm

I'm not sure if I understand... If you decompose a point's coordinates you will always get coordinates in the world-axes (as far as I know at least). I'm wanting to get point coordinates relative to a plane.

If I place a point in the +x, +y quadrant of a world XY plane (let's say [1,1,0] relative to the plane) but the plane's center is at [20,20,20] then the point's actual coordinates are [21,21,20]. This is what we would get if we decompose the point. I want it to return the [1,1,0] instead. It would be like reversing the point oriented component to evaluate rather than create a point.

What I did as a workaround was create 2 oriented points based on my new plane - one @ [0,-1,0] which is the negative side of the x-axis, and one @ [0,1,0] - the positive side. Then I have the point I'm testing, which moves back and forth. So I just measure the distance from my test point to the two new points. When the test point is closer to [0,1,0] it's x position is positive, and vice versa.

Does that make sense?

Permalink Reply by Evan Bauer on November 29, 2011 at 7:08am

Right, I follow what you're trying to do. In the example you gave with the [21,21,20] could you not just find the new origin (20,20,20) then subtract {20,20,20} from each 'new' point's coordinate therefore doing [21,21,20]-(20,20,20)={1,1,0} **Note types of parenthesis** Then you test the new {1,1,0}?

Permalink Reply by Brian Harms on November 29, 2011 at 9:41am

In this simple example you could, but if the plane were rotated, upside down and tilted at an angle it would be much harder. I'm just looking for a clean solution.

Permalink Reply by David Rutten on November 29, 2011 at 7:19am

Plane CP will do this, although the x, y and z components are uv and d respectively.

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by David Rutten on November 29, 2011 at 7:29am

I added additional plane parameters to [Decompose Point] and [Point XYZ] to make this easier.

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Aris Nikolopoulos on September 25, 2016 at 3:48am

Hello,

wouldn't it be very useful if all primitives could have an option to "inherit" the coordinate system as well as the origin point when you link them to a plane?

many times, I need to organize components in a local system, and every time I have to manually translate world coordinates to local ones.

If all the components "inherited" the local coordinate system it would be much more quick and intuitive.

(I hope what I said made sense) :)

Permalink Reply by David Rutten on September 25, 2016 at 4:07am

Yes, but not by adding more inputs to all components. If there can be a way to provide local coordinate systems unobtrusively then it's something I'd love to add.

Permalink Reply by Aris Nikolopoulos on September 27, 2016 at 2:39am

Challenge accepted :)

(inspired by the sketchup component which when opened, has its own independent local coordinate system)

Permalink Reply by Aris Nikolopoulos on September 27, 2016 at 3:10am

Permalink Reply by David Rutten on September 27, 2016 at 3:38am

Yes, a similar approach occurred to me as well, but I'm not sure I like it. Like you already showed in your images, it's somewhat awkward to cleanly define membership of such regions. Resizing/moving the region might severely mess up the layout of components in its neighbourhood. If you don't move components out of the way then you end up with ambiguous inside/outside relationships as the local system and a component might only partially overlap. And of course it's problematic when you're dealing with multiple LCS regions overlapping each other. Can they be fully immersed in each other?

Rhino geometry does not allow for the specification of a local coordinate system, so having shapes carry around this additional information would involve quite a departure from the Rhino SDK classes. This means that data crossing the LCS region boundary must itself know how to adapt. This results in two problems:

It puts a lot of extra responsibility on data type developers, something which I worry about.
It's not at all clear when data ought to be translated from one LCS to another.

An example of (2) would be if you measure the length/area/volume of some shape, then export that number to a different coordinate system. Should it scale? How about transformation data? Should it be changed to a different base?

----

I'm not saying your suggestion is a bad idea, it's just that there's a lot of rather complex problems associated with it to which I don't yet see a solution.

Permalink Reply by David Rutten on September 27, 2016 at 4:30am

Yes, going from one coordinate system to another is a change of basis transform. It would be nice if the planes used for this could have non-unit and non-perpendicular axes, I don't think that can be done in GH1 using any of the standard components.

The real question here is when that change of basis is supposed to happen. Should it happen between components when they belong to different coordinate system regions or should it happen inside components?

If we end up taking a region approach as proposed by Aris, then the data needs to be transformed 'inside the wires' when those wires exit or enter a LCS region. If on the other hand coordinate systems are assigned to individual components, then they would affect the component itself. Ie. it tells the component that your inputs are defined in some custom coordinate system but the outputs are ALWAYS in world coordinates.

The second approach is less neat mathematically, but simpler I think both to develop for and use. It also solves the problem of where to preview geometry. If all geometry is always in world coordinates, then what you see if what you get. If geometry needs to be previewed within some other coordinate system defined in world coordinates, then your own point of view becomes relevant. Ie. from what coordinate system do you want to look at this geometry?