Render.ru

Серьезное пожелание для разработчиков Realsoft 3D

FSV141

Активный участник
#1
Возможно я не очень хорошо разобрался с редактором VSL, поэтому прошу не судить меня строго, если что-то напишу не по делу.

Итак, работая с VSL-редактором я почувствовал острую необходимость контролировать промежуточные результаты на различных стадиях работы шейдера. Проще всего это объявнить аналогией с нодовым композером. Например, в Digital Fusion у каждого нода есть 2 маленьких точки, при нажатии на которые вывод из данного конкретного нода отображается на одном из двух экранов.
В Гудини, например, так же можно вывести результат работы каждого нода во вьюпорт.

Примерно то же самое можно было бы организовать и для реалсофтовского редактора VSL. Что скажите? Может про это стоит написать разработчикам?
 

ODA

Активный участник
#2
Все так странные эти люди:) А аналогии с текстовым видом RenderMan шейдеров не возникло? ;)

На самом деле есть классический вариант Preview для шейдера (в виде шарика). Который ко всему прочему можно произвольно менять на любой другой объект. Хотя в реальной работе этого мало. дело в том , что увидеть что и как на смом деле происходит с шейдером можно только в рабочей 3D сцене (так как кроме шейдера важно знать как распределяются его данные в пространстве. Другими словами результат сильно зависит от способа задания текстурных координат). Таким образом все настройки шейдера лучше проводить в боевых условия - т.е на объекте к которому он будет применен. Для этого надо следующее. Указать область экрана для рендера - Define render Box. В настройка редера на экран указать обновлять автоматически. В настройка рендера уcтановить приемлемые значения параметром исходя из особенностей аппаратных ресурсов для получения желаемого время/качество Preview. В результате этих действий мы получаем автоматическое изменение картинки при настройках шейдера. Кроме этого ни кто не отменял использовать OpenGl. Для контроля положения текстур в шейдере это самый быстрый способ (в V7 OpenGL существенно прибавил в скорости и качестве).

И еще:) Очень хорошо что наши пользователи имееют возможность сравнивать разные пакеты. Это безусловно расширяет кругозор. Но во всем должен быть здравый смысл. Если к трамваю приделать гусеницы, он конечно, сможет объезжать пробки по газонам, но полноценным танком он не станет (а трамваем уже не будет).

С другой строны, здравые идеи только приветствуются. Например, я бы очень хотел увидеть в V7 систему 3D Paint в скульптурном моделинге принципиально близкую к Zbush.:)
 

FSV141

Активный участник
#3
Все так странные эти люди:) А аналогии с текстовым видом RenderMan шейдеров не возникло?
Ага. Давайте еще программирование на Ассемблере вспомним... для VGA адаптеров... Не увлекались? Классная штука! Написал 150 коротеньких строк, нарисовал цветной прямоугольник - счастья до небес! И самомнению бальзам на сердце. Как же! Я СМОГ! Смотрите как я крут! Я умею заносить константы в регистры! ;)
Некоторые товарищи операционные системы на Ассемблере пишут. Быстрые и компактные. Тока на них никто не работает. Почему? Это слишком долгая тема и вообще, оффтопик.
Мир движется к ВИЗУАЛЬНОМУ программированию! Гляньте (если не видели) на Quest 3D или Virtools. Обалдеете.

На самом деле есть классический вариант Preview для шейдера (в виде шарика). Который ко всему прочему можно произвольно менять на любой другой объект.
Это нам известно.

Хотя в реальной работе этого мало. дело в том , что увидеть что и как на смом деле происходит с шейдером можно только в рабочей 3D сцене (так как кроме шейдера важно знать как распределяются его данные в пространстве. Другими словами результат сильно зависит от способа задания текстурных координат).
Согласен. Все это так и этим приходится пользоваться. Но на ранних стадиях исполнения шейдера было бы ГОРАЗДО ПРОЩЕ И БЫСТРЕЕ видеть результат с любого интересующего места.
VSL-шейдер, это же самая настоящая программа. С ветвлениями и даже циклами. А раз это программа, то в ней без дебагера не обойтись. Это вам любой программер скажет. И чем сложнее программа, тем сложнее ее отлаживать без специализированных средств.
А дебагер, между прочим, это как раз и есть - средство остановить программу в любом произвольном месте и посмотреть промежуточные результаты (значения переменных и области памяти). Только так можно отладить программу и никак иначе.
Че-то я еще не видел не одного программиста, который отлаживал программу по конечному результату ;-)
Без дебагера можно обходится лишь при написании очень простых программ. Пока что VSL-шейдеры Риалсофта не сильно сложны и работать по-старинке конечно же можно. Но ведь надо смотреть в будущее! Шутка-ли, - седьмая версия на подходе!

