open shading language for blender что это

Введение в OSL для Blender

Недавно вышла новая книга, посвященная blender: Open Shading Language for Blender. OSL — это язык высокого уровня программирования шейдеров. Автором данной книги является Michel Anders. Он ведет блог, посвященный данной теме, и на специальной странице Вы можете скачать «превью» данной книги, а в случае заинтересованности, купить полную версию. Сам автор говорит, что книга предназначена для тех, кто хочет расширить свои навыки создания материалов.

Так как книга о высокоуровневом языке программирования, то для ее освоения необходимо иметь, как минимум, твердое представление о том, что такое язык программирования. Также Вы должны быть уверенным пользователем блендер, в частности, без проблем создавать материалы, при помощи нодов в окне Node Editor. Ну и самый досадный момент — книга на английском 🙁 Так что, покорятся вершины OSL для Blender далеко не многим…

Но, из-за того, что «превью» книги распространяется абсолютно бесплатно, я решил перевести его на великий и могучий… К тому же, этих основ более чем достаточно, чтобы понять, что это за «зверь» такой, и как с ним бороться (надеюсь, меня не съедят комментаторы за авторские права).

В этом посте перевод лишь первой главы, описывающей процесс создания самого простого шейдера, а в случае заинтересованности читателями, будет перевод всех остальных примеров, доступных в «превью» версии.

Подготовка Blender

В связи с тем, что при работе с OSL может происходить множество ошибок, которые отображаются в консоли, то будет разумно открыть ее. Для того, чтобы сделать это в Linux или OSX, достаточно просто запустить blender через консоль (набрать в ней слово blender). Пользователям Windows нужно запустить блендер и включить консоль в верхнем меню Window > Toggle System Console.

Откройте блендер со сценой по умолчанию. Измените тип рендера на Cycles Render. Далее нужно убедиться, что в качестве вычислительного устройства у Вас выбран CPU (OSL сейчас не поддерживает GPU) и отметить пункт Open Shading Language.

Разделите окно 3D-вида напополам по горизонтали, и в любом из них переключитесь на Node Editor. На этом с подготовкой закончено, можно приступать к созданию первого шейдера OSL!

Создание первого шейдера OSL

Создайте для Вашего куба материал и затем добавьте нод Script (Shift + A > Script > Script). Данный нод имеет всего две кнопки:

Оба метода хороши, но мы будем использовать External. Теперь нам необходимо создать файл, который мы назовем firstshader.osl, и загрузить его в нод Script. Файл должен содержать следующий код:

shader darken( color In = 1, output color Out = 1 )

Соедините ноды, как показано на рисунке ниже, и в окне 3D-вида включите режим отображения Rendered.

В первой строке объявляется шейдер, который называется darken. Шейдер выглядит как функция с параметрами, и во второй строке определяется входной параметр In. Тип этого параметра — цвет (color один из основных типов в OSL), и его значение по умолчанию равно 1. Это означает, что все три компонента цвета (красный, зеленый и синий) будут установлены в значение 1, что делает цвет белым.

Следующая строчка определяет параметр Out, который также имеет тип Color, и его значение по умолчанию равно 1. Создали мы этот выходной параметр при помощи ключевого слова output. Когда шейдер компилируется, blender создает соответствующие сокеты с обеих сторон нода (входные слева, выходные справа). Также он окрашивает сокеты в соответствующие цвета. В случае с параметром color, сокеты будут желтыми.

Все параметры должны быть определены по умолчанию. Если к входному параметру нода не будет подключен другой нод, то будет использоваться значение, определенное по умолчанию. Также, если ничего не подключено к входу, то данное значение может быть изменено пользователем. В зависимости от типа сокета, соответствующий редактор появится при клике по параметру (например, popup выбора цвета, если это цвет). Значение не подключенного сокета может быть даже анимировано (при помощи горячей клавиши I), как и практически все в Blender.

Значение по умолчанию для выходного сокета используется в том случае, если нигде в теле шейдера оно не было изменено.

Тело этого шейдера состоит из одной строки (строка 5), в которой входной параметр (In) умножается на 0.5, и результат присваивается параметру Out.

Данный шейдер слишком прост и не показывает многих возможностей, но он дает четкое представление того, как много работы берет на себя сам blender: создает нужные сокеты в нужных местах, окрашивает их в соответствующий цвет и помогает легко изменять параметры шейдера.

