reset to origin.

[Jesper Rahlff]

Hello Odforce!

I often find myself in a situation wanting to take each piece of geo I have from an alembic, move it to the origin and "reset" rotation for convinience, do some operations, and then move it back to its original place with its original rotation on it. However I often find my knowledge short to do this stuff.

I have crafted an example file here of my problem and hopefully some of you can help me with a few examples on how to do this.

As described in the file, this is what I want to do:

- move each piece of geo to the origin.

- calculate the rotation thats on the piece of geo, and "reset" it so that the point with @Cd = {1,0,0} is upwards.

- put the geometry back to its original position with its original rotation.

 

I hope you guys can help fill the gap I have when it comes to this kind of stuff.

 

Cheers

 

 

calculate_transform.hiplc

[f1480187]

Take a look.

pieces_to_origin.hipnc

[Jesper Rahlff]

Thanks f1.

I am pretty sure I understand most of it.

however the last 3 lines I am not sure of..

 

4@xform = rot; 

translate(4@xform, origin); 
@P *= invert(4@xform);
 

would you care to explain a little in detail whats going on at the end?

as far as I can tell, you create a vector4 called xform out of the matrix3 you crafted. Then you use translate() however nothing is translated until the last line is applied. That is a little confusing to me.

 

 

 

also is it correct assumed that this only works because you can use the pointnumbers? I mean conveniently enough point 0 is the "red" point on all the triangles, but what if that was not the case? 

like in the attached example..

calculate_transform_v02.hipnc

Edited November 28, 2017 by Jesper Rahlff

[Noobini]

prolly would have helped better if origin was called COM...or center...or centroid

so each pyramid now has a 'center', a 'gyro' is calculated...but this gyro is at world origin (hence confusing)...so

translate(4@xform, origin);  is to move each gyro to the correct center in world space (not world origin)

that's my clutching at straws understanding.

[f1480187]

1. Previous lines:
3 x 3 rotation matrix approximating piece's orientation was made. Despite of the name, such matrix can also hold the scale. Scale is {1,1,1}, since everything is orthonormalized.

xx xy xz
yx yy yz
zx zy zz

First line:
4 x 4 transform matrix initialized using 3 x 3 rotation matrix, so, it can now contain translation too.

xx xy xz  0
yx yy yz  0
zx zy zz  0
 0  0  0  1

Second line:
Transform matrix got some translation. Here it is called "origin", as you wrote it, I myself prefer "pivot". Now the transform matrix fully approximates piece's local transform.

xx xy xz  0
yx yy yz  0
zx zy zz  0
tx ty tz  1

Last line:
Piece is transformed by approximated transform inversion.
xform: origin → local transform
invert(xform): local transform → origin

 

2. Yes. There are many ways to solve this. For example, you can add another point wrangle before, and when the red point found, set detail attribute containing it's position.

[Jesper Rahlff]

thanks for the in depth explanation. It makes a lot more sense now.

So if I understand you correctly, as long as you can find some kind of similarity in your geos, you can do this? (your example with the red point).

 

[f1480187]

I assumed red point is what you've managed to achieve already. If you don't have such constraint yet, the task may be harder or easier, depending on input geometries. In fact, if you will find two constraints, second can fix arbitrary rotation around vertical axis (in code, use it instead of arbitrarily-typed vector constant). If you are able to find exact pivot, instead of averaging points, it will work even better. If all pieces share same topology, it is easy, since iterating will produce exactly same point numbers. Otherwise Match Topology can be used. If the pieces are very random you probably won't be able to do much.

[Jesper Rahlff]

this is the geometry I have to work with. The red point I have not achieved, that was just a pointer in the first example file so I knew which point should be upwards. In the example file attached here, I am not sure where to start tbh

so basically I need each spike to point upwards when at the origin.

calculate_transform_v02.hipnc

Edited November 29, 2017 by Jesper Rahlff

[f1480187]

That locked null is still missing geometry for me. Scene file is 52 kB, which is usually too small to have any geometry embedded. Try converting it to houdini geo or upload zipped scene with alembic file.

[Jesper Rahlff]

1 minute ago, f1480187 said:

That locked null is still missing geometry for me. Scene file is 52 kB, which is usually too small to have any geometry embedded. Try converting it to houdini geo or upload zipped scene with alembic file.

 

test_v150.bgeo

[Jesper Rahlff]

this is the geo. one frame of the geo atleast

[f1480187]

Same. I can't use packed alembic primitive (saved in bgeo or locked, no difference here on my Houdini 16.5.268) if I have no file on disk at the same time. Well, it makes a bit of sense, though proper embedding is really expected by everyone, IMO. You can upload file or drop Convert node and lock usual Houdini polygons.

 

Edited November 29, 2017 by f1480187

[Jesper Rahlff]

okay I have droppet a convert node and locked that node to hold the polygons

the .bgeo file holds polygons now from a convert sop rather than an alembic.

calculate_transform_v02.hipnc

test_v2_1.bgeo

Edited November 29, 2017 by Jesper Rahlff

[f1480187]

It is very easy to select points manually here, and hard enough to do it procedurally, due to different topology and shape. Still possible, though.

Tried @satoru's hack from this thread:

 

pieces_to_origin_hack.hipnc

Edited November 29, 2017 by f1480187

[Noobini]

I took a bit of a detour with this...taking adv. of the fact that it's very pointy...

Edited November 29, 2017 by Noobini

[Jesper Rahlff]

Thanks guys. I will play around with it. I really want to keep everything as procedural as possible even though it might mean more work for me  the purpose anyway is for me to be better at Houdini-ing.

Cheers

 

update: F1 I gotta say, brilliant to take advantage of a visualization tool on the edit. I would never have come up with that! 

Edited November 29, 2017 by Jesper Rahlff

[Jesper Rahlff]

15 hours ago, Noobini said:

I took a bit of a detour with this...taking adv. of the fact that it's very pointy...

great idea Noobini. works very well

[bonassus]

I'm trying to understand vex creating the x,y,z vectors in the example given here. 

Quote

vector origin = detail(1, "origin");
vector dir = origin - point(0, "P", 0);

vector y = normalize(-dir);
vector x = normalize(cross(y, {1, 2, 3}));
vector z = normalize(cross(x, y));
matrix3 rot = set(x, y, z);
4@xform = rot;
translate(4@xform, origin);
@P *= invert(4@xform);

I don't understand why vector x is calculated by crossing y with {1,2,3}. does any one have an answer that would explain this?

[f1480187]

@bonassus that will take an arbitrary perpendicular to y. Using random constant usually enough, except it may break with vectors collinear to the constant. rot is an orthonormal matrix with y pointing at dir and arbitrary rotation around y axis.

[bonassus]

On 12/31/2018 at 6:49 PM, f1480187 said:

@bonassus that will take an arbitrary perpendicular to y. Using random constant usually enough, except it may break with vectors collinear to the constant. rot is an orthonormal matrix with y pointing at dir and arbitrary rotation around y axis.

ok it's an arbitrary vector. thanks for the response. i kind of understand...