GH - Drawing a Line on a Rotated Plane doesn't rotate

This is probably a stupid question, but now I have tried so many ways to draw geometry starting from rotated planes in GrassHopper, but unless the component doesn’t have an explicit Plane input (or “Base”), the geometry will of course not align to the plane (only to the plane’s position in World, if starting from the Plane as a “point”).

I tried using vectors as well. But my attempts ends up with distortions of the angles of the geometry which I want to be following the transformed Plane when I tilt or rotate the Plane.

What has succeeded so far is straight lines based on Plane Normals, but if I rotate them, and then flip or rotate the plane, the lines are not rotated properly (again, the angles gets “distorted” by combined plane angles).

Obviously I don’t understand Planes in GH and how they are meant to be used. Obviously they are nothing like the Construction Planes in Rhino Viewports.

Q: So what is the basic approach for drawing, lets say, a line, on a plane being rotated and/or flipped and… so that that line is also rotated & flipped when the plane is flipped. Do I have to make two rotations - one for the plane an one for the geometry? If so, why then bother rotating the plane in the first place?

I must be missing something fundamental here, probably thinking in the wrong order. Like, must each GH object be explicitly rotated & flipped, and I cannot assume that geometry would follow the transformations of a plane? < scratching head >

// Rolf

Edit: Example picture: the two planes are at each end of a line (not shown) and are rotated. The green line (y+) was drawn starting from the lower plane (with a Point component based on that plane), but is not rotated togerther with the plane :

here’s one way to do it:

planeRotate.gh (9.3 KB)

Thanks jeff, helpful as always!

As a matter of fact, I have come so far too. Let’s call this rotation for “tilting” the plane. Edit: You also used the Plane’s Normal. In the picture above I also tilt the upper plane, then draw a “Normal” down to the lower plane, and I also rotate the two planes. But then starts the problem (the green line).

So, how do I draw lines planar to the plane(s) and have that geometry rotate with the planes, if adding a rotation around the plane’s center? (I should have been clearer on the tilting and rotation of planes).

// Rolf

So, is the right way (only way?) to do it to always draw only “normal” lines from any pane?

// Rolf

have you tried out Deconstruct Plane?
it returns the origin plus X,Y, & Z vectors of any given plane… or basically, contains all the info to make a local coordinate system per plane.

i know this is a basic example and only shows how to make a line along the plane’s X which sticks to the plane upon rotating… but maybe useful?

DePlane.gh (9.3 KB)

Yes, actually, I had overlooked that DefPlane yielded vectors, I thought it was coordinates… Well, that was a big step forward. I added it to my test model.

But now have a look at this definition. Rotate the thing by making a circle movement with the MD slider pad and watch the upper “tilt arm” go bananas :

PlaneRotate_Lab.gh (41.0 KB)

I think that this illustrates, somehow, the problems I experience when I try to rotate things in “free space” - joints starts to flip and tilt and perform the most charming things. Shouldn’t the “tilt arm” just keep moving along with the plane it started from without being so “nervous”? What am I doing wrong?

// Rolf

hey Rolf…

that’s too confusing for me to figure out what’s going on (clusters inside of clusters etc)…

i had to switch to number sliders because i’m getting some weirdness on mac with the MD Slider but one peculiarity i came across was :

• notice orientation of the line (pointing in positive Y direction)…
• in the panel, which is coming from Y_Hinge output ‘G’… notice the 3rd number of ‘Z’ is greater than the first…


• now sliding X-coordinate one digit, the line/plane is still in the same orientation, the numbers in the panel are now equal: (0.71)


• moving the slider one more click:

the line/plane has flipped directions… the 1st number of Z is now greater than the 3rd.
every time a flip happens, there’s a similar occurrence in the panel which has one number becoming greater than the other… it happens with both sliders and continues to happen throughout the full rotations.

i don’t know what’s going on inside those nested clusters but it seems some weird math might be happening inside there.

Hi Rolf.

I am very unsure about this but was reading this last night - is it a similar problem?

Barry.

