VEX on Copy To Points

[kiryha]

Why is the cube also rotating?

VEX_rotateCopys_01.hipnc

[Sepu]

The code is running over all the points if you just look to wrangle you can see what is doing to the grid, then when you use the copy to points is gonna look what attributes are using and it will apply that to all the points in the grid, this case on the boxes. What are you trying to achieve?

[f1480187]

You didn't compute transform attribute in wrangle (v@N, v@up, p@orient, and other), so, it doesn't specifically affect the resulting copies orientation. You can replace it with Transform node and result will be the same. Copy to Points tries to guess best orientation using geometry normal and object space's up vector. There is checkbox called "Transform Using Point Orientations" enabled by default.

Edited January 5, 2018 by f1480187

[kiryha]

@Sepu
I am trying to understand VEX and Houdini inspired by this thread. I cant understand at all how this bees and bombs are done even with the hip files, so I wish to clear basics.
Why then "sine" Wrangle does not affect boxes ad modifies only the grid?

@f1480187
When I add v@N; v@up; p@orient; in Wrangle, cubes no longer rotates. So I understand that Copy to Points tries to guess the best orientation... how and why it "decides" to replicate code from Wrangle to the cube before "Copy to Points" node? 
It may be a wrong assumption, but if I copy Wrangle and place it before "Copy to Points" node, the result is the same. 

 

Edited January 5, 2018 by kiryha

[f1480187]

When you add some transform attributes, it stops guessing them. Therefore no rotation, if the attribute values didn't describe any rotation. Sine wrangle does affect boxes, but the grid resolution is too low, and automatic orientations will be quite straightened, point normals can give you a hint on this. Corner cubes still rotated though.

 

Actually, for those who interested, there is pseudo-code section in the linked help page (again) with some info on how it works internally, guessing defaults and using inputs:

Key: 
X = pivot matrix (translate by -pivot)
O = orient matrix 
S = scale matrix (scale * pscale) 
L = alignment matrix (*) 
R = rot matrix 
T = trans matrix (trans + P) 
M = transform matrix

(*) The alignment matrix (L) is defined by N or v and up. 

IF N exists AND up exists and isn't {0,0,0}: 
   L = mlookatup(N,0,up) 
ELSE IF N exists: 
   L = dihedral({0,0,1},N) 
ELSE IF v exists AND up exists and isn't {0,0,0}: 
   L = mlookatup(v,0,up) 
ELSE IF v exists: 
   L = dihedral({0,0,1},v) 

IF transform exists:
   Transform = X*M*T
ELSE IF orient exists: 
   Transform = X*S*(O*R)*T
ELSE: 
   Transform = X*S*L*R*T

 

[kiryha]

>  Therefore no rotation, if the attribute values didn't describe any rotation.
But... the boxes are rotated around local Z axis!

As I understand, the "sine" Wrangle do not affect (deform) boxes, it affects only grig and boxes orients along grid surface. In case of "rotate" Wrangle boxes are rotates

 

Adding v@N; to the wrangle stops rotation.

Edited January 5, 2018 by kiryha

[f1480187]

Both wrangles work in same manner affecting the grid, from which final orientations computed. "Rotate" leads to orientations aligned to the rotated grid, "sine" leads to straightened ones because of low res grid with symmetric slopes.

31 minutes ago, kiryha said:

the boxes are rotated around local Z axis!

"When I add v@N; v@up; p@orient; in Wrangle, cubes no longer rotates". For example, if you declare @orient without actually setting it to some weird value, it will be defaulted to {0, 0, 0, 1}, which is "no rotation". If you customize normals, then copies will rotate. Really depends on what you actually did.

[kiryha]

So. Wrangles affect only the Grid. Orientation(rotation) of boxes defined by @N, @up, and @orient attributes. Right?

Such setup makes more sense for me.

VEX_rotateCopys_01.hipnc

Edited January 5, 2018 by kiryha

[f1480187]

Boxes got copied on template points based on their attributes. In case of missing attributes, Houdini will guess typical ones. There is more of them described by the link, those three are common.

[alr77]

Hello,

i was reading you topic. Yes as you said.

 

1. There is a button into copyTopoint Sop : "Transform using points orientation."

If you uncheck it you could orient your objects (admitting all the same) with an upper transform in your node tree.

 

2. with the button activated "Transform using points orientation." : As well using a attrWrglr on your grid let's you (as you've done) set up you @N oe @orient as you like.

