Povray-3.7: Неофициальный экспортёр

[sungreen]

... при изменении цвета, перемещении ползунков, материал в окне предпросмотра не обновляется ...
... при выборе паттерна - обновляется сразу ...

[LanuHum]

... при изменении цвета, перемещении ползунков, материал в окне предпросмотра не обновляется ...
... при выборе паттерна - обновляется сразу ...

У меня такая же картина. Сразу обновляется и при изменении размеров окна превью.
Где будем искать причину?

Побежал я на работу...

[bdancer]

bdancer, а ты не подскажешь, почему у меня активный материал объекта сцены предпросмотра не равен активному материалу активного объекта сцены для рендера?

Может и подсказал бы, если бы понял о чем речь =)

[LanuHum]

Может и подсказал бы, если бы понял о чем речь =)

А, посмотри код в render.py
Ныне строка 1014, а впереди вот эти строчки:

Код

            for ob in scene.objects:
                if ob.type=='MESH':
                    scene.objects.active=ob

В принципе, этих строчек быть не должно, но, если их нет, то рендерится объект с неизвестным мне материалом, который я нигде и никогда не назначал

Код

            ob=scene.objects.active
            print (ob.name)

checkers.002
Получается, что в сцене превью активным является объект checkers.002, материал которого не содержит нодов
#declare checkerdark = texture {pigment {rgbt <0.02744,0.02743,0.02743,0>}}
Я от фонаря решил сделать последний меш активным, и, вроде как получилось, но, это неверно, ибо этот объект хоть и имеет это дерево нодов, не имеет ior, который я присваиваю объекту.
Ior я, вообще нахожу смешно:

Код

            ior=0
            for obj in bpy.data.objects:
                if obj.povray.object_ior>1:
                    ior=obj.povray.object_ior

Это не будет работать, если будет несколько объектов с различными индексами преломления
Получается так, что сцена превью имеет собственные объекты:

Код

            for ob in scene.objects:
                print (ob.name)

checkers.008
checkers.007
checkers.004
checkers.019
checkers.022
checkers.017
checkers.014
checkers.013
checkers.010
Camera
previewlamp
checkers.003
checkers.002
previewhair
Lamp.008
Lamp.004
Lamp.003
previewcube
preview.005
preview.006
texture
preview.004
preview
Lamp
preview.003
Lamp.002
preview.002
Lamp.001
CameraAtmo
И активным является чёрт его знает какой, но ни с тем материалом, который должен быть.
 bpy.data.objects совсем другие

Код

            for obj in bpy.data.objects:
                print (obj.name, obj.type)

Camera CAMERA
Cube MESH
Lamp LAMP

[bdancer]

Да, все верно, для превью подгружается отдельная сцена со своими объектами; активен ли объект никак не связано с тем является ли он превью объектом.

Найти материал можно так:

Код

for ob in scene.objects:
    if not ob.type == 'MESH':
        continue
    if not ob.is_visible(scene):
        continue
    if not ob.name.startswith('preview'):
        continue
    for slot in ob.material_slots:
        ma = slot.material
        if ma:
            # This will be the preview material
            print("Material: %s" % ma.name)

Здесь 'scene' это та scene, что передается в def render(self, scene), a _не_ bpy.context.scene.

[LanuHum]

Найти материал можно так:

Благодарю.

[LanuHum]

В общем, не нахожу я, что  нужно сделать, чтобы действия в color ramp и стандартных сокетах color являлись сигналом к перерисовке превью.
Действия в пользовательском сокете color вызывают перерисовку, но в нём нет альфы. Можно, конечно, крутилку добавить, но, color ramp пользовательским ни сделать.
Ой, брошу я этот бесов экспортёр. Так программа не пишется: то одно не работает по неизвестной причине, то другое...

[bdancer]

В общем, не нахожу я, что  нужно сделать, чтобы действия в color ramp и стандартных сокетах color являлись сигналом к перерисовке превью.

Простого способа нет. Питоновые деревья не генерируют обновления превью, потому что блендер не знает о том что они должны это делать. Допустим соединение/пересоединение нод тоже не обновляет превью.
Я это у себя решил довольно грубо - так как я все равно делаю патчи для экспорта, то я добавил код для создания этого события на основании ntree.bl_idname.
Попробую сделать обобщенный патч...

[Update]
Пока получается как-то так: https://developer.blender.org/D738, посмотрим чего блен-девы скажут.

