Jump to content
kiryha

VEX on Copy To Points

Recommended Posts

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?

  • Like 1

Share this post


Link to post
Share on other sites

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 by f1480187

Share this post


Link to post
Share on other sites

@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 by kiryha

Share this post


Link to post
Share on other sites

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.

sine_grid_template.thumb.png.669a7341fed5bc80af65725a4e15139c.png

 

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

 

  • Like 2

Share this post


Link to post
Share on other sites

 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 by kiryha

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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_02.PNG

VEX_rotateCopys_01.hipnc

Edited by kiryha

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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 by alr77
  • Like 1

Share this post


Link to post
Share on other sites

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.

  • Like 2

Share this post


Link to post
Share on other sites

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_phylotaxis_01.PNG

VEX_HouVEX_phyllotaxis_02.hipnc

Share this post


Link to post
Share on other sites

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 ?

Share this post


Link to post
Share on other sites

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 by kiryha

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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 by f1480187
redundant "#include <math.h>"
  • Like 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×