Если данный урок был интересен, и Вы желаете углубиться в изучение OSL для Blender — оставляйте отзывы в комментариях.

Источник

Open Shading Language in Cycles

The Cycles render engine has two shader systems.

SVM (Shader Virtual Machine) is the default shader system but the engine also has support for OSL (Open Shading Language).

The OSL shader system was working on a basic level back in April 2011 when Cycles got released, but afterwards it was not updated as Cycles itself was very young and needed to mature still. There would have been no benefit in supporting both backends from the very beginning.

Lukas Tönne and myself updated the OSL backend in Cycles for the last couple of weeks and brought it up to speed again. We had to fix a bunch of compiler errors first, as the OSL API itself changed as well over the past year.

1) What is OSL?

OSL is an open source shader system, developed by Sony Pictures Imageworks (SPI). They developed it for their in-house renderer (which is a modified version of Arnold) and it was the exclusive shading system for big VFX films such as “Men in Black 3” and “The Amazing Spider-Man”.

OSL is available under the “New BSD” licence and can be integrated into commercial and free software applications.The source code is available on github.

Make sure to read the “Physical Production Shaders with OSL” presentation from the Siggraph 2012 Shading Course to get a detailed overview of OSL.

2) OSL in Cycles

You will be able to use either the SVM or the OSL backend. The reason for that: OSL is only available when you render with the CPU, a limitation of OSL itself which might change in the future, but for now it”s CPU only and therefore we keep both backends.

Every shader node in Blender is implemented in both backends, so you can switch back and forth here without worrying about your material setup.

3) Custom shaders

The real strength of OSL is the ability to write your own shaders. You can create materials, lights, displacement or patterns in the OSL language itself.

These shaders can also be exchanged with other OSL Render engines. Each renderer can add custom features and closure types, but the basic shaders and functions should be available in every OSL renderer. Chaosgroup confirmed that V-Ray is going to support OSL in their next major release as well.

4) Where do I get Blender with OSL?

OSL is not included in official builds yet, if you want to give it a try you have to compile the OSL library yourself and enable “WITH_CYCLES_OSL” in cmake. The updated OSL code is in trunk, except the OSL script node. A patch for that will be released soon.

It probably won”t make it into the upcoming Blender 2.64 release, as we still have to fix a few bugs and polish it, but 2.65 will most likely include it.

If you want to test it or even better help developing it, you can find compile instructions and ToDos here.

Источник

Open shading language for blender что это

Open Shading Language

Welcome to Open Shading Language!

Open Shading Language (OSL) is a small but rich language for programmable shading in advanced renderers and other applications, ideal for describing materials, lights, displacement, and pattern generation.

OSL was originally developed by Sony Pictures Imageworks for use in its in- house renderer used for feature film animation and visual effects, released as open source so it could be used by other visual effects and animation studios and rendering software vendors. Now it’s the de facto standard shading language for VFX and animated features, used across the industry in many commercial and studio- proprietary renderers. Because of this, the work on OSL received an Academy Award for Technical Achievement in 2017.

OSL is robust and production-proven, and has been used in films as diverse as «The Amazing Spider-Man,» «Hotel Transylvania,» «Edge of Tomorrow», «Ant Man», «Finding Dory,» and many more. OSL support is in most leading renderers used for high-end VFX and animation work. For a full list of films and products, see the filmography.

The OSL code is distributed under the «New/3-clause BSD» license, and the documentation under the Creative Commons Attribution 4.0 International License. In short, you are free to use OSL in your own applications, whether they are free or commercial, open or proprietary, as well as to modify the OSL code and documentation as you desire, provided that you retain the original copyright notices as described in the license.

How OSL is different

OSL has syntax similar to C, as well as other shading languages. However, it is specifically designed for advanced rendering algorithms and has features such as radiance closures, BSDFs, and deferred ray tracing as first-class concepts.

OSL has several unique characteristics not found in other shading languages (certainly not all together). Here are some things you will find are different in OSL compared to other languages:

Surface and volume shaders compute radiance closures, not final colors.

OSL’s surface and volume shaders compute an explicit symbolic description, called a «closure», of the way a surface or volume scatters light, in units of radiance. These radiance closures may be evaluated in particular directions, sampled to find important directions, or saved for later evaluation and re-evaluation. This new approach is ideal for a physically-based renderer that supports ray tracing and global illumination.

