What Open Shading Language Does in Blender and Why You'd Use It

Open Shading Language is a text-based way to write custom shaders in Blender

Open Shading Language (OSL) is a programming language built into Blender that lets you write shaders — the code that controls how surfaces look — by typing text instead of connecting visual nodes. If you've used Blender's Shader Editor, you've seen the node-based approach: little boxes connected by lines that define color, roughness, reflection, and other surface properties. OSL lets you do the same thing by writing code directly.

OSL only works with Blender's Cycles render engine, not Eevee. It's useful when you need precise control over complex material behavior, when you want to reuse shader code across projects, or when a visual node setup would become so tangled that text is actually clearer. Most everyday Blender work doesn't need it — the node editor handles the vast majority of material tasks. But if you're building procedural textures, writing shaders that respond to custom data, or porting shader code from other software, OSL is the tool for that.

Key Takeaways

OSL is a text-based shader language that works only in Blender's Cycles render engine, not in Eevee or viewport shading.
You write OSL code in Blender's Shader Editor using an OSL Script node, which you can connect to other shader nodes just like any other node.
OSL is useful for procedural textures, complex material logic, and reusable shader code, but most materials can be built faster with the node editor.
OSL code runs during rendering, not in real time, so you won't see results until you render or switch to rendered viewport mode.
Learning OSL requires some programming knowledge, but the syntax is designed to be readable and the Blender documentation includes shader examples.

How OSL fits into Blender's shader system

Blender's Shader Editor normally works with nodes — visual blocks that each do one thing. A Principled BSDF node handles most material properties. A ColorRamp node maps values to colors. A Noise Texture node generates patterns. You connect them together, and the render engine reads that graph to decide how light bounces off the surface.

OSL lets you replace or supplement that node graph with code. You add an OSL Script node to your shader setup, write code inside it, and plug its outputs into other nodes or directly into the Material Output. The code runs when Blender renders, and it produces the same kind of output a node would — a color, a number, a vector, whatever you need. The rest of your shader graph works exactly as before.

This matters because some shader tasks are easier to express in code than in nodes. If you need to blend between three textures based on a custom formula, or generate a pattern that depends on object position and time, or write logic that would require twenty nodes connected in a maze, OSL can be cleaner and faster to write.

When you would actually use OSL instead of nodes

The node editor is fast and visual, so most Blender artists never touch OSL. But a few situations make OSL the better choice. If you're building a procedural texture that responds to multiple inputs in a complex way — say, a weathering shader that changes based on surface angle, height, and a custom paint layer — OSL lets you write that logic in one readable block instead of connecting fifty nodes. If you have shader code from another software (like a game engine or a research paper) and you want to port it to Blender, OSL's syntax is close enough to C that translation is straightforward. If you're building a shader library that you'll reuse across many projects, OSL code is easier to version control and share than a .blend file full of nodes.

OSL is also the only way to write certain kinds of shaders. If you need to read from a texture at a custom coordinate that depends on render-time data, or if you need to do math that Blender's built-in nodes don't expose, OSL gives you that access. Some studios use OSL for look development because it's faster to tweak a few lines of code than to rebuild a node graph.

But if you're learning Blender or building a one-off material, the node editor is almost always the right choice. It's faster to learn, faster to iterate, and you can see your changes in real time in the viewport. OSL has a longer feedback loop — you write code, render, see the result, go back and edit.

How to write and use an OSL shader in Blender

To use OSL, you first make sure Cycles is your active render engine. Go to the Render Properties panel and select Cycles. Then open the Shader Editor, select the object you want to shade, and add an OSL Script node. You can do this by pressing Shift+A in the Shader Editor, navigating to Script, and choosing OSL Script.

The node opens with a blank text editor. You write your shader code there. A minimal OSL shader looks like this:

shader my_shader(output color result = 0.5) { result = color(1.0, 0.0, 0.0); }