Кстати, раньше дебагеров небыло. Программы были сравнительно короткими и программеры просто вставляли операторы вывода значений интересующих их переменных на экран или в файл (сам так делал). Но в любом случае НАБЛЮДЕНИЕ ЗА ПРОМЕЖУТОЧНЫМИ РЕЗУЛЬТАТМИ РАБОТЫ ПРОГРАММЫ (шейдера) - НАСУЩНАЯ НЕОБХОДИМОСТЬ.

И еще:) Очень хорошо что наши пользователи имееют возможность сравнивать разные пакеты. Это безусловно расширяет кругозор. Но во всем должен быть здравый смысл. Если к трамваю приделать гусеницы, он конечно, сможет объезжать пробки по газонам, но полноценным танком он не станет (а трамваем уже не будет).
Откуда столько консерватизма???

P.S. Насколько я понимаю, VSL расшифровывается как Visual Shading Language. Ну так пусть он уже будет по-настоящему визуальным! Как говорится, назвался груздем - полезай в кузов.
Да и чего греха таить, именно визуальный способ написания мощных шейдеров является одной из сильнейших сторон Realsoft 3D. Я лишь предлагаю заметно усилить позицию программы в данном направлении.
 

ODA

Активный участник
#4
По поводу никто не работает. Все это забавно читать. Прости меня за эти слова:) Наверное стоит написать такое сообщение на любой форум по RenderMan-у и посмотреть реакцию:)

НА самом деле ты путаешь основные понятия и отсюда неправильные выводы. Задача шейдера (с точки зрения пользователя) не выдать "на гора" набор 1-ц и 0-лей. А получить распределение характеристи (свойства) в пространстве по заданному шейдером закону. Т.е основной оценкой "попали - не попали" является визуальное изображение полученное в результате работы шейдера. О том какое изображение мы должны получить определяется ЗАРАНЕЕ. т.е до написания шейдера. Это четко заданная последовательность действий - workflow. Как правило сейчас на производстве никто не рендерит финальное изображение. Для окончательной сборки используется либо 2D редактор либо компоузер. При таком подходе результатом деятельности шейдра является вывод заданного параметра в отдельный канал с последующим сохранением в файл. Вопрос. НА каком этапе этой цепочки нужно контролировать промежуточный результат в виде единиц и нулей?

Ты можешь сформулировть в чем конкретно заключается твое предложение по усилению VSL?

PS Если все же появляется потребность получить значение параметра канала то для этого есть специальный инструмент - Field Evaluаtion. Позволяет читать параметр любого канала в заданной точке пространства.
 

FSV141

Активный участник
#5
Дима, вы меня не поняли. Я не хочу видеть нули и единицы. Я-ж как раз призываю к тому, чтобы вообще человек с ними не имел дел.

Я предлагаю демонстрировать картинку на том этапе работы шейдера, на который укажет пользователь.
Допустим, я хочу сделать какой-то сложный шейдер с процедурными текстурами. Значит у меня на разных этапах генерятся текстуры на основе шума с разными параметрами. Все это смешивается в том числе и по достаточно сложным формулам с константами, переменными и т.п. и т.п.
Так вот, я НЕ предлагаю смотреть значения переменных для каждого пикселя!
Я предлагаю смотреть изображения: "шумовых текстур", результатов их смешения и т.д. и т.п. Естественно, все это в виде картинок. Видя картинку и подкручивая ползунки и коэффициенты мы быстрее получим нужный результат. Особенно тогда, когда пользователь четко распишет сам для себя как он получает конечный материал. Как должны выглядеть его процедурные текстуры и что с ними должно произойти после определенной математической обработки.
Вот собственно и все.
Кое-где в VSL есть превьюшки у отдельных блоков. Но этого очень мало. Нужна универсальная и гибкая система предварительного просмотра результатов работы каждой стадии работы шейдера.
 

ODA

Активный участник
#6
А можно ситуацию вернуть на землю и рассмотреть конкретный пример? Думаю, тогда многое сразу станет понятнее.
 
Сверху