Edge Displacement on fractured pieces

[rayman]

You have to reorient offset matrices for each wall to match direction of surface. There are many ways to do it, I`m going to show you how, but again it is up to you how to do it for your scenes. This initial setup you can do manually or procedurally, it depends entirely on your scene.

I have already create another file with 2 direction displacement on reoriented pieces, but forgot to post it. Tonight probably.

[rayman]

Heres some renders from updated setup.

I hope it looks like something useful now (:

[Aaron_]

wow that's awesome with  2 direction displacement and also displacement mask on it.

Can't wait to see your scene file.

Appreciate your work.

Dude you have to create one little tutorial about this stuff and send it for example to cmiVFX, will be good for you and for us as well:)

[JaydenDP]

wow that's awesome with  2 direction displacement and also displacement mask on it.

Can't wait to see your scene file.

Appreciate your work.

Dude you have to create one little tutorial about this stuff and send it for example to cmiVFX, will be good for you and for us as well:)

 

+1

That would be great

[rayman]

hip

SHOP_edgedisp_v07.hipnc

[magneto]

Thanks rayman, your second file looks a lot better, and is a great example to learn.

 

I have a couple of questions about your first file if you don't mind

 

1. It seems like the fractured pieces are not fused. Is this intentional? Because when you use connectivity it actually shows some pieces as multiple because of this.

 

2. Is Connectivity creating id attribute necessary?

 

3. In your simple geo animation, you are also exporting w vector but this doesn't seem to be used. Is this necessary?

 

4. Can you use PolyFrame SOP's Bitangent instead of calculating zax yourself?

 

5. I know you said you didn't use matrices but do you know if it's possible to get matrix attributes inside a shader? I modified your file to export a matrix and read it inside the shader but the resulting render is screwed up very badly even though I compared they are the exact same matrix as the one your are creating. So I don't know if Houdini doesn't allow matrix attributes from being read inside a shader from the geometry?

 

 

Thanks again.

[Netvudu]

Before mighty Rayman answers, I can help with number 3 and 4.

 

3. "w" is angular velocity, and IMHO is indeed being used. Just give a try and bypass it, and you´ll see the simulation changes. I think it is passing angular velocity to the pieces, or that´s what I think....which is cool because I never understood why "angvel" didn´t work.

 

4.  Polyframe´s bitangent does NOT necessarily match the zax vector. In fact as we previously discussed, the yax (Polyframe´s tangent) is put through a double cross product "just in case", even though it works in this case as it is.

 

We´ll wait for Rayman´s own reply regarding these and other questions.

This is an amazingly educational thread. I´m learning heaps from these files.

[rayman]

Hello. I don`t mind answering a questions at all (:

 

1.Nope. This one is caused by assemble node. It looks like if you provide inside group name it will separate pieces.

2.In this case - no. As I said, the whole matrix part I took from another scene, where I composed matrices for each piece, instead of points, so just ignore it.

3.As Javier mentioned - i`m using it to set some random initial angular velocities.

4.

4.  Polyframe´s bitangent does NOT necessarily match the zax vector. In fact as we previously discussed, the yax (Polyframe´s tangent) is put through a double cross product "just in case", even though it works in this case as it is.

The only thing I can add is that you can entirely ignore Poly Frame node. Just create 2 normals per piece(first and second prim normals for example), rename them to xax and yax and copy them to all of the piece`s points.

5.I don`t know. It is possible that the matrices are transformed to camera space just like the P attribute. If you can, upload your file so we can investigate.

[magneto]

Thanks alot guys. I didn't know "w" was angular velocity, thought it was weight or something

 

I never saw this technique of animating the RBD pieces, which is also cool.

 

As for #5, I just downloaded your first scene and exported the offset matrix directly as matrix (16 floats) without modifying anything else. Also in the shader, changed the connections to your matrix to this new matrix, and the result is very different where you don't only get the Y axis displaced but also the pieces are not in the same orientation as they actually are. So like you said something is going on.

 

I colored the new nodes in red, but overall I only added 2 nodes. It would be really awesome if this mystery was uncovered, because I spent an hour yesterday but couldn't figure it out.

 

Thanks again guys

SHOP_edgedisp_v02_matrix.hipnc

[pezetko]

You need to invert the matrix in SHOP before you connect it into the multiply1 node (before displacement).

Then just add matrix to float and float to matrix conversion between bind5 (mat) and invert node (-> multiply1) and multiply2 node. And keep val14,24,34,44 unconnected on float to matrix. (I got strange results without this matrix to float and float to matrix conversion - Green nodes)

With that matrix to float and float to matrix conversion you can be sure that last (4th) column of that transform matrix is (0,0,0,1) so you have no position offset.

SHOP_edgedisp_v02_matrix_01.hipnc

Edited February 28, 2014 by pezetko

[magneto]

Thanks pezetko, I missed the invert when doing this quick example, but in my original file, I have it connected properly. But just like you said this still produces strange results. How does doing matrix to float and then float to matrix fixes it? When I rendered it was working, but don't know why.

 

Is this a bug? It has to be, right?

[Netvudu]

what´s your reason for doing this, Ryan? Are you trying to "asset-ize" as much as possible? because I was thinking the same...

[magneto]

Using a matrix instead of individual vectors to construct and deconstruct the matrix seems more logical to me, and allows me to recreate rayman's example scene my way, instead of copying it verbatim, which makes me understand the idea better.

 

That's why it would be great if we could solve why this difference occurs when using the matrix directly. I am not a shader expert, so any insight is appreciated

Edited February 28, 2014 by magneto

[teratera]

Hello, Rayman

 

Thanks for the file, very educational. I'm apologizing just in case for the question, because I can't say I fully understand the setup, but nevertheless... Why is that when I plug something different than a box shape (like a sphere or cylinder) it kind of not works properly? Displacement occurs on outside primitives and it all looks kind of not right. 

 

Is there something can be done about it? That would be really great, because your technique works beautifully.

[pezetko]

Reason why you need matrix to float and float to matrix conversion is becouse after multiplication of matrices in vopsop and then in shader you cannot be sure that last (4th) column of that transform matrix is (0,0,0,1) (in fact, it's not). If it's not zeroed then you have position offset of the origin, so perspective projection is wrong and you get wrong results from displacement. So easiest way of setting that last collumn to zero the origin offset is by using matrix to float and back nodes.

[magneto]

Thanks pezetko but isn't having an offset the goal? Even when you use the conversion nodes, you are still transferring the translation of the matrix since the last row is also connected.

 

Aside from this, I was looking at the second file and was wondering if there is a way to just use the inside and outside groups of the Voronoi Fracture? Why do we need to remove some points from this, which looks very hard to do procedurally? Can we just displace primitives in the shader so the outside primitives using these inside points are not affected?

 

 

 

Thanks

[pezetko]

Yes, sorry for confusion. That translation offset is maintained in first three components of 4th row as you mentioned. I'm used to transposed notation from robotics. So basicly "zeroing" last column (0,0,0,1) is there to maintain homogenous matrix. So you get correct matrix multiplication if you combine transformations by matrix multiplication. You can try to put some small value in any component of last column, the result will be that you will get some type of offset of rendered piece.

Edited March 1, 2014 by pezetko

[pezetko]

As I'm thinking about it right now, shouldn't be that position offset of each piece (mx_p) in last column of the transformation matrix instead of last row? That way it makes much more sense to me.

Ok Houdini is using row-major version of transformation matrix.
(http://www.sidefx.com/docs/houdini10.0/hom/hou/Matrix4)

Edited March 1, 2014 by pezetko

[magneto]

My understanding is that the first 3 components of a matrix defines its orientation and the last component defines where it is in space (translation). That's why matrix3 values do not define a translation.

 

Also if you compare the values of each vector to the matrix itself at the display node, you can see they match 100%. After this point the matrix doesn't change in the shader, only inverted once.

 

Proof that there is nothing wrong with the matrix, displacing the geometry in SOPs using the same matrix directly:

 

Edited March 1, 2014 by magneto

[pezetko]

Yes, you are right.
First 3x3 matrix in 3d space describe rotation and scale. That fourth row/column in 4x4 matrix is there for position. If the position is defined by vector4 (x,y,z,1) it makes sense to put position in 4th row. And it's also mentioned in help (http://www.sidefx.com/docs/houdini10.0/hom/hou/Matrix4). As I mentiond I'm used to column major format.