This shader outputs pure red. You can connect the result output to a Principled BSDF's Base Color input, and when you render, that surface will be red. From there, you can add inputs to your shader (like a texture coordinate or a value slider), read from Blender's built-in data (like the surface normal or the object's location), and write logic to compute colors, vectors, or numbers.

OSL code runs only during rendering. If you're in solid or material preview mode in the viewport, you won't see your OSL shader — you'll see the fallback preview. Switch to rendered viewport shading (press Z and choose Rendered) to see OSL results in real time, though performance will be slower than with pure nodes.

OSL syntax and what you need to know to write it

OSL syntax is based on C and GLSL, so if you've written code in either of those languages, OSL will feel familiar. You declare variables with types (float, color, vector, int), write functions, use loops and conditionals, and call built-in functions that Blender provides.

A few things are specific to OSL shaders. Every shader must have a shader block that defines its inputs and outputs. Inputs are parameters you can connect or set from outside the shader. Outputs are values the shader produces. You use the output keyword to mark which variables are outputs. You can also use metadata to add UI controls — for example, you can mark a float as a slider with a min and max value, so it appears as a slider in the node's properties instead of a text field.

Blender provides built-in functions for common shader tasks: texture sampling, noise generation, math operations, and access to render-time data like the surface normal, the viewing direction, and the object's location. The Blender manual lists all of these, and the OSL specification (maintained by Sony Imageworks) documents the full language.

Performance and rendering considerations

OSL shaders are compiled to machine code when you render, so they run at reasonable speed. But they're generally slower than equivalent node setups because the render engine can optimize nodes in ways it can't optimize arbitrary code. If you're rendering a scene with heavy OSL shaders on many objects, render time will be longer than with nodes.

OSL also doesn't work with GPU rendering in Cycles — it only works with CPU rendering. If you're using an NVIDIA GPU with CUDA or an AMD GPU with HIP, you can't use OSL. You have to switch to CPU rendering, which is slower but necessary for OSL to work.

For viewport performance, OSL shaders don't show in the viewport at all unless you're in rendered mode. In material preview mode, you see a fallback representation. This means your feedback loop is slower — you can't tweak a shader and see the result instantly like you can with nodes.

Learning resources and where to go next

The official Blender manual has a section on OSL under the Shader Editor documentation. It includes syntax reference, a list of built-in functions, and several example shaders. The OSL specification itself is available on the Imageworks website and is the authoritative source for language features.

If you're new to programming, learning OSL is harder than learning the node editor. You'll need to understand variables, functions, loops, and basic math. If you already know Python or C, the jump to OSL is small. Many Blender communities (like Blender Artists forums and the Blender subreddit) have people who write OSL, and they often share code examples and answer questions.

The best way to start is to look at existing OSL shaders, understand what they do, and modify them. Blender ships with a few example OSL shaders in its startup file. You can also find community-written shaders on sites like Gumroad or GitHub. Start by changing numbers and seeing how the output changes, then gradually write your own logic.

Frequently Asked Questions

Can I use OSL with Eevee or viewport shading?

No. OSL only works with Cycles. If you're using Eevee, you're limited to the node editor and Eevee's built-in shader nodes. Eevee has its own shader language (GLSL), but you don't write it directly in Blender — you use nodes.

Do I need to know programming to use OSL?

Yes, you need to understand basic programming concepts: variables, functions, loops, and conditionals. If you've never programmed before, the node editor is a better starting point. If you know Python or C, OSL will be quick to pick up.

Can I export an OSL shader to use in another software?

OSL is a standard language, so you can write OSL code that works in other renderers that support it (like RenderMan or some game engines). But Blender-specific functions won't work elsewhere. You'd need to rewrite those parts using the target software's equivalents.

Why is my OSL shader not showing in the viewport?

OSL only renders in Cycles with CPU rendering. Switch to rendered viewport shading (Z key, then Rendered) and make sure Cycles is your render engine. If you're using GPU rendering, switch to CPU — OSL doesn't work with GPU acceleration.

Can I mix OSL shaders with regular nodes?

Yes. You can plug an OSL Script node's outputs into a Principled BSDF or any other node, and you can feed node outputs into an OSL shader's inputs. They work together in the same shader graph.

This guide is for general information only and is not medical, financial, legal, or other professional advice. For decisions specific to your situation, consult a qualified professional. See our Editorial Policy.