In contrast, other shading languages usually compute just a surface color as visible from a particular direction. These old shaders are «black boxes» that a renderer can do little with but execute to find this one piece of information (for example, there is no effective way to discover from them which directions are important to sample). Furthermore, the physical units of lights and surfaces are often underspecified, making it very difficult to ensure that shaders are behaving in a physically correct manner.

Surface and volume shaders do not loop over lights or shoot rays.

There are no «light loops» or explicitly traced illumination rays in OSL surface shaders. Instead, surface shaders compute a radiance closure describing how the surface scatters light, and a part of the renderer called an «integrator» evaluates the closures for a particular set of light sources and determines in which directions rays should be traced. Effects that would ordinarily require explicit ray tracing, such as reflection and refraction, are simply part of the radiance closure and look like any other BSDF.

Advantages of this approach include that integration and sampling may be batched or re-ordered to increase ray coherence; a «ray budget» can be allocated to optimally sample the BSDF; the closures may be used by for bidirectional ray tracing or Metropolis light transport; and the closures may be rapidly re-evaluated with new lighting without having to re-run the shaders.

Surface and light shaders are the same thing.

OSL does not have a separate kind of shader for light sources. Lights are simply surfaces that are emissive, and all lights are area lights.

Transparency is just another kind of illumination.

You don’t need to explicitly set transparency/opacity variables in the shader. Transparency is just another way for light to interact with a surface, and is included in the main radiance closure computed by a surface shader.

Renderer outputs (AOV’s) may be specified using «light path expressions.»

Sometimes it is desirable to output images containing individual lighting components such as specular, diffuse, reflection, individual lights, etc. In other languages, this is usually accomplished by adding a plethora of «output variables» to the shaders that collect these individual quantities.

OSL shaders need not be cluttered with any code or output variables to accomplish this. Instead, there is a regular-expression-based notation for describing which light paths should contribute to which outputs. This is all done on the renderer side (though supported by the OSL implementation). If you desire a new output, there is no need to modify the shaders at all; you only need to tell the renderer the new light path expression.

Shaders are organized into networks.

OSL shaders are not monolithic, but rather can be organized into networks of shaders (sometimes called a shader group, graph, or DAG), with named outputs of some nodes being connected to named inputs of other nodes within the network. These connections may be done dynamically at render time, and do not affect compilation of individual shader nodes. Furthermore, the individual nodes are evaluated lazily, only when their outputs are «pulled» from the later nodes that depend on them (shader writers may remain blissfully unaware of these details, and write shaders as if everything is evaluated normally).

Arbitrary derivatives without grids or extra shading points.

In OSL, you can take derivatives of any computed quantity in a shader, and use arbitrary quantities as texture coordinates and expect correct filtering. This does not require that shaded points be arranged in a rectangular grid, or have any particular connectivity, or that any «extra points» be shaded. This is because derivatives are not computed by finite differences with neighboring points, but rather by «automatic differentiation», computing partial differentials for the variables that lead to derivatives, without any intervention required by the shader writer.

OSL optimizes aggressively at render time

OSL uses the LLVM compiler framework to translate shader networks into machine code on the fly (just in time, or «JIT»), and in the process heavily optimizes shaders and networks with full knowledge of the shader parameters and other runtime values that could not have been known when the shaders were compiled from source code. As a result, we are seeing our OSL shading networks execute 25% faster than the equivalent shaders hand-crafted in C! (That’s how our old shaders worked in our renderer.)

What OSL consists of

The OSL open source distribution consists of the following components:

liboslc, a library that implements the OSLCompiler class, which contains the guts of the shader compiler, in case anybody needs to embed it into other applications and does not desire for the compiler to be a separate executable.

liboslquery, a library that implements the OSLQuery class, which allows applications to query information about compiled shaders, including a full list of its parameters, their types, and any metadata associated with them.

oslinfo, a command-line program that uses liboslquery to print to the console all the relevant information about a shader and its parameters.

liboslexec, a library that implements the ShadingSystem class, which allows compiled shaders to be executed within an application. Currently, it uses LLVM to JIT compile the shader bytecode to x86 instructions.

testshade, a program that lets you execute a shader (or connected shader network) on a rectangular array of points, and save any of its outputs as images. This allows for verification of shaders (and the shading system) without needing to be integrated into a fully functional renderer, and is the basis for most of our testsuite verification. Along with testrender, testshade is a good example of how to call the OSL libraries.

