Very cool!

bookmark

I use a technique which is to subtract the output from a diffuse node from the output of a clay or toon node driving the SSS effect in the ambient. My reasoning is much the same as yours, i.e. that it doesn't require specific linking or setting of the keylight position and reacts to all lights. Looking at your nodes it looks like the principal may in fact be a similar but simpler to the diffuse driven (non-linear) colorramp gradient feeding the clay node. The right arm glow in the first image maybe due to too high a value on the translucency. You could reduce this for selective body parts selectively by connecting an intermediate texture map. Nice work, though, I'll definitely give it a try. Bill

BM, :-)

Did something similar, but with 30 nodes instead.

What its really cool about this node setup is that once its done, you get incredible results no mater how many lights, camera views, ect.

Its cool that it works everytime! pluss it works on every figure!, just save the scene, load your characters and lights and render!!!

no more re-runs or node tweaking hazzles!

warpo

bookmark

.

.

bookmark

.bm.

Very cool technique. Excellent stuff. IMO, the image in #2 has a slightly hollow/glowing look that often accompanies translucence SSS systems. However #3 is really great. Also, there are green bands on her stomach that look a little odd - present on both images.

.

Thank you for detailing and organizing your shader setup, that is a great teaching help. It's probably the texture...she feels too smooth and monochrome to me. This is not a criticism of the SSS exploration. Excellent contribution, the march to conquer the shader room continues! ::::: Opera :::::

Thank you, bagginsbill, your posts are always useful to read.

Sings "bookmark, bookmark, bookmark, lal-lal-laa!"

bkmk :)

thanks for posting this , brilliant work

bookmark

bmk

warpo - can u PLEEEEZE do a screenshot of the nodes u used - the effect is awesome! I'm just learning about nodes n stuff and want to improve on my basic textures - Thanx

I wonder if someone could do a step by step version of this tut ...for us Nodophobes it looks terribly complicated in the image tho no doubt much easier than it looks ....but where to start etc..

I agree. I've a hazy idea of how to apply certain nodes, but some help would be invaluable :-)

These are very nice. Question: Once I get the Nodes all setup, How do I Save this as a Material File or a Shader Spider File???? Cheers DR

Just follow the above example and you are ready to rock LOL my node setup is about 30 nodes per material and a real pain to get started with, but fear not! cause I'm writing a Phyton script as times allows, to load the nodes automatically and will be happy to share it as soon as its finished Good thing is that once the nodes are loaded you don't need to touch them again if you make changes to lights, cameras, ect. For now, just follow the above example and you can't go wrong! o_~ just add some extra blinn nodes for highlights here and there and you'll get similar results as mine. warpo

Mariner: Go to the materials tab in your library and add it as a material collection by pressing the + icon warpo

You guys are great for sharing all this stuff! I like to putter around a lot - try settings, render, save, try different settings, AD NAUSEUM - but have no trouble letting someone else do the work if they want - like you! This is great! Thanks a bunch! Larry F

Lower the Back Light and Fastscatter node intensity to taste that will give you a more subtle SSS effect warpo

Mariner - that looks terrific! How about a test render bypassing the front-side SSS part so we can see what the contribution is? Just connect the top clay node to the simple color next to it. This will remove the color ramp and just use the straight texture. I'm curious about how this is working with other textures and characters. I don't have many good ones.

Bagginsbill Could you give me a quick pick of how you want it disconnected connected???? Cheers DR

Looks great... Thanks for sharing.

Attached Link: http://www.renderosity.com/viewed.ez?galleryid=1142123

that render certainly has my attention. thanks for continuing the thread

.

Thank you for sharing your knowledge and new found ideas so generously.

Hi, yup! thank you for sharing the technique. Ive figure it out what it will be... cool technique! BOOKMARK this guys!

bagginsbill, a couple of questions.... 1) in post 37, you say it is the original from post 1, but "modified a little". Is the arrangement in post 1 still your latest and greatest, or are you posting the definitive final somewhere else? 2) some models have many groups. is it necessary/good to apply the full material to all groups, like eyelash, pupil, toenails, etc.,? 3) if applying this shader tree to all/many groups, is there a hit on render time? 4) i use face_off's shaders, and there are several settings he has that I would not want to be without. a) "oiliness" b) skin highlight strength c) granite displacement/bump strength and a few others if one where to build the tree in post1 here, and save as a material, and then apply it to many parts of a model, I can't see where the gain would be. Everytime you needed to tweak, wouldn't you have to open the tree on every body part (group) and change settings on various shaders? In other words, how is this tree practical without a universal "top-level friendly" setting controller? I am not dissing your work here, only seeing how it would be practical in production. Thank you ::::: Opera :::::

