Page MenuHome

Smoothstep Shader Node implementation
Needs RevisionPublic

Authored by Alexander Romanov (a.romanov) on Oct 27 2014, 9:33 AM.

Details

Summary

Here is the implementation of the Smoothstep Shader Node which is based on the built-in smoothstep GLSL function.

This node can be used instead of the Squeeze Value node in many cases, and is much faster.

If you like it, we could also submit patches for other built-ins such as clamp, ceil, sqrt etc.

Thanks,

Alexander (Blend4Web Team).

Diff Detail

Event Timeline

Yuri Kovelenov (yurikovelenov) retitled this revision from smoothstep shader node to Smoothstep Shader Node implementation.Nov 26 2014, 5:58 PM
Yuri Kovelenov (yurikovelenov) updated this object.
Sergey Sharybin (sergey) requested changes to this revision.

General rule here is we don't accept nodes which are simple to implement using existing nodes in the the tree. This keeps nodes as a small basis usable by everyone. it's also not totally clear if render engine will benefit form this. It would mean you'll need to support more basis nodes which would make kernel bigger and slower for cases you don't have this node (well, ok, talking about Cycles mainly here but adding nodes to just BI is weird anyway).

If it's for GLSL performance then we should look into better handling of those things as a part of viewport project. Or maybe our gpu/ code can do some shader compile-time optimization and squash some node setup into a specialized GLSL function.

This revision now requires changes to proceed.Jan 28 2015, 7:04 PM

General rule here is we don't accept nodes which are simple to implement using existing nodes in the the tree. This keeps nodes as a small basis usable by everyone. it's also not totally clear if render engine will benefit form this. It would mean you'll need to support more basis nodes which would make kernel bigger and slower for cases you don't have this node (well, ok, talking about Cycles mainly here but adding nodes to just BI is weird anyway).
If it's for GLSL performance then we should look into better handling of those things as a part of viewport project. Or maybe our gpu/ code can do some shader compile-time optimization and squash some node setup into a specialized GLSL function.

Our motivation is rather clear. The new GLSL-based Blender viewport and any external real-time engines would benefit from fast GLSL-based nodes.

Yes, the SMOOTHSTEP node can be implemented using already existing node, but it is not a simple setup - now we use 3 subtract, 1 divide, 3 multiply, 1 min and 1 max nodes - this is 9 nodes in total. This way, such already existing nodes as sine and cosine (inside the math node) could be also implemented with simple math operations, but this could be rather ineffective and unusable solution.

That's why we propose to add this node to the shader nodes. If its absence in Cycles is your concern, we could also submit a patch for Cycles.
What do you think?

"""(...) the SMOOTHSTEP node can be implemented using already existing node (...) 9 nodes in total."""

That is simply not true. The smooth step function does the same as ColorRamp with Ease interpolation.

I'm a total outsider to this topic but what would seem as a good solution to me is detecting this special case (ColorRamp node with Ease interpolation) when the GLSL shader is being compiled, and using the smoothstep function directly.
And also, the ColorRamp node could be improved to more user comfort. I believe that is a better way to go than adding another node type.