@N = set(urValueX,urValueY,urValueZ).

 

Wishin it helped you.

work well !

 

alr + + +

Edited January 5, 2018 by alr77

[kiryha]

How to control the pivot of the scale? If I wish to scale from the bottom of the cube, instead of the center?

VEX_rotateCopys_02.hipnc

[Noobini]

go back up to your box1, drag the label Size into the middle field of next row (ie. the middle 0), pick Relative Channel Reference

You'll see it puts ch("sizex") into the field, change the x to y because we want to move the box up depending on its y size.

Now you'll see it's moved up too much, we want to move just half the height, so change the expression to ch("sizey")/2

Now you'll see the bottom of the box is at 'ground' level....no matter how 'high' the box is...

Then your scale will work properly.

[kiryha]

How would you modify the boxes with VEX to fill gaps between them?

The first thing that is coming to a mind is to use a "taper" and "transform" nodes for the box before copy node, but I keen to get procedural approach which will not fall apart after changing parameters in "phyllotaxis" wrangle.

 

VEX_HouVEX_phyllotaxis_02.hipnc

[Noobini]

looks like a job for f1480187...

[f1480187]

Found lazy hack using two Add nodes.

lazy_phyllotaxis.hipnc

[kiryha]

Why 42 and 26?

[Noobini]

this is annoying me...i see in the wrangle count = 300...yet my spreadsheet says I've got 600...displaying pt numbers see doubling up...

so:
 

int count = 300;
float bound = 10.0;
float tau = 6.28318530; // 2*$PI
float phi = (1+ sqrt(5))/2; // Golden ratio = 1.618
float golden_angle = (2 - phi)*tau; // In radians(*tau)
vector pos = {0,0,0};
float radius = 1.0;
float theta = 0;
int pt;


vector polar_to_cartesian(float theta; float radius){
    return set(cos(theta)*radius, 0, sin(theta)*radius);
}

for (int n=0; n<count; n++){
    radius = bound * pow(float(n)/float(count), ch('power'));
    theta += golden_angle;
    
    pos = polar_to_cartesian(theta, radius);
    addpoint(geoself(), pos); // *** IS THIS REALLY NEEDED ? ***
    
    // Create UP, pscale and N attr
    pt = addpoint(geoself(), pos);
    setpointattrib(geoself(), "pscale", pt, pow(radius,0.5));
    setpointattrib(geoself(), "N", pt, normalize(-pos));
    setpointattrib(geoself(), "up", pt, set(0,1,0));
}

see where i got the CAPS, is that needed ? isn't it added in the next line ?

[kiryha]

You are right, Noobini, we don't need this line, my mistake! 
But then we need to divide by two those magic F1 numbers.

In this case, we don't need those lines as well(setting points attributes for instance orientation):

setpointattrib(geoself(), "pscale", pt, pow(radius,0.5));
setpointattrib(geoself(), "N", pt, normalize(-pos));
setpointattrib(geoself(), "up", pt, set(0,1,0));

Edited January 12, 2018 by kiryha

[kiryha]

The @orient attribute is working wired. When you move a slider copy starts rotation but than slider gradually stops working. What am I missing?

 

float rotate_X = chf('rotate_X');
float rotate_Y = chf('rotate_Y');
float rotate_Z = chf('rotate_Z');
p@orient = set(rotate_X, rotate_Y, rotate_Z, 1);

 

 

VEX_CopiesOrient_01.hipnc

[f1480187]

Need all 4 components to have meaningful values to define orientation. You can convert from Euler (in radians) like this:

@orient = eulertoquaternion(set(rotate_X, rotate_Y, rotate_Z), XFORM_XYZ);

It is equivalent of this (for XYZ order):

float cos_x = cos(rotate_X/2);
float sin_x = sin(rotate_X/2);
float cos_y = cos(rotate_Y/2);
float sin_y = sin(rotate_Y/2);
float cos_z = cos(rotate_Z/2);
float sin_z = sin(rotate_Z/2);

@orient = set(cos_z * sin_x * cos_y - sin_z * cos_x * sin_y,
              cos_z * cos_x * sin_y + sin_z * sin_x * cos_y,
              sin_z * cos_x * cos_y - cos_z * sin_x * sin_y,
              cos_z * cos_x * cos_y + sin_z * sin_x * sin_y);

 

Edited February 15, 2018 by f1480187
redundant "#include <math.h>"