Разработка инструмента для театра и шоу
SL_OS_SCRIPTING+
Здравствуйте дорогие друзья.
Многочисленные просьбы о написании инструментария для СЛ, для использования в шоу и театральных постановках подвигли меня начать писать свой инструмент. Начало положено, но каким он в итоге получиться, во многом зависит от Вас, мои уважаемые подписчики и дорогие друзья. Тут я представляю короткий видео-ролик заготовки данного инструмента, а вы - люди творческие, уже сможете сами придумать то, как можно его использовать в театальных и шоу-постановках.
Я готов к сотрудничеству со всеми заинтересованными лицами. Результат нашей совместной работы будет опубликован абсолютно бесплатно и с открытым исходным кодом для всех желающих им воспользоваться.
С уважением - mainspirit.
Собственно, здесь имеем частный случай применения одной операции ко множеству одинаковых однопримовых объектов, слинкованных в один.
Чаще мы имеем другую ситуацию, совершенно разные многопримовые объекты, к которым мы применяем разные операции в разное время. Допустим, один я двигаю, другой вращаю, у третьего изменяю размер, на четвертом текстуру, на пятом управляю прозрачностью, на шестом цветностью и т.д.
Это можно в принципе реализовать и в многопримовом объекте, но представь себе реальную ситуацию, когда тебе в декорации на 400 прим, объединенных в один объект, нужно найти скажем 50 прим, относящихся к визуально одному объекту, и к нему применить нужные операции? При этом, мы еще имеем множество граней, которые нужно указывать при таких операциях как смена текстур и многих других. Представь себе, как будет выглядеть твой командный файл для управления всем этим и каким увлекательным будет его процесс написания? Сомневаюсь что на этом фоне будет огромный выигрыш от замены нескольких скриптов на один.
Поэтому как частный случай для определенных конкретных условий, великолепно. Как универсальный скрипт для управления объектами на сцене — скорее всего нет, из-за большой сложности управления и написания командного файла.
Ну и как не печально, весь выигрыш от уменьшения количества скриптов в большим запасом перекроют пара лишних аватаров, прилетевших на постановку, на которых их надето по несколько сотен.
Что касается 400, тут я пока не могу ответить на этот вопрос, потому что есть ограничение по объединению до 200 прим точно.
Однако, объединяются объекты по ID, и при их объединении можно учитывать и другие параметры объектов, таким образом можно сгруппировать автоматически определенные объекты в нужной последовательности. Но процессоров должно быть несколько, это хорошая идея, спасибо.
wiki.secondlife.com/wiki/LlCreateLink
Первый пример кода это рез объекта из инвентаря root и его линкование, у тебя это в цикле матрицей 10 х 10.
Линковать объекты во всех случаях, это все равно подход неправильный, ибо не все манипуляции с объектами будут доступны в таком варианте, нарушится работа других скриптов из-за линкования объектов. Я сразу покажу тебе пример, который станет невозможен для реализации, если оставляем линкование как императив.
youtu.be/IwTlV19xT5k?t=1098
Если уж для театра, то скорее всего нужно писать полноценный резер со чтением заметки, а не просто llRezObject(ObjectName, llGetPos() + <0,0,0.5>, ZERO_VECTOR, llGetRot(), 0);
Соответственно нужен скрипт для объектов, скрипт который будет формировать эту заметку, опрашивая объекты и получая координаты и углы. Ибо объекты то будут разноплановые, и их сначала нужно разрезить, а потом уже крутить-вертеть.
Опять-таки, заметка в абсолютных координатах и углах создаст проблемы с переносом при смене сима-парселя, нужны координаты относительные, которые задаются положением какого-нибудь объекта или иным способом.
Хотя опять-таки, их валом на маркете по очень даже демократичным ценам, с возможностями, которых хватит всем, было бы желание. Покупные не все могут освоить, а ты им скрипт и команды на каналы)
Работы тут море, это мы касаемся только операций с объектами, пока даже не касаясь системы перемещения аватаров и их анимирования, если я расскажу что там нужно сделать, ты просто схватишься за голову.
Которую кстати нужно синхронизировать с операциями с объектами, причем с большой точностью. Аватар скажем поднимает руку, и из руки вырывается луч (это уж мой пример из постановки которая скоро будет показана), фактически луч — объект который мы достали перемещением, но это нужно сделать с большой точностью, даже разброс в 0,5 секунды будет заметен.
Нужен командный скрипт, который будет соединять воедино все, систему перемешений и анимировая, резов и любых манипуляций с объектами.
Команды в чат не уместны, и даже кнопки на хадах с повещенными командами годятся только для самых простых сцен с небольшим количеством действий.
Командный скрипт должен вычитывать заметку, которая есть сценарий, и соединят все воедино.
Это в двух словах, объем работы если все писать самому просто сумасшедший.
Если это проект сугубо некоммерческий, то я готов поаплодировать, учитывая объем и сложность работы, необходимости тщательной обкатки, а также поддержки.
Основная концепция такая, что есть некая центральная база, к которой подключается процессор, которых может быть несколько.
База взаимодействует с процессорами через обычный канал связи.
Сами декорации загружаются в процессор как его инвентарь, но только после предварительной подготовки, потом резяца и линкуются с процессором. В дальнейшем он управляет декорациями как своими частями, по сценарию или под управлением базы.
Как только будет немного что-то готово — я сразу выложу видео.
Язык написания заметки-сценария при сохранении нужной гибкости уже мало будет отличаться от собственно написания непосредственно скрипта. Для передвижения объекта из точки А в точку Б мы должны указать номер (ID) объекта, команду на передвижение, начальные и конечные координаты, время за которое объект должен совершить передвижение, начальные и конечные углы поворота, скорость поворота объекта. В команде на вращение опять-таки, скорость, оси. Интерпретатор заметки и в целом управляющий скрипт могут приобрести монструозный вид, и исполняться медленно, создавая ту самую нагрузку на сервер.
В моем варианте я просто вложу пропишу координаты и скорость в простенький скрипт передвижения, а командный скрипт оправит простую команду в нужный момент на нужный канал. Команда просто триггер на исполнение последовательности в скрипте целевого объекта, момент интерпретации команды, а значит и значительный блок дополнительного кода в принципе отсутствуют. Таких последовательностей в скрипте может быть столько, сколько мне нужно для управления объектом. Разумеется, я не пишу каждый раз все заново, большинство операций типовые, и просто берется подходящий блок из уже написанного, и переделывается нужным образом.
Приведу маленькое сравнение. У меня есть пара навороченных покупных резеров. Один работает с заметками, другой, неприлично дорогой, вообще не требует заметок, я просто редактирую сцену как надо и все изменения в положении объектов тут же фиксируется. Но у меня есть и третий резер, который я написал сам. Зачем он при наличии таких инструментов? Как раз его применение состоит в его простоте, потому что скрипт работает практически мгновенно именно за счет того, что он крайне прост. При этом в жертву принесено удобство, нужно вручную прописать в этот скрипт названия объектов, координаты и углы. Зато скорость реза сравнима со скоростью перемещения объектов в пределах парселя. Навороченные резеры не в пример удобнее, но и резят намного медленнее именно за счет сложности их скриптов. Есть некоторые ситуации когда это критично, а примов может не хватить для размещения объектов за пределами сцены и перемещения в нужный момент.
Вот небольшой намек для правильного выбора подхода к разработке.
Функция llListen() включает прослушивание каналов, за которое отвечает событие Listen{}. Это ресурсо-затратный процесс уже сам по себе, а если их несколько, то вообще труба. В линден лаб вики не зря висит предупреждение:
.
Объединение объектов как минимум позволит сократить кол-во процессов такого прослушивания.
Что касается оптимизации на минимальное использование ноткарт, при сканировании группы объектов, процессор помещает информацию о том, к какой группе они принадлежат, координаты относительно процессора а так-же поворот объекта — в каждый объект, в раздел ОПИСАНИЕ, куда мы можем сохранять целых 128 байт кода)))
wiki.secondlife.com/wiki/LlMessageLinked
Количество прослушиваний сократили. Даст это выигрыш в уменьшении нагрузки на сервер, либо она наоборот увеличиться, за счет резкого увеличения сложности управляющих скриптов, тут очевидно может дать ответ только практика.
Первая причина, у меня нет никакой уверенности в том, что будет выигрыш по загрузке сервера. Напомню, что язык LSL является в чистом виде реализацией парадигмы event-driven programming, в нем нет привычных классических потоков, есть так называемые «события» обработка которых наступает в случае наступления определенных условий для срабатывания триггера. Остальное время скрипт ждет наступления события, то есть, простаивает. Допустим, у нас установлен дескриптор прослушивания listen_handle на определенном канале. При поступлении на данный канал сообщения, которое соответствует установленным фильтрам, срабатывает событие listen которое запускает установленную последовательность обработки указанного события. Если мы сдуру установим дескриптор на публичный канал 0, без установленных дополнительных фильтров, то обработчик у нас будет запускаться постоянно и нагрузку на сервер мы конечно создадим немалую. А если канал не публичный, да и вообще редко используемый? Часто ли будет срабатывать событие listen? Думаю не чаще, чем будет на указанный канал поступать наша команда. Не говоря про то, что можно установить дополнительные фильтры, и срабатывание будет происходить еще реже. Об этом собственно и говориться в описании функции llListen, там категорически не рекомендуется использовать публичный канал без необходимости. В остальном, при соблюдении указанного условия, я не вижу разницы в загрузке сервера при использовании события llListen в сравнении с использованием скажем touch_start. В одном случае скрипт ждет поступления команды на определенный канал, соответствующей заданным фильтрам, во втором случае скрипт ждет начала «клика» на объект. Можно ли делать заключение, что в первом случае мы огромную нагрузку создаем, а во втором — все замечательно? Думаю, тем кто немного знаком с парадигмой event-driven programming, понятно, что это не так. Собственно, мы это и видим в описании, там же говорится о нежелательности использования публичного канала и бездумного установления множества дескрипторов. Рекомендуется использовать отличный от нулевого и по возможности редко используемый канал, что в принципе всегда и делается.
В общем, у меня есть определенные сомнения в необходимости городить весь огород. Для себя лично я на ближайшую перспективу избрал другую парадигму управления объектами в сцене, можно условно ее назвать технологией «непрерывного распределенного реза». Суть кратко состоит в том, что мы имеем на сцене только те объекты, которые необходимы для использования в данный момент. Это очень актуально для сложных сцен, где сцена в целом или ее части меняются в процессе выполнения сценария. Классический единовременный рез требует необходимости разрезить все что может понадобиться разом, объекты со скриптами будут занимать примы и ждать своей очереди в процессе выполнения сценария, что конечно же не очень хорошо. В этой же парадигме мы резим объекты когда они нужны, с некоторым небольшим упреждением, необходимым для их прогрузки, при необходимости объекты перемещаются потом на заданные координаты, выводятся из невидимости, либо иным способом появляются в составе декорации. Когда необходимость в объекте отпадает, он уничтожается немедленно, не занимая ресурсы. Всем этим управляет разумеется сценарий, в котором время появления и исчезновения объектов четко приписано. Также схема учитывает возможность использования в сцене объектов, принадлежащих разным аватарам. Если над сценой работает несколько человек, у одно есть одни необходимые объекты, у другого — другие, это очень полезно.