Monday, October 29, 2012

meShaderEd.py (0.2.7)


https://github.com/ymesh/meShaderEd
download v0.2.7

Format of root RSL nodes was changed, hence previous shader networks needs to replace those nodes.

ProjectSetup: Using relative pathes for resource directories.
ImageView: Auto update checkbox.
ImageView: Reset zoom button.
NodeEditorWindow: replaced by NodeEditorPanel (though it is not fully functional yet...)

Added support for LightSource rib node in BasicPrimitive2.
Here is screenshot with example of usage of these nodes:


14 comments:

  1. После обновления при старте под Windows выдаёт ошибку:

    WindowsError: [Error 123] Синтаксическа  ошибка в имени файла,: 'C:/0-Programs/1
    -CG/meShaderEd/include;C:'

    До обновления у меня в настройках, в графе "include" было:
    C:/0-Programs/1
    -CG/meShaderEd/include;C:/0-Programs/1-CG/meShaderEd/include/DRL
    Ну то есть помимо стандартной директории include я добавил свою подпапку.

    ReplyDelete
    Replies
    1. Видимо, увлекся косметическими улучшениями кода и забыл о функциональности...
      Спасибо, что оперативно заметили этот косяк. ;)
      Для исправления "по-быстрому":
      1. meShaderEd.py line 105 -- в параметрах CreateMissingDirs ( ... ) удалить include_dir
      2. gui/SettingsSetup.py line 140 -- в параметрах CreateMissingDirs ( ... ) удалить inc_dir

      Delete
    2. Извиняюсь за поздний ответ.
      Спасибо, всё завелось. :)

      Ещё есть вопрос: где именно meShaderEd хранит все свои настройки?

      И ещё фича-ревест:
      можно как-нибудь так сделать, чтоб можно было задавать, под каким именем вынесенные пользователю параметры попадут в итоговый шейдер?
      Т.е.:
      Допустим, есть у мня нода gamma1, которая крутит френель на отражении. Она принимает 2 параметра - цвет и собственно гамма. Естественно, gamma я выношу в параметры шейдера... и он туда попадает под именем gamma1_gamma.
      Вообще не понятно, что он должен делать. По-хорошему, он должен называться fresnel_gamma, но я этого названия никак получить не могу, т.к. нода fresnel у меня уже есть. А даже если я переименую всё у себя в нетворке, то потом может понадобиться вынести какой-нибудь параметр gamma_чтонибудь - и этого я уж точно сделать не смогу.
      Результат: в итоговом шейдере у всех параметров длинный ненужный префикс. Либо приходится пробегаться автозаменой по файлу шейдера и вручную его потом компилить.

      Хотелось бы в будущих версиях увидеть редактор параметров шейдера, который позволял бы как минимум задавать вручную имя параметров и их порядок. А как максимум - группировать их, задавать им типы (тот же string может быть путём файла или пространством) и сохранять это всё в виде slim-файла и 3delight'овских комментов-описаний.
      Наиболее простым и функциональным я вижу такой редактор по аналогии с Нюковским.

      Delete
    3. Вдогонку:
      Открыл я новую ноду surface... что-то не видно вообще никаких изменений. Посимвольно я их не сравнивал, но на первый взгляд xml-ка один в один, что была раньше.

      Delete
    4. Если в коде surface.xml есть:

      #define SURFACE_SHADER ${INSTANCENAME}
      surface ${INSTANCENAME} (
      ${PARAMS}
      )
      {
      /* CODE BEGIN ${INSTANCENAME} */
      Ci = $(Ci) * $(Oi);
      Oi = $(Oi);
      /* CODE END ${INSTANCENAME} */
      }

      то это -- последняя версия. Раньше такого не было.
      Если нет -- то возможно meShaderEd берет ноды из какого-то другого места.
      Расположение библиотеки прописаны в Settings.
      А они, в свою очередь, сохраняются в системных преференсах.
      Для винды -- это обычно \Users\\AppData\Roaming\mesh\meShaderEd.ini
      (этот файд можно безболезненно убивать -- он создастся заново)

      Delete
    5. По поводу имен параметров... Пока в шейдер попадают имена параметров, а не лейблы, т.к. они гарантировано без пробелов и спец.символов и не повторяются. В liquidmaya -- это не проблема, т.к. лейблы можно описать в .lif файле и они будут отображаться в майском AttributeEditor-e. В Slim-e, ShaderLink-e имена параметров формируются точно так-же (имя_ноды_имя_параметра).
      NodeEditor уже есть (dblclk on node), но пока read-only.
      По идее там можно будет реорганизовывать порядок параметров (драгом в списке) и менять все их свойства (в том числе и варианты отображения в GUI). Возможно, что уже в следующей версии.

      Delete
  2. Обнаружил ещё один баг:
    Файлы meShaderEd.py и gui/SettingsSetup.py я ручками исправил.
    Но даже после этого фикса кастомная директория всё равно не подцепляется. Т.е., мой щейдер, требующий мою процедуру, не компилится, потому что не находит её. В результате - в meShaderEd превью-чайник рисуется дефолтным синим.
    Причём, даже если переложить файл с процедурой в корневую директорию include - всё равно она не находится. Удаётся скомпилить, только если скопировать все нужные *.h-файлы прямо в папку samples/shaders/src (тугда, куда sl-ки генерятся).

    ReplyDelete
    Replies
    1. Похоже, что сепаратор ';' для инклудов не работает...
      Хорошо. Тогда можно использовать ',' (запятые без пробела)
      для описания списка инклудов в Edit->Settings...
      Должно работать.

      Delete
    2. Спасибо. Поставил запятую - завелось, отрендерилось. :)

      Насчёт редактора атрибутов... Node Editor - это не совсем то. Например, он позволяет работать с атрибутами одной ноды, но не даёт группировать/упорядочивать вообще все выходные параметры шейдера.
      liquidmaya я не пользовался, сейчас сижу на Делайте. Но, как бы то ни было, я имел в виду, посел компиляции не писать лейблы самому руками, а чтоб meShaderEd автоматом создавал все необходимые интерфейсные файлы (файлы, или в случае с Делайтом - комменты - для "красивого" отображения шейдера в атрибут эдиторе).

      Delete
  3. Ещё есть предложение.
    Но оно скорее концептуальное по направленности проекта, а не техническое:

    Вместо мега-нод, которые могут всё, стараться в каждой ноде закладывать минимально необходимый функционал.
    Редактор же нодовый. Т.е., вместо того, чтоб прям в самой ноде прогонять тучу if-ов, пытаясь предусмотреть всё, лучше просто сделать отдельные куски, которые безусловно либо есть, либо их нет.
    Например, есть замечательная нода FacingForward на основе, как я понял, пиксаровского кода. Она крута, и в ней предусмотрена куча всевозможных случаев. Однако я, например, всегда сперва инвертирую FacingRatio (чтоб получить аналог френеля на отражениях), а уже потом кручу гамму - так красивее получается. В общем...
    1. всего в одной ноде всё равно не учтёшь.
    2. все эти "учтённости" негативно сказываются на производительности.

    Поэтому на этом примере я вместо одной FacingForward сразу сделал несколько своих мелких нод:
    просто FacingRatio (дотпродукт векторов),
    гамма,
    грейд.

    Я предлагаю именно такое направление развития для проекта. В одной ноде оставлять только то, что принципиально невозможно разбить на несколько.

    P.S.:
    1. Лучше на "ты" или на "вы"?
    2. как/куда я могу прямо по ходу создания выкладывать свои ноды?

    ReplyDelete
    Replies
    1. Согласен. Изначально, этот редактор задумывался в (само)образовательных целях,
      поэтому множество мелких нод нужны для понимания RSL функций.
      Более сложные конструкции, сгруппированы и вынесены в отдельные папки.
      В идеале, я планирую добавить поддержку NodeGroup, чтобы можно было группировать и редактировать ноды, как в Nuke или Coral-e.

      Касательно FacingRatio. В operation->functions, на мой взгляд логичное место для стандартных функций (там уже есть faceforward, например)

      По поводу выкладывания. По началу, было бы проще архивом в письме.
      Затем я заведу на GitHub-e в Wiki страничку User Depot и там уже, каждый желающий сможет
      описывать свои наработки.
      Кроме того, я могу добавить заинтересованных пользователей GitHub-а в Collaborators и они могут сами добавлять ноды в проект, а также возможные улучшения и исправления багов.

      На "ты" проще и привычнее ;)

      Delete
  4. Это просто счастье какое то! С каждой версией столько полезностей. Сейчас создаю карбон шейдер, с помощью вашего редактора. По завершению с удовольствием им поделюсь что бы, библиотека примеров росла и ширилась. Примеры из ранних версий мне помогли быстрее понять как все устроено. И если пожелания принимаются, можно бы сделать ноду DOT (NUKE), или что бы можно было бы назначать цвет связок между нодами для лучшего ориентирования откуда какой параметр идет. Или может что бы определять цвет нод, тогда бы я мог разделить ноды по цветам в группы. Или цветовая плоскость позади группы нод с подписью как в NUKE.Спасибо

    ReplyDelete
    Replies
    1. Замечательно.
      Я рад, что кроме меня, еще кто-то пользуется редактором ;)
      Пожелания, конечно-же -- всячески приветствуются.
      Нода DOT мне самому нравится в нодовых редакторах.
      Очень помогает придать наглядности сложным графам.
      Однако, у редактора есть некий roadmap с перечнем полезностей,
      которые хотелось бы продумать и добавить...
      Сейчас, на мой взгляд, больше не хватает возможностей быстрого дублирования и Copy-Paste.

      Delete
    2. Не прошло и пол-года, как добавилась нода а ля "DOT in Nuke" -- ConnectorNode.
      В версии 0.2.9 можно с помощью Ctrl-drag (Mac: Cmd-drag) "оттягивать" параметры ноды для превращения их в ConnectorNode.

      Delete