Triplanar node - random offset/rotation

[andy_clarke]

Hi guys,

I have a shader developed by another artist using a triplanar texture node. Both the random texture offset and random texture rotation options are ticked and the random mode is set to Face Material ID. I now need to replicate the exact rotation and offset on a new mesh with a new shader and I can't figure out how - with the setup exactly the same on both, I'm getting different results. The random mode is set to 'face material ID' on both the original shader and the new shader, and both materials have the same material ID number (2). (Everything else is the same - object space, rest attributes, etc.)

I've tried creating an attribute on the new mesh to feed into the 'user attribute' random mode option and I can see in the IPR that the seed changes when I change the value, e.g. from 1 to 2. So that's great, I have control, but I can't figure out what seed value the original triplanar texture is reading to match it up.

Does anyone know:
a. how to find out what seed value the triplanar node is reading (with random mode set to 'Face Material ID')
b. if there's another way of matching the original offset/rotation without manually tweaking the parameters (it's not an easy texture to line up!)

Many thanks,
Andy

[Gosho.Genchev]

Hey andy_clarke ,

It would be ideal if you could provide us with an example hip file.

The "Face MaterialID" option will only work if you have added a "face_mtlIDs" primitive integer attribute to your geometry. Otherwise, the value is assumed "0" for all primitives.
The "User Attribute" mode will not directly match 1:1 with a face_mtlIDs attribute, even if the values are the same.

Therefore:

a. how to find out what seed value the triplanar node is reading (with random mode set to 'Face Material ID')

Unless it was specifically added to the geometry, it is assumed 0.

b. if there's another way of matching the original offset/rotation without manually tweaking the parameters (it's not an easy texture to line up!)

I'll see what I can do if you send a scene my way.

Best regards!

[andy_clarke]

Hi Gosho.Genchev ,

Thanks for the reply. Neither mesh has a 'face_mtlIDs' attribute set, so maybe there is something else going on in this scene that I've missed. If I could send it over for you to take a look that would be great! Is there a secure method of getting it to you? The scene is client-sensitive.

Many thanks,
Andy

[Gosho.Genchev]

Hey andy_clarke ,

You can use the Support request form here: LINK

Best regards!

[andy_clarke]

Thanks Gosho.Genchev , I've just sent you a scene to test.

Cheers,
Andy

[Gosho.Genchev]

Hey andy_clarke ,

An interesting case for sure.

I noticed that rendering the 'chocolate' group on its own produces no offset in the TriPlanar projection when switching between the 2 geometries. You can verify this on your end with a Blast SOP -> group: chocoalte ; "Delete Non-Selected". So in this case everything looks as it should.

Adding another piece of geometry seems to break the projection. I'll keep digging to figure out why - I'm still not sure if that is a bug, or simply a side effect of the way the scene is set up. Either way we'll try to think of something for the future.

Regardless, it seems possible to circumvent the issue altogether by partitioning the export for V-Ray to treat each group as a separate piece of geometry internally. You can do this by:
1. Drop a Name from Groups SOP after the "OUT" Null in your chain. Set the "Group Mask" parameter to "*" - the wildcard tells Houdini to generate a unique name attribute value for each group.
2. Drop a Pack SOP. Enable "Name Attribute" so a separate Packed Primitive is generated for each unique "@name" value. Disable "Create Packed Fragments" - internally, we export fragments to a single mesh plugin and as I mentioned above - we want to avoid this and export each primitive group in a separate object. This will only happen for Packed Primitives - not for Packed Fragments.

If you render this, you should get equivalent results between the 2 objects.


Additionally, I'd strongly recommed exporting your geometry to alembic files. Time to First Pixel will be significantly better the heavier your scene gets; VRScene export times will be significantly lower, and the VRScenes will be KBs instead of GBs; Memory usage will also be lower.
To do so:
1. Just like before - drop a Name from Groups SOP after the "OUT" Null in your chain. Set the "Group Mask" parameter to "*" - the wildcard tells Houdini to generate a unique name attribute value for each group.
2. Drop a ROP Alembic Output and enable "Build Hierarchy from Attribute". Specify "Path Attribute" to be "name".
3. Export the file and bring it back using an Alembic SOP - you should now have a separate alembic shape for each unique name value.
4. Drop a Material SOP and assign the materials, just as you did before. The only difference here is that instead of specifying the group as e.g. "bar", it needs to be "@path=/bar" - the Alembic export has generated a primitive string attribute called 'path' and its values are coming from the 'name' attribute that you created earlier using the Name from Groups SOP, and specified for partitioning in the Alembic ROP.
5. Render -> you should get proper resuts.



I've given the updated scene with a link to this forum thread to the colleagues from the support team - you should receive it soon.

Hope that helps!