Offset Texture with Vertex Color Attribute

[Ferdinand13]

Hey Juanjo,

I've got the following issue: I would like to use the colour attribute of the underlying geometry, to drive the offset for a texture I intend to use in the material for this geometry. In my case, I'd like these colour values to affect the texture offset for each little bar of wood.

In both Redshift and even Unreal Engine, piping a colour value into a transform/translate input means that it will use the red and green channels for X and Y, therefore giving me a different texture offset for each piece of wood.

In Octane, I've tried piping the Color Vertex Attribute node into the translation input of a Transform 2D node (that controls the albedo texture), but unfortunately it doesn't work.

I then tried to find any utility nodes that would let me turn the Color Vertex Attribute node's colour output somehow into the 3float input the Transform 2D node expects, but there doesn't seem to be any combination that can do that either.

Would you have any idea, how I would be able to use those colour values I've got on my geometry to drive the texture offset as described? That'd be great!

[Meet]

I have tried the same thing before and realized that octane transform can't take any input. This might be helpful to you though viewtopic.php?f=73&t=69211
Random tiling using OSL driven by a texture

[Ferdinand13]

I have tried the same thing before and realized that octane transform can't take any input. This might be helpful to you though viewtopic.php?f=73&t=69211
Random tiling using OSL driven by a texture

Thanks a lot! I checked out the other post and there's a lot in there that I haven't tried yet. Will do that now

However, the main issue would probably be that this is based around instancing, but in my case I'm dealing with full geometry, no instances no nothing. Just lots of polygons that each have a different colour (which I would like to use to drive the offset).

Let's see what the other post offers, but if it's still based on the instancing workflow, it probably won't help in my case (unless I turn the setup around completely ).

@Juanjo, is there any way for Octane to support these types of variables in the material context? Seems like pretty basic functionality, but of course I might be wrong.

[Ferdinand13]

I have tried the same thing before and realized that octane transform can't take any input. This might be helpful to you though viewtopic.php?f=73&t=69211
Random tiling using OSL driven by a texture

OK, so reading through the other post, it seems like this should work a) within the Solaris context (which is how my current setup works) and b) using non-instanced geo as well.

I've tried, using this setup, which - at least in my mind - should work:

But what I get when doing that (and then firing up Octane) are the following console messages:

Code: Select all

unknown Octane pin or attribute ID: HO_OSL_rawCode type: string
unknown Octane material node PinId: rndm

Any idea what's going wrong here? Thanks for letting me know

[juanjgon]

Do you know if this setup works in the main Houdini plugin to check if this is an Octane limitation? Sorry, if you have a Solaris related question, you should open a topic in the Hydra/Solaris subforum.

Thanks,
-Juanjo

[Ferdinand13]

Do you know if this setup works in the main Houdini plugin to check if this is an Octane limitation? Sorry, if you have a Solaris related question, you should open a topic in the Hydra/Solaris subforum.

Thanks,
-Juanjo

Thanks Juanjo. Already did that, but replies on the Hydra/Solaris forum are slim pickings unfortunately (and there's no documentation whatsoever).

Either way, I dug a little deeper in the /obj context and actually managed to make this setup work, by declaring the "Cd" variable under "Vertex Vector Attrs." in the Octane Parms as you can see here:

So this works, offsetting the texture as expected. Hooray!

Unfortunately this same setup throws up the error as discussed, when using it inside Hydra/Solaris