[LanuHum]

Допустим соединение/пересоединение нод тоже не обновляет превью.

У меня соединение/пересоединение обновляет превью. Как раз это один из способов получить нужную картинку. Крутишь color ramp, затем просто отсоединяешь любой сокет, и тут же его присоединяешь - картинка обновляется. Картинка обновляется и при изменении числовых параметров и enumProp.

Простого способа нет.

А, вот здесь про что написано?

Detecting Scene Updates

Functionality was added to detect when the scene changes, for example for external render engines that want to do interactive rendering.

http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.61/Python

[LanuHum]

sungreen, обнови экспортёр, и проверь вложенный файл. У меня, вроде, обновляется. Осталось укротить color ramp.
Я заменил стандартный сокет color на пользовательский. Теперь альфы не будет. Добавил крутилку transmit  в ноде color. Это using namespace Povray : 1-alpha  в Блендере. Вообще, я склонен использовать все термины Поврей. Об этом мы говорили вначале. Мнение было "НЕ ПРОТИВ"

[вложение удалено Администратором]

[sungreen]

... пока не могу понять в чём дело, но после обновления экспортёр не находит по указанному месту бинарный файл - *** POVRAY FILE NOT FOUND *** ...

[LanuHum]

... пока не могу понять в чём дело, но после обновления экспортёр не находит по указанному месту бинарный файл - *** POVRAY FILE NOT FOUND *** ...

Не бинарный, нет отрендерённой картинки
Ты точно загрузил версию обновлённую 2 часа назад?
Так было, когда render.py стр 884-887

Код

class PovrayRender(bpy.types.RenderEngine):
    bl_idname = 'POVRAY'
    bl_label = "Povray render"
    bl_use_shading_nodes = True

Сейчас последняя строчка 887 закомментирована и gui  GitHub показывает, что все изменения в репозиторий внесены
# bl_use_shading_nodes = True
и далее стр 888, 889

Код

    bl_use_preview = True
    DELAY = 0.5

Проверь. У меня работает:

[вложение удалено Администратором]

[sungreen]

... еще раз попробую высказаться на эту тему для собственного понимания решения и для логичного решения в целом, предлагаю перейти в надсистему и обсудить решение задачи как частный случай более общей надзадачи. То есть рассмотреть не конкретный экспортёр к поврею, а абстрактный экпортёр общего назначения к классу рендеров, которые принимают в качестве параметра внешний файл с описанием сцены в установленном для рендера формате ...

... в рамках функциональной декомпозиции можно сказать, что экспортёр условно решает подзадачи: экспорта сцены в формат рендера; взаимодействие с рендеров (запуск, передача данных, получение результатов); обеспечение пользовательского окружения для подготовки сцены и дополнительно можно выделить контроль, отладку, расширение, автоматическое обновление (сервисные функции) ...

... в моём понимании при использовании нескольких рендеров, основное неудобство состоит в том, что приходится перенастраивать сцены (свет, материалы и т.п.). Когда пользователь только наичнает осваивать новый рендер, то естественно он хочет попробовать как будет выглядеть его любимая сцена в новом рендере. Мне лично было бы интересно иметь такую возможность визуализировать сцены в различных рендерах без внесения изменений. Но априори так не получиться, поскольку рендеры имеют свои фичи. В силу чего в интерфейс блендера  добавляется множество дополнительных элементов управления настройками свойств объектов с учётом особенностей выбранного рендера. К тому же не всегда очевидно к чему относятся эти элементы ...

... так же в пользовательском окружении требуется интерактивное взаимодействие с рендером - предпросмотр  материалов, предварительный рендеринг во вьюпорте, возвращение результатов в редактор. В этом ключе от экспортёра требуется максимальная скорость формирования и обмена данными с рендером. Оптимизация  кода это отдельная задача и опять возвращаясь в надсистему, нужно чтобы экспортёр был универсальным и в тоже время эффективным ...

... универсальный экпортёр не должен содержать код, связанный с конкретным рендером. Если такой код и должен присутствовать, то в отдельном модуле, но основную часть экспорта сцены в формат рендера хотелось бы делать в нотациях формата через файлы-шаблоны. То есть не прописывать жесткий код в экспортёр, а формировать выходной файл через унифицированные процедуры экспорта компонентов сцены. По сути на этом этапе экспортёр должен получить на вход блендер-данные и название рендера, сформировать файлы для рендера по указанным шаблонам,правилам ...

