Weird, I set up a debian jessie based build environment precisely to avoid this issue.
Could you post the error somewhere?
Weird, I set up a debian jessie based build environment precisely to avoid this issue.
Could you post the error somewhere?
Sure, here’s a cl screenshot.
as text:
./blender: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version CXXABI_1.3.11' not found (required by ./blender) ./blender: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version
GLIBCXX_3.4.22’ not found (required by ./blender)
./blender: /lib/x86_64-linux-gnu/libm.so.6: version GLIBC_2.27' not found (required by ./blender) ./blender: /lib/x86_64-linux-gnu/libc.so.6: version
GLIBC_2.25’ not found (required by ./blender)
Hi.
With last commit of yesterday, Rendered preview works but Render image does not work (you get only black result in hair).
Hey @YAFU,
It may be because of the Diffuse fallback - I had to turn it off because it wasn’t compatible with OSL.
Can you (or anyone who’s getting the black hair error) git bisect
the branch and tell me the commit where it stopped working?
I forgot to say that I’m in Linux just in case
I have no idea how “git bisect” is used. But
Hash 07696962c4d: Render image works well.
Hash 25677d77385: Render image only gives black hair result.
In both Rendered preview they seem to be working well.
Hm, in 25677d7738530d8f827e5ac960ccded6b128d897 I added the last missing feature (Chiang’s primary reflection roughness modifier), so I had to (in layman terms) take all the curve geometry data out of the shader’s main data source. This change should only affect OSL, though.
Can you try with 4774e906e19816b720c20271b9f9db28bb89debe and see if it’s fixed? If not (or it crashes outright), please send me a .blend
with the bug (and the stacktrace if your OS gives it).
Hi.
“Render Image” still does not work with new commits, hair looks black (but works in Rendered preview).
It happens with any file, anyway here one:
http://pasteall.org/blend/index.php?id=49628
But better you wait until Lukas or another developer can confirm the problem, there is a possibility that I am doing something wrong.
I’m seeing the same error too (Linux Mint (18.3)). Seems like the GLIBC 2.23 Mint comes with isn’t good enough (ldd --version). But to be honest, I don’t know if there is anything we can do about that.
No need @YAFU - I could reproduce it (I was using a complex node tree to test, you used the shader alone).
I’ll come back later in the week and tell you when and how I fixed it
Hey all,
Brecht fixed @YAFU’s bug in 1fac3b7da05ada27d8a41c114283394b5a505ebb. (I didn’t know I had to tell Cycles how many data sources I was using ).
I also added the following features:
Please, have a look at my branch and tell me if you find any other bugs. As previously, I’ll release a set of builds on Monday.
Can we expect a more user-friendly way of altering melanin levels akin to some of the other production renderer shaders out there?
Hey @m9105826,
Do you mean, like Arnold’s Standard Hair?
About the melanin - I can certainly add two extra sockets, like Arnold’s, to set the melanin quantities (and use them if you set “Melanin concentration”).
As for the rest - I think they may be added too.
In any case, I’ll ask Brecht and Lukas what they think about it.
Here’s a new Linux build based on the latest commit (7780d306).
I think I solved the problem that caused the build to not work on older distros, now it should work on every distro that can run official builds.
The melanin controls certainly should get their own dedicated sockets, putting them in the color field was just a quick hack I think.
Hey all,
Builds for this week’s commits are now up.
Let’s recap the added features:
I also added:
Is constrained melanin randomization possible with the new setup? It can go a long way towards creating a realistic look, especially for fur.
I’m not sure whether this should be part of the node itself, I’d rather add a per-hair random value to some input node to give more flexibility.
Melanin randomization is physically based part of the shader, it should be in the node. On top of that, it could be useful to have some hair ID attribute for artistic control.
Yep, that looks like what I was expecting!