Hi,
I have an issue with OSL shading in Houdini Solaris(18.5.499) using (HtoA 5.6.0.2).
I have written the below OSL shader. This works perfectly fine in Maya (MtoA 4.2.1.1), but when setting up the EXACT same shader network in Houdini the OSL part of it does not work. It doesn't seem to reading the "input" properly like it does in Maya.
It is definitely the OSL part of the shading network that is causing an issue, because I have tested WITHOUT the OSL shader in Maya and Houdini and then I get the same result. Only when I plug in the OSL shader does it stop working properly in Houdini.
1. Is there any reason why this shouldn't work in Houdini Solaris?
2. What can I do to make it work in Solaris or is this a bug?
OSL shader (same in Houdini and Maya).
Houdini Shader Network:
Houdini result:
Maya shader network and result:
Maya(left) and Houdini(right) result without OSL shader, just with aiUtility and Random (which I want to plug into OSL input):
Not known for certain why this bugs out.
I wrote a new node that does not need the Arnold utility or the random nodes and instead just wrote the functionalities needed directly into the OSL node ( less noodle chaos )
Added a seed in the UI.
Try it and see if its better.
If it works, you can just move the stuff you need UI access to into the UI area of the code.
shader probabilitymix ( int Seed = 42, output color Out = 0, ) { int Hash; string Name = "theThing(tm)"; getattribute("nodeName", Name); Hash = hash(Name); float ratio = noise("cell", vector(abs(Hash), abs(Seed), 11)); Out = mix(0,1, ratio); vector a = vector (1,0,0); vector b = vector (0,1,0); ratio < 0.5 ? Out = a : Out = b; }
Hey!
Thanks for taking a look at this!
I tried putting your OSL code into my Solaris scene and I am not getting the same result as you unfortunately. Still only a block of colours. If I have the seed set to anything below 1.0 it turn red like below and if the value is 1.0 and over it turn green.
Houdini result of Mads code:
Also I tried your code in Maya and not getting the same result as you in 3Ds Max?
Maya result of Mads code:
OSL should evaluate the same no matter the software?
Thanks,
I am not happy to hear that this isn't working.
It can then only be because Maya and Houdini is not on par with the OSL specifications.
getattribute("nodeName",something);
SHOULD be a generic construct, not a max thing IIRC.
It also worries me that your original shader doesnt work as it is super generic code, so I think its a case of OSL not really being mature enough in either of those hosts, or in your concrete case, Houdini.
I wont be able to move further, so wait for an Arnold/Houdini dev to come around and probe your concrete case.
Hi Klaus!
I was able to reproduce your issue. It seems that connections to inline OSL nodes are not correctly interpreted in Solaris. I'm still looking for the root cause, so no idea what's going on exactly, but I'll let you know once I have a solution.
Cheers,
Pal.
Okay that is great news. I feel like this was working in a previous version, as the above OSL have been used on some of our furry creatures before. But now in 18.5 it has stopped working.
Regarding a fix for this in the short term do you have any solution? This has messed with our furShader quite a bit.
Thank you,
Klaus
You could build a small Arnold core node rig that does the filtering.
Where the Compare node in "math" would do it for your 2 conditions.
This is an issue with our shader translator (that translates Arnold shaders to the USD stage in Solaris). It's not something you can fix on your side without modifying the shader translator.
Hi Klaus!
I have a local solution that fixes your issue, but I'm still investigating the best way to integrate it into HtoA.
For a short-term solution, I attached the updated version of the Arnold shader translator, arnold.py.zip. Just extract the "arnold.py" file inside, and replace "scripts/python/husdshadertranslators/arnold.py" inside your htoa installation.
Cheers,
Pal.
Hey!
I finally got around to test this today. This solution works and our OSL shader works once again!
As this is a local fix, when can we expect a fix for this in the normal release? Is this something that would just be automatically fixed in the next release?
Thanks a lot for the help!
Hey!
Yes, correct, we already have a fix (though a different approach) for this issue in our release branch.
Cheers,
Pal.
Can't find what you're looking for? Ask the community or share your knowledge.