... такая абстракция избавит код экспортёра от многочисленных проверок "что если"; позволит распараллелить разработку шаблонов; минимизирует внесение изменений в код экспортёра при добавлении новых фич в рендер; позволит разрабатывать шаблоны для кастомных сборок рендера ...

... хотелось бы иметь возможность визуально контролировать текст, вносимый в файл описания сцены в формате рендера конкретным выбранным элементом ...

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

... экспортёр требуется, потому что рендеры имеют собственные форматы описания сцены, а экспортёр выполняет роль посредника между блендером и рендером. Тогда можно рассмотреть такое противоречие "быть или не быть" - с одной стороны экспортёр должен быть чтобы обеспечить конвертацию данных в формат рендера, с другой стороны экспортёра не долно быть чтобы обеспечить максимальную скорость передачи данных от блендера к рендеру. В принципе чтобы экспортёра не было, достаточно чтобы сами рендеры работади с одним общим форматом описания сцены, тогда блендер подготавливал бы файл в этом универсальном формате и отдавал бы прямо рендеру без посредника - эспортёра. Код экспортёра также может быть внедрен в исходный код блендера, тогда скорость обмена будет выше ...

... или рассмотрим другое противоречие "скорость против универсальности" - с одной стороны экспортёр должен поддерживать множество форматов, с другой стороны он должен обеспечить максимальную скорость взаимодействия с конкретным выбранным рендером. Обычное решение - "подстелить соломки". Поскольку на выходе требуется текст описания сцены, то отдельные фрагменты текста могут быть заранее сформированы на основе уже готовых шаблонов на этапе внесения изменений в сцену, храниться в памяти и обновляться только при необходимости. Сборку конечного файла производить слиянием и(или) внедрением фрагментов, с минимизацией проверок "что если" ...

... унификация кода экспортёра может повысит его функциональность. Но это опять же из разряда "поэкспериментировать", без очевидного профита и возможно с окончательной потерей веры в человечество ...

... план такой - как обычно взять за основу пример из блендерАПИ, и начинать обвешивать его функциональными модулями абстрактного экспортёра. Вначале реализовать модуль вызова рендера как внешнего приложения с функциями настройки конфигурации (чтения, сохранения),  запуск рендера с параметрами, контроль процесса визуализации и обработка результатов работы рендера ...

... далее мне нужны в редакторе нодов два узла - один источник текста в формате описания сцены, а второй приемник этого текста и генератор файла, который можно послать на рендер ...

... по идее при наличии этого уже можно попробовать запустить визуализацию в нексольких рендерах - поврей, суслик, митцуба или любой другой наличествующий. Не должно быть особых преград - файл просто передается выбранному рендеру, рендер делает свою работу, результат возвращается в редактор ...

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

... тогда можно попробовать делать декомпозицию текста описания сцены и начинать привязвать узлы к реальным объектам редактора ...

[bdancer]

У меня соединение/пересоединение обновляет превью

Ну, так отлично, проблем меньше.

А, вот здесь про что написано?

Используй коллбеки, никто не запрещает, заставишь эти коллбеки обновлять превью будешь ваще молодец =)

[LanuHum]

Используй коллбеки, никто не запрещает, заставишь эти коллбеки обновлять превью будешь ваще молодец =)

Как я могу написать коллбек для встроенного компонента?

sungreen, хочу тебя понять, но не могу.
Давай начнём с этого:

... универсальный экпортёр не должен содержать код, связанный с конкретным рендером. Если такой код и должен присутствовать, то в отдельном модуле, но основную часть экспорта сцены в формат рендера хотелось бы делать в нотациях формата через файлы-шаблоны. То есть не прописывать жесткий код в экспортёр, а формировать выходной файл через унифицированные процедуры экспорта компонентов сцены. По сути на этом этапе экспортёр должен получить на вход блендер-данные и название рендера, сформировать файлы для рендера по указанным шаблонам,правилам ...

Покажи мне эти файлы-шаблоны. Ты говоришь о них, но видишь ли ты их материализованными?
Если взять конкретно Поврей, то, на мой взгляд, официальная версия экспортёра, которая входит в состав аддонов при официальной версии Блендера подогнана под интернал...Может, лучше взять её за основу создания твоей версии? И, зачем ноды, чтобы получить файл с общими данными сцены типа: камера{persp,location,rotation}, свет{point,location,power}, меш{verts,edges,faces,normal} ?

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