[/quote][quote=“jeff_hammond, post:7, topic:44739”]
i don’t know what’s going on inside those nested clusters
[/quote]
The components are the same as in your example, I only prepared t6he Rotate3D component with the different plane & axis vectors as you use in you example:

Whatever is happening, it should not happen.
Edit: But when I think about it some more, it may well be explained by the fact that the components use “fixed” world axes. This would make the coordinate system flip when one axis is rotated “beyond” what defines a right- or left-hand coordinate system. In short: Can’t combine a rotation with a fixed axis. Should work better to deconstruct the first rotation and use vector from that to rotate the second axis rotation… Hm.

Edit2:
Yes, using a vector from the deconstructed first rotation seems to work better ( DePlane(X) used in stead of world X vector):

[quote=“bm_cadd, post:8, topic:44739”]
is it a similar problem?
http://www.grasshopper3d.com/forum/topics/plane-s-normal-problem-reversed-z-axis[/quote]

Hm, interesting. Possibly. I need to take a closer look at that case to see if it’s the same phenomenon, but it seem to be a leaking RightHand/LeftHand problem, and if so it’s… well, it’s not good. But if it can be fixed with the same ad-hoc method as in that thread then I guess I have to live with it. Thank you for the hint!

// Rolf

Try rotating the following nasty little figure. Here the planes are “tilted” properly, but they are not rotated the way I would have expected :

3DRotator_test2.gh (29.5 KB)

Edit: New picture with “droopy” lines hanging from the planes :

Notice how the green planes are “tilted” but not rotated (about it’s local xy center) in the same manner as the small cubes.

// Rolf

i can’t use that .gh…
the elefront stuff doesn’t seem to be working on mac.

so i can’t tell exactly what you’re trying to do there… but a rough guess? –

rotatingBoxes.gh (14.8 KB)


if that’s not it, can you post an example of the problem using only native GH components?

.

I updated my last link to “3DRotator_test.gh”. Hopefully I got rid of all the Elefronts’ “Description” components.

But no, it wasn’t about rotating the “satellite” cubes, instead it was more about keeping them rotating together with the center/master cube and (which will be crucial if making a hinge where the satellite cubes connect) rotate (as opposed to “tilt”) also the planes where the satellite cubes connect. Those planes’ locations follows the master cube - but - their planes are still rotated in “World” axis, as you can see from the picture in my previous post.

Edit: I added some droopy lines to a “3DRotator_test2.gh” to even better illustrate what I mean. And what I mean is that adding hinges to the planes at the satellite cubes, then everything from the hinges and onward will not rotate as one would expect.

// Rolf

that still doesn’t open for me… there’s elefront stuff in there.
regardless, the parts of it i can see are way too confusing to expect someone else to spend the hour it would take just to see what’s trying to happen (imo).

isn’t there a simpler example of the problem you could come up with?


according to the picture though, the droopy lines look like they’re all going in Z… i’m assuming you’re wanting them to go on the plane’s Z in which case, you can’t use worldZ for directions… use the plane’s Z

here’s some lines coming off the planes in various directions/rotations.
it’s just messing around and likely not very helpful but you can probably see how the lines’ directions are determined by the plane coordinates instead of the world coordinates

rotatottotr.gh (12.6 KB)


i suppose if you’re wanting to use world coordinates, you could build one of the modules at regular X,Y,Z… then once it’s doing its thing as a single unit, you could then orient that group on the planes…

i feel like that’s sort of what logic path you’re on anyway… using world XYZ coordinates except on various CPlanes…
that could be somewhat accomplished by building in world coordinates then moving to custom coordinates afterwards instead of beforehand.

Hi again,
I apologize for the elefront conponents, I tried to search (with F3) for all of them, but apparently I still didn’t find them all, sorry for that.

However, building everything ready in World XY plane is exactly what I’m trying to avoid in this case, since the point is that I want to make “hinges” at each separate joint/object.

Anyway, due to the intended hinge-joints, I still need to orient each object individually even if the individual objects had been drawn beforehand and only later translated and oriented into place. And the problem again - when rotating the “master object” the planes for the “satellite objects” doesn’t rotate as expected.

I will take a look at your example asap and see if it addresses that problem. And thanks for trying to help.

// Rolf