# EDIT: Strange rotation, probably data tree issue

EDIT: Post re written for clarity.

I am doing a study of one of Anthony Howe’s kinetic sculptures, (Howe, Olympic Cauldron). I got the definition to work so that I achieved the intended outcome, but along the way I ran into a problem that I didn’t understand.

The tree structure of the geometry is six branches with 12 bit of data, whereas there are only 12 bits of data feeding into the X and C input of the Rotate 3D component; so when I merge the two geometry trees to get a tree with 6 branches with 24 bits of information, the C and X inputs ‘run dry’ and defaults to a single value?

These are the steps I’ve taken:

rotation_data_tree.gh (24.3 KB)

1. Reference Rhino curves and perform a polar array.
2. Perpendicular Frames from a reference circle to get the origin point and z-vector for geometry to rotate around. (same number as instances in array.
3. First rotation to off set each instance by 0.5 degrees. Lets call this group A.
4. Second rotation to get 90 degree offset. Lets call this group B.
5. Third rotation controlled by a number slider 0-360.

All 3D Rotate components use the same vector and origin points from step two. However, if I insert group A and B into the same 3D Rotate, group A will rotate around the correct origin points from step 2 but group B will only rotate around a singular point.

If I insert group A and B in two individual 3D rotate components controlled by a single number slider, then I get the intended rotation.

some curves are not internalize so could not figure out what u looking for !!

I think this is what u r looking for !!

rotation_data_tree_1 .gh (25.3 KB)

Thank you so much for have a look at my file Rajeev. And apologies for not providing a complete file, I thought I had internalized the data in both curve components.

I did manage to make it work, but I am interested in why one solution worked and another one didn’t. I wonder if it is do with a mismatch in input data to the 3D Rotate component. Feeding 24 bits of geometry but only 12 bits of information to the C and X inputs?

I don’t think my original post was very clear so I will rewrite it for clarity. It is a bit difficult to try and explain a problem when you are first trying to understand the nature of the problem.

now i got what u are looking for for the video you posted
let me check it out and come back to u

https://images.app.goo.gl/H7Z3vxDr9MdRGEWPA

Thank you for looking into this Rajeev. I think I found out the nature of the problem which was to do with data matching. As I was supplying a list of 12 vectors to a list of 24 items, after performing the transformations on the first 12 items it defaulted back to the first vector for the remaining 12.

I don’t know if there is a native setting for a individual components to cycle through one input A until it has exhausted input B?

I found three solutions, and I don’t really know which one is better.

A) Rotate group A and B separately but controlled by the same slider
B) Duplicate the inputs to the X and C on the rotate 3D component.
C) Longest List set to wrap cycle through the X and C inputs until it matches the G input.

i hope u get some more refreshing ideas out of this

strange rotation.gh (34.2 KB)

1 Like