testrender, a tiny ray-tracing renderer that uses OSL for shading. Features are very minimal (only spheres are permitted at this time) and there has been no attention to performance, but it demonstrates how the OSL libraries may be integrated into a working renderer, what interfaces the renderer needs to supply, and how the BSDFs/radiance closures should be evaluated and integrated (including with multiple importance sampling).

A few sample shaders.

Where OSL has been used

This list only contains films or products whose OSL use is stated or can be inferred from public sources, or that we’ve been told is ok to list here. If an OSL-using project is missing and it’s not a secret, just email the OSL project leader or submit a PR with edits to this file.

Renderers and other tools with OSL support (in approximate order of adding OSL support):

Films using OSL (grouped by year of release date):

Building and Installation

Please read the INSTALL.md file for detailed instructions on how to build and install OSL.

The OSL language specification can be found at src/doc/osl-languagespec.pdf (in a source distribution) or in the share/doc/OSL/osl-languagespec.pdf file of an installed binary distribution.

Contact & reporting problems

Simple «how do I. «, «I’m having trouble», or «is this a bug» questions are best asked on the osl-dev developer mail list. That’s where the most people will see it and potentially be able to answer your question quickly (more so than a GH «issue»).

Bugs, build problems, and discovered vulnerabilities that you are relatively certain is a legit problem in the code, and for which you can give clear instructions for how to reproduce, should be reported as issues.

If confidentiality precludes a public question or issue, you may contact the project administrator privately at lg@imageworks.com, including for security-related issues.

OSL welcomes code contributions, and nearly 50 people have done so over the years. We take code contributions via the usual GitHub pull request (PR) mechanism. Please see CONTRIBUTING for detailed instructions.

Contacts, Links, and References

The current project leadership is documented in the Governance file.

Many people have contributed features, bug fixes, and other changes to OSL over the years: Steve Agland, Shane Ambler, Martijn Berger, Farchad Bidgolirad, Nicholas Bishop, Solomon Boulos, Stefan Bruens, Stefan Büttner, Matthaus G. Chajdas, Clark Chen, Alejandro Conty, Thomas Dinges, Mads Drøschler, Luke Emrose, Louis Feng, Mark Final, Henri Fousse, Syoyo Fujita, Tim Grant, Larry Gritz, Derek Haase, Sven-Hendrik Haase, John Haddon, Daniel Heckenberg, Thiago Ize, Niklas Harrysson, Matt Johnson, Ronan Keryell, Chris Kulla, Elvic Liang, Max Liani, Adam Martinez, John Mertic, Bastien Montagne, Steena Monteiro, Alexis Oblet, Erich Ocean, Mikko Ohtamaa, Jino Park, Alexei Pawlow, Jay Reynolds, Declan Russell, Patrick Scheibe, Alex Schworer, Jonathan Scruggs, Sergey Sharybin, Sandip Shukla, Cliff Stein, Stephan Steinbach, Esteban Tovagliari, Brecht Van Lommel, Alexander von Knorring, Alex Wells, Roman Zulak.(Listed alphabetically; if we’ve left anybody out, it is inadvertent, please let us know.)

We cannot possibly express sufficient gratitude to the managers at Sony Pictures Imageworks who allowed this project to proceed, supported it wholeheartedly, and permitted us to release the source, especially Rob Bredow, Brian Keeney, Barbara Ford, Rene Limberger, Erik Strauss, and Mike Ford.

Huge thanks also go to the crack shading team at SPI, and the brave lookdev TDs and CG supes willing to use OSL on their shows. They served as our guinea pigs, inspiration, testers, and a fantastic source of feedback. And of course, the many engineers, TDs, and artists elsewhere who incorporated OSL into their products and pipelines, especially the early risk-takers at Chaos Group, Double Negative, Pixar, DNA, Isotropix, and Animal Logic. Thank you, and we hope we’ve been responsive to your needs.

OSL was not developed in isolation. We owe a debt to the individuals and studios who patiently read early drafts of the language specification and gave us very helpful feedback and additional ideas, as well as to the continuing contributions and feedback of its current developers and users at other VFX and animation studios.

The OSL implementation depends upon several other open source packages, all with compatible licenses:

Источник

Open Shading LanguageпѓЃ

It is also possible to create your own nodes using Open Shading Language (OSL). Note that these nodes will only work for CPU rendering; there is no support for running OSL code on the GPU.

To enable it, select Open Shading Language as the shading system in the render settings.

Script NodeпѓЃ

