Isn’t this Blender ARTISTS?
@VickyM72, this made my day.
I guess I have to break down the steps to reproduce that example so that we’re on the same page and you can see where the roadblocks are. Here we go:
The first roadblock is the Half-Lambert shader (picture 1) that is sadly missing in Cycles and for some reason cannot be implemented in OSL either. You can work around that problem by using a very big lamp, but as soon as a light source in Cycles is larger than zero, things will get noisy even in direct lighting mode. In fact the noise introduced by such a large lamp will be so bad, you’ll have to increase the number of samples by a factor of 400 or more (!) to get that clean gradient which BI produces by default and in almost no time at all.
A noise-free gradient is essential for the next step because the shader result will be fed into a color ramp that creates a flat 2D look (picture 2). By editing that color ramp, you can easily control the exact position and softness/hardness of each toon shadow edge. This is another roadblock for Cycles. A color ramp node is available, but there seems to be no way to feed shader results into it. There is a toon shader node, but it doesn’t work with color ramps either. With Cycles I currently see no way to create toon skin that shades in steps from beige to pink at constant brightness (i.e. the cartoon version of subsurface scattering).
Back to BI. By displacing the surface with a procedural texture (picture 3) and then animating that texture (picture 4), you can replace the clean CG look with one that resembles pencil and brush strokes (see picture 5 for a close up view). There are endless ways to customize that effect by modifying the noise function, the strength of displacement, the animation curve, the number of motion blur samples etc. You can also do a lot of other things, e.g. warp the normals instead of displace the surface. Here’s yet another roadblock for Cycles, because its motion blur implementation fails to capture animated textures.
Am I missing something? Feel free to point it out!
It can be implemented, but you’d need to pass in the light sources into the OSL shader and explicitly evaluate them.
A color ramp node is available, but there seems to be no way to feed shader results into it. There is a toon shader node, but it doesn’t work with color ramps either.
In contrast to the above solution, in order to feed a ramp with the result of the general radiance estimation, you’d need a sufficient amount of samples first, then evaluate the ramp. So within the design of OSL, this belongs into a post-process (e.g. the compositor).
Here’s yet another roadblock for Cycles, because its motion blur implementation fails to capture animated textures.
BI’s (vector) motion blur would fail to capture (non-displacing) textures as well. Deformation Motion Blur is obviously a desired (and planned) feature. Motion Blur based on subframe samples obviously works with both, but isn’t directly supported by Cycles (even though it would be simple to implement).
If this is the same half lambert that is presented in Valve’s paper http://www.valvesoftware.com/publications/2006/SIGGRAPH06_Course_ShadingInValvesSourceEngine.pdf it kind of looks dead easy to implement, unless I am missing something. (pseudo code) bdsf = color *( (diffuse(N) * 0.5) +0.5))^2) wouldn’t that work
it kind of looks dead easy to implement, unless I am missing something
You can’t define BSDFs in OSL itself.
why would you? Isn’t there already a Lambert shader if you call diffuse with no roughness I think it should be the same. IIRC that is how cycles diffuse shader works with no roughness its equivalent to a Lambert shader with roughness Oren-nayar
That code would be totally fine for OSL. We have a diffuse(N) closure BSDF.
You cannot evaluate closures directly within an OSL shader. In particular, you can add two closures, or multiply a closure by a color, but you cannot multiply two closures.
That requires a working getattribute() function. Currently you can pass lamp properties to shaders only through Python drivers. I did that once using nodes, but it was a pain to set up.
Half-Lambert softness should really be a lamp property, and the diffuse BSDF should process it by default. BI does that with hemi lamps, and there’s a patch to make it work with point lamps too.
I still from time to time use BI just for its look but the moment I need some real raytracing I switch to Cycles.
Both engines feed two different needs.
I’d probably use the fact that OSL is compiled at runtime and #include the data into the OSL script itself.
Half-Lambert softness should really be a lamp property, and the diffuse BSDF should process it by default. BI does that with hemi lamps, and there’s a patch to make it work with point lamps too.
BSDFs don’t know anything about lamps. I’m actually convinced now that all these things should stay in BI, far away from Cycles, because this is a barrel without bottom. Not everything that can be done, should be done.
And then edit the include file every time you move the lamp?
BSDFs don’t know anything about lamps. I’m actually convinced now that all these things should stay in BI, far away from Cycles, because this is a barrel without bottom. Not everything that can be done, should be done.
I’m not suggesting to hardcode these things into Cycles. But why isn’t it possible to write custom BSDFs that iterate over all the lamps in a scene and extract a particular user-defined property?
It would be autogenerated from the Lamp Data.
I’m not suggesting to hardcode these things into Cycles. But why isn’t it possible to write custom BSDFs that iterate over all the lamps in a scene and extract a particular user-defined property?
Again, BSDFs don’t know anything about lights by their definition. What you want to do is perfectly possible with an OSL shader, it’s just a matter of convenience of getting the light data into the shader.
The reason why I need the lamp data in the first place is precisely because of what I said before: It’s impossible to implement a Half-Lambert shader in OSL.
The node tree I showed you above is not a Half-Lambert shader but a procedural emission texture that imitates Half-Lambert’s angular light falloff based on the coordinates of one particular “lamp” (which could in fact be any other type of object).
Proper Half-Lambert in Cycles would be a BSDF, which indeed wouldn’t know anything about lamps. But we don’t have that, and I can’t be bothered to learn CUDA just to implement it. BI, especially with the lamp softness patch, gets the job done just fine.
This is also why OSL fails to impress me. OSL basically works on presets. A BSDF not already hardcoded into the renderer can’t be created with OSL either. You can only mix and apply textures to existing ones.
If you pass in the light data to the shader and loop through it and then pass that result into an emission shader, you have pretty much the same result as in BI. That is the way to emulate “classic” shaders in something like OSL.
Having Half-Lambert as a BSDF would not allow you to control which light is supposed to be Half-Lambert and it also would pick up on any form of light, which is probably not what you want.
Yes, but it becomes impractical if the OSL script needs to be recompiled every time a lamp moves, is added, is removed, or has any of its properties changed.
Having Half-Lambert as a BSDF would not allow you to control which light is supposed to be Half-Lambert and it also would pick up on any form of light, which is probably not what you want.
Does Cycles understand the concept of ultraviolet light and fluorescence? Emission that is invisible until it is picked up by a special BSDF and reflected as visible light? I guess that would solve the problem.
Yes, but it becomes impractical if the OSL script needs to be recompiled every time a lamp moves, is added, is removed, or has any of its properties changed.
That depends on how you pass in the data. You could also recompile the script only when adding/removing lights and pass the lights through generated nodes.
Does Cycles understand the concept of ultraviolet light and flourescence?
No.
Is there any render engine out there that currently has the ability to render out light paths outside of the visible spectrum, I’m pretty sure I have yet to see a case where a render engine actually has code for ultraviolet light (ditto for infrared light and X-rays)?
By the way…
The post-process wouldn’t know where to apply the ramp.
Since our fake Half-Lambert shader is noise-free and doesn’t require more than one sample, applying the ramp inside the shader would actually work. The problem is that we can’t use the color ramp widget to edit the ramp.
The post-process wouldn’t know where to apply the ramp.
Of course you’ll have to mask it out, if you don’t want it everywhere. I’m not saying it’s a particularly nice solution, I was explaining why you can’t ramp the result of a shader directly as-is.
The problem is that we can’t use the color ramp widget to edit the ramp.
Well, obviously it’s not a ready-made solution. You have to script some stuff here. The color-ramp data is available to you. Is this going to go on forever, where you point out little obvious stepping stones that are perfectly solvable?