Hello operaguy! 1) Well nothing is ever final with me. In and of itself, the shader in post 1 works pretty well when it works. However, tuning and tweaking this shader is a pain. I like to be able to change one number and have it produce a single, conceptually simple effect. So for example, to get make this model more or less tanned, you have to change several of these settings. I started down that path when I posted the render #37. And then face_off so nicely critiqued my render and I wanted to address those points. To my mind, his crits should each have a simple obvious knob in the shader. The way it is built right now they don't. So I'm redesigning the whole thing. Unfortunately, the result is about 3 times as many nodes!!! The math isn't complicated, its just that if you want a single knob to alter 5 other settings in non-linear ways, you need a node for each math operator. I wish Poser had a Python shader node and I could just type in expressions like: out = bias(in1.red, in2) + bias(in1.green, 1-in2) + bias(in1.blue, 1-in2) That fairly simple formula requires nine nodes. Bah! When I get the next version suitably tweaked so the obvious controls are independant, I will publish it. It will be a couple weeks though. My "real job" is interfering and I have to go to Stockholm all next week. Meanwhile, all I really did for that pickture was tone down the specular node (I think the value was .15), make it white (which was a mistake), and I made the pink colors in the colorramp more red and changed the zone it affected by reducing the colorramp input. (I think I made it .7) 2) If the nails are not "painted", then yes apply the shader there too. Especially if you are going to back-light the hand or foot, you need it. If the nail is painted, then no. For non-skin material zones, this one doesn't apply at all. It is a very poor workflow to have to edit skintorso, save the mat, then apply to the other 6-7 zones. Then do the same for head zones. Totally bad. I found a "MatClone" python script by Kenneth Mort aka TromNek that helped. It never got past "beta" but I tweaked it to work for me. 3) Well there is always a small increase in render time with each additional node. But it is small. Really small. Nothing compared to changing render settings or going to a higher shadow map size. Remember, the shader for skin is only being evaluated where the renderer "sees" the skin. So if the figure only takes up 20% of your image, this shader only affects 20% of the render time. 4) Absolutely right. It is a huge waste of time to tweak each zone or even to save and load for each zone. But I'm going to make a Python script that I think will come in extremely handy. Not just for my materials, but any materials. The idea is this: Use the script to label certain nodes in a special way. For example, suppose there is a math node that controls the amount of front-side SSS. We change the node from "Math_Function" to "Math_Function[Front-side SSS]". Now the other part of my script would know (because of the bracketed name) that it needs a slider for "Front-side SSS". For a given figure, you would move the slider and it would adjust ALL INSTANCES of this specially labelled node in all the material zones throughout the figure, or even the whole scene if you wanted it. This opens up unbelievable possibilities. For example, you could take any material you got from anywhere (free or pay), mark it up as described above, and then my script would present you a global dialog that could control all the marked-up materials wherever they are in real time. Also, since such parameters can be animated, you could get them to be altered through an animation and easily control these effects from one place. The mind boggles! I don't know why Poser doesn't have such a feature. Seems obvious to me. It's going to take me a while to write it because I don't know TK well. But I do know Python really well. Once this script is available, you wil be able to use it to control really complex materials like mine or face_offs with ease. And nobody will need to do any more coding like face_off had to do. (I've never looked at his scripts - don't have them - but they must be a bitch!) Coding this will take quite a while and if somebody wants to help with it, I'd love that. Well like I said, gotta do some work over the next week. But we'll talk again when I'm back.

darn those day jobs and trips to scandanavia! Good luck on this ambitious project, will look forward to seeing your progress. Thanks for the detailed response. ::: og :::

"... if somebody wants to help with it, I'd love that."
Just post in the Python forum if you want help with something specific.

Baggins.... The script you have described 4) of msg #43 is pretty much exactly the way the RealSkinShader and Unimesh scripts work. They place nodes for each material, name them appropriately, and as you tweak the settings through the dialog, the script changed all the nodes for all the materials.

Face_Off,

I'm not sure what you're getting at. I agree that your front end to your shader system rewrites parameters in your shader tree. However, it doesn't LEARN them from your shader tree, it already knows them, right? I'm talking about a script that, given ANY material, is able to detect control nodes that are meant to be tweaked THROUGH THE SCRIPT itself. In other words, you hard-coded things like "oiliness" and "blush" or whatever in your script. If you change the material nodes, you'll have to change your script. If you add new features to the nodes, like "pimples" or "tan lines", you'll have to add new sliders to your dialog box.

If this is not the case, please educate me because I've never known any of your scripts to be applicable to other people's shader trees. If there is some way of arranging my nodes in my shader, such that people who have your python scripts could control my shader through your scripts, that would be interesting. However, I don't recall you publishing that compatibility with your front end derives from merely having certain agreed upon node names in your material. As far as I know, your scripts WRITE the materials. Your script causes the materials to be in the form you have pre-defined it to be. At least that's my understanding.