OSL was designed for node-based shading, and each OSL shader corresponds to one node in a node setup. To add an OSL shader, add a script node and link it to a text data-block or an external file. Input and output sockets will be created from the shader parameters on clicking the update button in the Node or the Text editor.

OSL shaders can be linked to the node in a few different ways. With the Internal mode, a text data-block is used to store the OSL shader, and the OSO bytecode is stored in the node itself. This is useful for distributing a blend-file with everything packed into it.

The shader search path is located in the same place as the scripts or configuration path, under:

Linux Windows macOS

For use in production, we suggest to use a node group to wrap shader script nodes, and link that into other blend-files. This makes it easier to make changes to the node afterwards as sockets are added or removed, without having to update the script nodes in all files.

Writing ShadersпѓЃ

For more details on how to write shaders, see the OSL specification. Here is a simple example:

ClosuresпѓЃ

OSL is different from, for example, RSL or GLSL, in that it does not have a light loop. There is no access to lights in the scene, and the material must be built from closures that are implemented in the renderer itself. This is more limited, but also makes it possible for the renderer to do optimizations and ensure all shaders can be importance sampled.

Источник

Open Shading Language¶

При помощи Open Shading Language (OSL) возможно создавать свои собственные типы узлов. Обратите внимание, что эти узлы будут работать только при визуализации на центральном процессоре; поддержки выполнения кода OSL на GPU нет.

Для включения этой возможности отметьте галочку Open Shading Language в панели Визуализация.

На Linux для компиляции скриптов OSL должны быть установлены инструменты компилятора C/C++ (в частности, /usr/bin/cpp).

Узел «Скрипт»¶

Шейдеры OSL могут быть связаны с узлом несколькими различными способами. При использовании режима Встроенный для хранения шейдера OSL будет использоваться текстовый блок данных, а байт-код OSO будет сохранён в самом узле. Это полезно для распространения blend-файла без зависимостей.

Шейдеры ищутся в том же самом месте, где расположены все остальные скрипты или другая конфигурация:

Linux MS-Windows macOS

Для использования в реальной работе, мы предлагаем использовать узел группы, обёртывающий узлы скрипта и ссылаться на него из других blend-файлов. Это упростит внесение изменений в узел после добавления или удаления сокетов, без необходимости в обновлении узлов скриптов во всех файлах.

Написание шейдеров¶

Более подробную информацию о том, как писать шейдеры, смотрите в спецификации OSL (на английском языке). Здесь приводится лишь простой пример:

Замыкания¶

Волосы¶

BSSRDF¶

Объём¶

Другие¶

Атрибуты¶

Some object, particle and mesh attributes are available to the built-in getattribute() function. UV maps and vertex colors can be retrieved using their name. Other attributes are listed below:

geom:generated Сгенерированные текстурные координаты. geom:uv UV-развёртка по умолчанию. geom:dupli_generated Для экземпляров – сгенерированные координаты из дублирующего объекта. geom:dupli_uv Для экземпляров – UV-координаты из дублирующего объекта. geom:trianglevertices Координаты трёх вершин треугольника. geom:numpolyvertices Количество вершим в многоугольнике (на текущий момент всегда возвращает три вершины). geom:polyvertices Массив с координатами вершин многоугольника (на текущий момент в массиве всегда три вершины). geom:name Имя объекта. geom:is_curve Является ли объект прядью или нет. geom:curve_intercept Точка вдоль пряди от корня до кончика. geom:curve_thickness Толщина пряди. geom:curve_tangent_normal Касательная нормали пряди. path:ray_length Расстояние, пройденное лучом с момента последнего попадания в препятствие. object:location Местоположение объекта. object:index Номер индекса объекта. object:random Случайный номер для каждого объекта, генерируемый из его индекса и имени. material:index Номер индекса материала. particle:index Номер экземпляра частицы. particle:age Возраст частицы в кадрах. particle:lifetime Общее время жизни частицы в кадрах. particle:location Местоположение частицы. particle:size Размер частицы. particle:velocity Скорость частицы. particle:angular_velocity Угловая скорость частицы.

Трассировка¶

Эта функция не может использоваться вместо освещения; основная её цель – позволить шейдерам «щупать» ближайшую геометрию, например, чтобы применить проецируемую текстуру, которая может быть заблокирована геометрией, сделать открытую геометрию более «изношенной» или применить ещё какие-нибудь эффекты, подобные ambient occlusion.

Источник