1. Пользоваться форумом на планшетах и телефонах стало удобнее благодаря Tapatalk

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

Тема в разделе "RealSoft3D", создана пользователем FSV141, 28 ноя 2008.

Модераторы: Moderator.
  1. FSV141

    FSV141 Активный участник

    С нами с:
    17.06.2008
    Сообщения:
    119
    Симпатии:
    0
    Баллы:
    11
    Возможно я не очень хорошо разобрался с редактором VSL, поэтому прошу не судить меня строго, если что-то напишу не по делу.

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

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

    ODA Знаток

    С нами с:
    13.01.2006
    Сообщения:
    176
    Симпатии:
    0
    Баллы:
    26
    Все так странные эти люди:) А аналогии с текстовым видом RenderMan шейдеров не возникло? ;)

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

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

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

    FSV141 Активный участник

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

    Это нам известно.

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

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

    Откуда столько консерватизма???

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

    ODA Знаток

    С нами с:
    13.01.2006
    Сообщения:
    176
    Симпатии:
    0
    Баллы:
    26
    По поводу никто не работает. Все это забавно читать. Прости меня за эти слова:) Наверное стоит написать такое сообщение на любой форум по RenderMan-у и посмотреть реакцию:)

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

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

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

    FSV141 Активный участник

    С нами с:
    17.06.2008
    Сообщения:
    119
    Симпатии:
    0
    Баллы:
    11
    Дима, вы меня не поняли. Я не хочу видеть нули и единицы. Я-ж как раз призываю к тому, чтобы вообще человек с ними не имел дел.

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

    ODA Знаток

    С нами с:
    13.01.2006
    Сообщения:
    176
    Симпатии:
    0
    Баллы:
    26
    А можно ситуацию вернуть на землю и рассмотреть конкретный пример? Думаю, тогда многое сразу станет понятнее.
     
  7. FSV141

    FSV141 Активный участник

    С нами с:
    17.06.2008
    Сообщения:
    119
    Симпатии:
    0
    Баллы:
    11
    Хорошо. Я постараюсь привести наглядный пример.
     
  8. ODA

    ODA Знаток

    С нами с:
    13.01.2006
    Сообщения:
    176
    Симпатии:
    0
    Баллы:
    26
    Ок Жду примера
     
Модераторы: Moderator.

Поделиться этой страницей