I cant seem to get my Z vector oriented anywhere but to the origin.
Ive tried perp frame, perp frames, reorienting, in the preview it looks fine, but the data is giving me a rotation on the X axis even though im on a flat surface…
Any ideas?
Thanks.
Ill post an example ASAP
Is this a question about Grasshopper?
Hi Helvetosaur,
Yes probably should have tagged it better… Did i post in the wrong place?
This isnt exactly one node i feel. Each route i take, the application instance is pointing to the origin. I can even creat my own plane with defined points as references and have it give me proper results.
No, that’s fine, I see you now added the category. Can you post an example of what you get versus what you expect to have but are not getting? It’s not quite clear to me what is going wrong.
no matter how much i try to pull that orientation away from the origin it still gives me these values… I can create my own vector and when i deconstruct the plane, always same results, so far.
vector issues.gh (11.8 KB) Where do you see that a vector is a point. A vector has no position in space it is a direction.
Use Line SDL for that
Im creating rotation values. to use in a transform spreadsheet and export as a csv file… maybe there is a better way to do this? But id like to have a target. and a list of points. Ive got my point positions and now im trying to have another point(variable) that holds the rotation values to the target from that point.
I see the transform matrix node , but i dont know how to really use this.
I don’t really understand what you are looking for.
You could search on this forum on discussion on Compound and transforms
When i try using your approach the numbers still show the same.
Unfortunately 
What I want is tx = rx , ty = ry, tz = rz. So position x should represent rotation value of the x axis… i THINK i can pull the rotation of the normal, if aligned properly, to get these values?
Then i can use to transform an object in all directions… I am only using points to hold information, i have not told the computer what those numbers mean yet
I didnt show other approaches, but also creating a plane from 3 points gives me this…
Such a simple operation here… with a terribly wrong value.
Helvetosaur,
Yes it is correct in yours. why would it show me different results…
I am taking my origin point. and moving up to create my Z axis, then rotating(could be shifting) to create my X axis. I take my Z axis and change to my Y asix. So the plane normal (new Z Axis) should face the middle if the data is correct… not at an angle…
What I’m trying to say is that the component works correctly… If it is not giving you the result you think you should have, most likely your origin, X axis and Y axis points are not where you think they are. Try checking your definition by baking the input points that are being fed into your plane component.
Yes, this is my question since the beginning.
I am giving it proper values. the point im referencing are in the image. It really frustrating that im struggling with simple plane manipulation.
how do i get the deconstruct plane to show the correct values? or what is the best approach to solve this issue?
can you try and use the example to recreate? because i can add 3 points also, but this is not parametric
Hi Sbontly.
Well, not really:
You were using vectors as points. That’s not going to lead you anywhere.
Check again @laurent_delrieu’s post.
You can construct and deconstruct planes in any way ( and so far I have ever found a bug…)
… but you need to distinguish well points from vectors!
This doesn’t make sense.
Both Vectors and Points are “triple” or “3-tuple” … so 3 numbers “packed together”.
Grasshopper can (an will) silently convert a point to vector and vice-versa, as they are almost “the same thing”. But you should try to avoid doing that completely, if you can’t get your stuff right.
If a component needs a point, make a point! Build it from scratch if needed. Don’t use a vector!
I hope something of my message could help in some way.
I wan’t able to understand the construction you are trying in the gh file…
Hey Maje,
Thanks for chiming in. Ill look into this you mentioned.
And to your second point. Yes, this is normally how data is handled. At the end of the days its just integers, floats, strings etc. We are giving it its structure. In other software this is pretty straight forward. Ill post my findings when i investigate.
There may be a space relativity thing happening here.world space vs local… but im referencing the current origin.
Ok, i too uses vector to point and vice-versa everytime.
I’m not saying it’s wrong, but that it’s hard to grasp what is going on if you are not used to this kind of stuff.
You were using vectors as points, and you were expecting “something” (still unclear for me).
It’s nice you know already that this is “normal”… but what you did seems to tell that is not normal for you.
If you tell clearly what you want to achieve i’m sure with 3-6 components we can build it up in 30 seconds.
…no
Ok, Ill try again. My file does show my process, but i can put into better words i think.
I am exporting a dataTable.csv, that im creating with my own numbers. For positions, rotations and other attributes.
I am creating a system where i have 1 target. and lets say 20 cameras. I am currently, as shown in my original image and file, taking these points, and drawing a line between them (cameras to targets), then using perp frame, which I assume lines up the Z vector to the line… unless there is a tangent?
From there im deconstructing the plane… and looking at its z vector, which is 3 floats. Essentially, normalized rotation values (rx,ry,rz), please correct me here. which in turn i will remap and export.
This did not work, so i took the origin of the of the camera points and rotated the circle geometry to get another point to act as my X Axis and moved the original points on the worldSpace Z vector. Then i built my own plane from these 3 points changing the worldSpace Z to localSpace Y, in hope that it will give the correct normalized rotation values…
Ive even manually rotated perp frames 90 degrees inward and the values still show it pointing to the origin.
Maybe the whole approach is wrong, and im up to hearing other options… but when i break down the logic, it seems coherent.
Thanks for your time everyone!