The python script I'm describing would be able to tell from the names of nodes alone, that they are useful control points to be presented to the user. Further, that these control points are common and to be shared across material zones, so that moving a slider for a given control parameter must be updated in every material wherein that control parameter is defined. It doesn't require any pre-agreement between the script and the shader tree.

The idea here is similar to the full body morph dials on a figure. If you load the morph, the UI presents a single dial for it. The fact that to implement the morph requires altering a partial body morph in twelve different body groups is completely hidden from the user. Similarly, for the materials in a figure, if you suitably mark a bunch of math nodes (using the square brackets) then the script presents a single dial for the complete set of nodes.

It is enough, for example to define a math_function whose name is "math_function[Tan Lines]" in a material. The square brackets would be picked up by the script and presented as a slider. Even if other materials are completely different in layout and content, if they have a node with "[Tan lines]" in the name, then those nodes get included. The script doesn't know what the control parameter really does, it just knows to present a slider called "Tan Lines" and when you move it, update every node in every mat zone that has a node with that substring in its name.
A more general approach would involve more that just the math_function node, but I think I could accomplish a tremendous amount of generality with that alone.

bagginsbill, splendid idea! I only see one problem: most nodes have more than one parameter, so how would your script know which one to control? Or are you limiting this to a certain type of node, say only math nodes, where you always change the same parameter?
Message edited on: 01/29/2006 17:58

Ah, ok - I'm with you. I originally coded the system to be similar to what you describe, however in practice some issues came up. The main one being if the user tweaks a particular material (say SkinHead), but not the other materials, you'll get a seam at the neck (since the materials are different) - so there became a need to enforce a certain node structure. Also, it's possible for the user to corrupt a node setup by disconnecting something, so any script that changes the nodes needs to be able to "fix" the node network. So in the end it becaome an impractical solution, and I went with a system with enforces a particular node setup, and allows the user to change the node values via the python interface. The next version of the system (which I am working on at the moment) allows a bit more flexibility, in that the user can change the node network, and as long as particular ndoes are present, and connected, the script will assume the node network is valid, and just change the values.

odf - That's the only problem you see? Fantastic :) I'm sure more problems will reveal themselves once it come into being and starts getting used. In the first version, I believe that limiting it to math nodes or color math nodes is reasonable. Here's why. Every node parameter is connected to another node or it is not. If it is connected, its value is multiplied with the connected node's output. If its not connected, its value is used directly. Suppose you have an unconnected parameter you want to control with the script. Set it to 1, or white, and connect that to a marked math node. Now you apply your setting in the marked math node, and it works just like it was in the parameter itself. Or suppose you have a connected parameter. Insert a math node between the parameter and its node input. Move the parameter value to the math node, and set the parameter to 1. Works the same. One variation would be to let you use the math node second value. Use a second set of subscripts. For example, if I want to tweak the exponent of a "power" node to control "fall off", I'd call it "math_function[][Fall off]". The empty brackets just mean skip the first value, we're controlling the second. I could use both, too, as in "math_function[Strength][Fall off]". This would be perfect for a lot of nodes. It's a bit of a waste to plug into math nodes instead of making settings directly, but it sure simplifies the script. SO I was thinking that the first version would use only those nodes. Finally, in order to maximize the maintainability of your shaders, I think it makes sense to only put controls in separate nodes that don't do any work. For example, if you decided to replace a controllable specular node with a combination of blinn and phong added together, you'd have to do some node node renaming to keep your ability to control "Total Specular" with a knob. IF you had the knob node by itself, it would be simple to just rewire it into the new subtree.

Face_off - I totally get that you wanted to make your system as foolproof as possible. Its a classic tradeoff. The script I'm intending to make is no substitute for a well-crafted integrated solution like yours. For people who make new shaders, like me, my proposed script will get around the editing/tweaking problems. All I want is to be able to quickly manipulate some key parameters in a complex shader tree on many zones. If those zones don't agree or are corrupted, so be it. I also think the script will make it easier for me to share my complex shaders - having obvious knobs is important. People will have more fun with them if they don't have to understand and navigate the nodes to make adjustments. BTW: Face_off, did you know that the three parameters of a Normal node can be used to compute the dot product of a particular vector with the normal directly? I was reading your shader thing and you extract each component of the vector, then multiply. That's a waste of effort. Just put the 3 coefficients into the normal node directly. The only problem with it is that the normal node is interpreted as a "color" and gets converted to a scalar by summing the 3 components and dividing by 3. But if you premultiply your coefficients by 3, or multiply by 3 in the next stage, you are good to go.