NiParticles примечания part 1
всякие разные уточнения, наблюдения и примечания, часть первая!)))
Примечание по типам частиц.
Все типы частиц (NiRotatingParticles, NiAutoNormalParticles) можно свободно конвертировать в NiParticles, что и было подтверждено практическими опытами.
Тем более, что в следующих версиях движка это и было сделано по умолчанию. Частицы были упрощены до NiParticles.
Примечание.
Что, по идее, должно отвечать за влияние освещение на частицы.
Т.е. аналогично нормалям в обычной шейпдате.
Либо, этот тип частиц, должен включать режим спрайтов, т.е. когда частицы всегда выровнены "лицом" на камеру.
Но, на практике, роли не играет, т.к. движок все берет на себя.
Все типы частиц это спрайты выравниваемые на камеру!
Но, на практике, это совсем не работает, т.к. частицы всегда повернуты лицом к камере.
Однако, это может быть использовано в ОпМв.
Создавая глобальные завихрения в массиве частиц.
Т.к. выравнивание (AutoNormal) и вращение (RotatingParticles) фактически не работают.
Фактически это является родительским объектом и не должен бы работать в ниф файлах.
Однако, он может работать, хотя иногда, случаются интересные (или не очень) явления (баги).
Примечание.
Было высказано предположение, что смена типов частиц с АвтоНормал на Ротайтинг, имело бы смысл при использовании ПартиклМешей.
Позволяя менять поведение геометрических объектов, в одном случае придавая им объемность, в другом позволяя вращаться.
Однако, в МВ все это не имеет смысла, т.к. ПартиклМеши не завозили.
Хотя, если ОпМВ получит поддержку этого объекта, в рассуждении о настройках типов частиц, появиться больше смысла.
Примечание.
При экспорте через ТЕС и ФФЕ экспортеры частицы конвертируются, по умолчанию, следующим образом:
|
МАХ
|
Nif (TESexporter)
|
Nif (FFE)
|
Примечание
|
|
|
NiAutoNormalParticles
|
NiAutoNormalParticles
|
|
|
|
NiAutoNormalParticles
|
|
!! ФФЕ всегда создает этот объект!
|
|
|
NiAutoNormalParticles
|
NiAutoNormalParticles
|
|
|
|
NiRotatingParticles
|
NiRotatingParticles
|
|
|
|
NiRotatingParticles
|
NiRotatingParticles
|
Только этот объект может создавать значения в разделе Start Random!
|
|
|
NiRotatingParticles
|
NiRotatingParticles
|
|
Но, при этом, можно, дополнительно в ручную, изменить NiRotatingParticles на NiAutoNormalParticles.
Собственно этот раздел и определяет тип частиц в ниф файле.
Т.е. все отличие в настройке вращения частиц по умолчанию.
Также, в МАХе, можно сменить тип частиц на NiParticleMeshes:
- в настройках Particle Type выбрать Instanced geometry.
Но делать этого, увы, смысла нет.
Т.к. этот тип частиц не поддержан в МВ.
Вероятно, объект завезли в 4.2 версии движка, либо в каком-то ином патче для 4.0.
Примечание.
ФФЕ модуль умеет создавать NiParticleMeshes при экспорте всех типов частиц, которым была выбрана опция Instanced geometry и указан некий 3д объект.
Также, NiParticleMeshes всегда создаются для частиц типа Snow.
ТесЭкспортер не умеет создавать этот тип записи в Ниф файле, так как движок МВ не поддерживает этот объект.
Однако, NiParticleMeshes оказался тем самым типом частиц, который умеет использовать 3д объекты в моделях, вместо обычных примитивных спрайтов!
Т.е. при экспорте узла NiParticleMeshes в ниф файле система частиц будет представлена 3д объектами, которые были выбраны в Instanced geometry настроек частиц.
В NiParticleMeshes может работать NiParticleRotation! Не совсем корректно, но все же может.
Т.е. объекты будут иметь некоторый эффект от этого "контроллера".
Увы, такую вкусняшку, беседка заменила сомнительным клонированием частиц по иерархии объектов.
Сам по себе движок 4ой версии должен поддерживать этот элемент, т.к. ФФЕ создает нифки 4-ой версии!
Поддержаны следующие силы воздействия:
Плоские отражающие поверхности:
Сферические отражатели:
Дефлекторы сложной формы (Udeflectors), и прочие силы воздействия; Wind, Motor, Push - не поддержаны (движком 4.0 версии).
Общие примечания о частицах.
Важно!
Для частиц размещаемых в редакторе, обязательно нужен "физический" объект, ака простой шейп.
Если в модели частиц нет такого объекта, становится не возможным их перемещение в сцене редактора.
Т.е. курсор не будет их подцеплять.
Исключение - магические снаряды, управление которыми полностью возлагается на движок.
Размещение, оных, через редактор, не предполагается, отчего шейп им, не нужен.
Примечание.
В файлах с частицами, возможно использование маркера.
Что позволит перемещать частицы в сцене, но полностью скроет все "физические" объекты в игре.
Примечание.
Существует еще одна заметная проблема связанная с частицам.
Это скалирование (scale) объектов.
Т.е. если нода частиц (либо сами частицы) имеют размер не равный 1.0000, но больше, или меньше, это будет приводить к разного рода явлениям.
Обычно, это выглядит как серьезное смещение частиц от их намеченных координат.
*стоит заметить, что это не так чтобы редкая проблема, иногда так и хочется увеличить размер Ноды, полагая, что это увеличит только размер самих частиц. Однако, это изменяет не только их размеры, но и точку их "опоры", что и приводит к этой оказии.
Например, частицы добавленные в глаза скелета (см. скрины ниже).
При стандартном значении размера их ноды и эмиттера, равного1.0 - будут корректно размещены в глазницах.
НО! Стоит изменить размер ноде, как частицы, сразу же улетят в сторону и будут перемещаться перед существом!
При этом, сам размер частиц, не измениться, но лишь сами частицы значительно сместятся от указанных в файле координат.
НИКОГДА НЕ МЕНЯЙТЕ НОДЕ ЧАСТИЦ (им самим и их эмиттеру) значение SCALE!
Кроме случаев, когда "траст ми! вы знаете что вы делаете"(с).
Если же Вы никак не можете понять отчего частицы плавают вокруг существа, вместо того чтобы аккуратно стоять в означенных координатах,
то бегите смотреть на этот параметр. 99% проблема будет связана с его значением.
А на оставшиеся 1% с флагом эмиттера, или ноды частиц.
Т.е. если частицы упаковать в обычную ноду, а эмиттер будет иметь регулярный флаг (2-10-12), то, возможно, частицы останутся на своих местах,
однако, при этом потеряются возможность создания шлейфа.
Примечание.
Частицы отправятся в свободное плавание вокруг модели и в случае изменения размера оной в игре.
Т.е. если существу (или светильнику, или активатору) задать, в редакторе, размер не равный 1.0.
Т.е. когда объект имеет в своем составе частицы, постарайтесь обойтись без изменения его масштаба в игре.
Не меняйте размер ни эмиттеру, ни ноде частиц, ни самим частицам!
Т.к. это всегда приводит к искажениям.
Если же нужно сделать частиц больше, то измените параметр Size в их контроллере.
|
|
|
|
Корректное отображение частиц в глазницах.
+ Шлейф.
|
У правой системы частиц, значение scale=1.0
А вот у левой =1.4 и посмотрите куда сразу улетели частицы!
Да, в конец комнаты!
Однако, в этом может быть и свой плюс.
|
Примечание.
Вид частиц на оружии из глаз героя может отличаться от вида от 3-его лица.
Связано с разным положением Weapon Bone в этих ниф файлах.
Xbase_anim и Xbase_Anim.1st.
На это влияет наличие ключей масштаба, в файлах базовой анимации и Расовое масштабирование.
Т.е. настройки роста по Расам в редакторе, окажут влияние на все частицы.
Как в Оружии, так и в доспехах.
Особенно это будет заметно в шлемах с "горящими глазами".
Частично, либо полностью, исправляется в МСП 2.4 версии, но в ванили, это расовое скалирование, представляет проблему.
Примечание.
Изменение масштаба частиц используемых в шлемах *Игрок, нпс, всегда происходит по причине изменения пропорций расы.
Однако, это баг, приводящий к 100% искажению размера частиц, исправлен в МСП 2.4.
Добавление контроллера фиксирующего размер на эмиттер и сами частицы не приносит положительного результата.
Но только использование МСП!
|
|
|
|
Ваниль, без МСП.
|
|
|
|
|
|
МСП 2.4
|
Частицы сохраняют свои позиции.
|
Примечание.
Если частицы использовались в парных моделях брони, они перестают нормально отображаться!
Т.е. если частицы были добавлены, например; к голенищу сапога, или наручу, или наплечникам, то при одевании на игрока, частицы будут работать только с правой стороны.
Однако, это можно исправить.
Это позволит сохранить отображение частиц на обеих сторонах доспеха для любых парных объектов.
Т.е. фактически, частицы продолжают работать, но их видимые поверхности, оказываются перевернуты на обратную сторону от камеры!
И добавление простейшего варианта трафарета, позволяющего рисовать обе стороны поверхности, позволяет исправить эту оказию.
Примечание.
Для частиц магии (т.е. тех фаерболов, что кастует игрок и прочие существа), крайне желательно наличие BoundBox!
Это нужно для точного определения столкновений снаряда с преградами.
Иначе, "снаряды" будут взрываться при малейшем касании "краями" частицами любого объекта.
Что сделает невозможным "стрельбу" в узких местах.
Примечание.
ФФЕ и ТЕСэксопртеры всегда создают эти свойства.
Но, если этих свойств нет, то их не так чтобы обязательно, было добавлять.
Хотя эта запись, должна способствовать сохранению частиц в сцене, когда движок может посчитать, что их в ней уже не должно быть.
Но, как показали изыскания уважаемого Greatness7, sgokeep действительно могут оказывать влияние на объекты!
Но не являются обязательным условием при работе с частицами.
Т.е. добавление этой записи, не является чем-то критически важным и им можно пренебречь, особенно при создании частиц одним Нифскопом.
Примечание.
Частицы не имеют UV set, т.е. им не требуется устанавливать развертку текстуры.
С одной стороны это облегчает их создание в Нифскопе, с другой не позволяет растянуть текстуру на весь массив частиц сразу.
В 3д МАХ опции наложения текстурных координат на частицы недоступны.
Примечание
Частицы обязательно должны иметь точку появления в сцене, ака Эмиттер.
Если его нет, частицы не будут появляться!
Но, есть исключение, если с частиц удален контроллер анимации, они останутся в сцене на правах обычного объекта.
Однако, потребуется установить их начальные положения в нулевом кадре анимации.
NiParticlesData->Vertices
Примечание
Актуальное для систем с отрицательным временем начала анимации и рождения, а также с большим кол-вом частиц.
Особенно, если оные появляются в сцене через действие скриптов!
Для уже имеющихся в мире - это не так заметно.
NiParticleSystemController
Если в файле несколько систем частиц которые расположены в одной точке, это может приводить к падению фпс в первом кадре.
Имеет смысл разносить не только позиции эмиттеров, но и позиции нод самих частиц!
Т.е. в первом фрейме частицы появятся в своих координатах, и уже оттуда расползутся на точки эмитеров.
Т.е. значение позиции ноды частиц важно для первого фрейма!
Также, имеет значение кол-во самих частиц в каждой системе.
Фактически это позволит обойтись одной системой частиц в файле.
Которая, будет клонирована по иерархии объектов.
Примечание.
Как правило частиц в обязательном порядке содержат контроллеры анимаций, однако это лишь "издержки" экспорта.
С частиц можно свободно их удалять.
Но, это приводит к проблемам с коллизиями, т.е. игрок будет застревать в частицах.
См. ванильные файлы гробничной паутины.
Примечание.
Хорошим примером использования статичных частиц может оказаться создания Ауры (или Нимба).
Это позволит дополнительно оптимизировать файл.
Либо, использовать статичные частицы при создании LensFlare эффекта.
Поскольку такие статичные частицы остаются билбордами, не потребуется создавать дополнительных Билборд нод!
Что сократит кол-во объектов в файле.
Примечание.
Также можно создавать псевдо статичные частицы посредством изменения времени появления оных в настройках
контроллера.
Установив время рождения в отрицательных значениях (-3.3333 к примеру) и время завершения в нулевом кадре (т.е. 0.000).
Такой метод использован в некоторых ванильных моделях.
Также, можно использовать флаг 12 вместо 8, на их контроллере.
Частицы будут созданы и застынут в таком состоянии до следующего посещения ячейки игроком.
Возможно, что в этом случае, экстра запись sgokeep= может являться необходимой!
Т.к. пока игрок ходит по гробничке, частицы могут выпадать из рендеринга, который и может подумать, что им там уже совсем нет места.
Впрочем, эти данные, отдельно не проверялись!
Примечание.
Статичные частицы могут быть упакованы в
niBsAnimationNode и содержать анимацию движения света, или иную другую.
Примечание.
Статичные частицы, будут иметь проблемы при перемещении оных в игре через действие скриптов.
Т.к. появление частиц фиксировано в первом кадре их анимаций, а обновляться ему нечем.
Т.е. при перемещении, они, либо застынут в начальных координатах, либо вовсе исчезнут!
Примечание.
Также, статичные частицы НЕ ПРИНИМАЮТ текстурных эффекты!
Поскольку, частицы в таком режиме, не используют эмиттер, к ним нельзя прикрепить "физическую" поверхность (
NitriShape), что критически необходимо при наложении эффектов.
Примечание.
Это определяет работу частиц в целом.
Неправильный набор флагов может приводить к остановке появления частиц, или иным проблемам.
Однако, в разных ситуациях могут использоваться различные флаги.
В статичных объектах (например в светильниках) одни флаги, в подвижных - другие.
Но, если
NiBSParticleNode превращена в обычную NiNode, поведение частиц радикально меняется.
То что не работало, может заработать!
Примечание.
Позиция родной ноды, при появлении частиц на свет, практически всегда игнорируется ими!
Т.е. точка появления, частиц в сцене, определяется только эмиттером.
Кроме случаев:
- частицы имеют кейфрейм контроллер, размещенный непосредственно на оные.
- частицы размещаются в игре скриптами.
В этом случае, можно увидеть частицы в координатах своих нод, откуда они расползутся по координатам эмиттеров.
И в дальнейшем продолжать работать с этих позиций.
А если, частицы были фиксированы контроллером, то они будут создавать "хвост" в сторону своего эмиттера.
При этом! Следует обращать внимание на использование niBsParticleNode.
Т.е. упакованы ли частицы, или эмиттер в эту ноду.
Т.е. это будет влиять на движение частиц и влияние на оные контроллеров анимации.
Примечание.
Обращайте внимание! Что
NiBSParticleNode нужна (в основном) только переносным светильникам!
Если частицы используются в статичных светильниках (статиках, или активаторах), то:
- полезно преобразовывать NiBSParticleNode в обычную ноду!
Это положительно сказывается на стабильности их работы.
Либо, что много правильнее, менять имя корневой ноды с NiBSAnimationNode на NiBSParticleNode.
Можно использовать обычные флаги 32, или 42.
Либо 172 если нужен хвост от частиц.
Примечание.
- 96ой флаг на ноде частиц в моделях оружии и 10 флаг на их эмиттере, приводил к появлению частиц в мир, где они так и оставались.
Т.е. в руках ГГ пусто, но при этом частицы как-то реагируют на движения игрока оставаясь в том месте где появились.
Т.е. после извлечения оружия частицы исправно появлялись, а затем оставались висеть на том месте, где ГГ извлек оружие.
При этом реагируя на движение оного!
Собственно можно посмотреть здесь.
Т.е. там подробно описано случай влияния NiBSParticleNode на вложенные в нее объекты.
Здесь, NiBSParticleNode в которую и был упакован эмиттер, привел к "интересным" результатам с работой частиц.
Т.е. флаг ноды отвечал лишь за создания шлейфа (follow = false) частицам, но в данном случае он повлиял на эмиттер.
Зафиксировав его положение в мире в момент извлечения оружия.
А частицы, логично, стали появляться из точки размещения своего эмиттера!
Однако, еще стоит отметить, что для активаторов и магических эффектов, подобный трюк, с эмиттером упакованным в NiBSParticleNode, крайне полезен!
Это позволяет создавать особенно вычурные эффекты движение частиц!
Примечание.
На частицы можно, ограниченно, накинуть скин с одним (произвольно выбранным) объектом в сцене, в качестве кости.
И указав, в настройках скиндаты, вес для одного вертекса.
Этого достаточно для использования частиц в моделях брони и пр. объектах со скином.
Также следует задать частицам правильное имя (Chest 1, Groin 2 и пр).
Однако, это лишь даст возможность их увидеть в файле.
Т.к. оные будут лежать в ногах "скелета" и не захотят появляется в координатах нужной кости.
Возможно, бспаррай контроллер, позволяет добиться немного больших результатов.
Частично позволяя придавая частицам некоторые "позы"
Но получать нормальную связанную реакцию на изменения положений сетки или костей, в файлах брони - не получается(
Т.е. добавление скининга к частицам возможно, но практический пользы от этого не так много, как хотелось бы.
Примечание.
В файлах существ, можно использовать, как обычные niNode, так и NiBSParticleNode.
Некоторые тесты показали положительное воздействие этой ноды на создание шлейфа частиц за существом при движении.
Переключение на niNode приводило к более жесткой фиксации частиц с телом.
Однако, это предотвращало исчезновения частиц в некоторых случаях.
Примечание.
Связка (эмиттер и нода с частицами) позволяет получать дополнительные эффекты анимаций.
Например, если
niViscontroller находится на родительской ноде частиц, или на самих частицах, то в игре оные будут исчезать мгновенно.
Но если niViscontroller находится на эмиттере, это позволит частицам исчезать плавно.
Т.е. естественно завершив свой жизненный цикл.
Примечание (по эмиттеру и плавному исчезновению частиц)
Существует побочный эффект.
Если такой метод использован в моделях существ, существует вероятность зависания частиц после кончины существа.
Т.е. базовая анимация уже остановлена, а частицы еще не закончили свой цикл - в результате, они застывают в воздухе.
См. костяного лорда, или поднявшегося спящего.
Может быть исправлено за счет увеличения времени анимации кончины, так чтобы частицы успели завершить свой цикл.
Либо следует поместить в сцену еще один контролер невидимости, который скроет все частицы и прочие объекты наверняка!
Пускай и без возможности плавного исчезновения оных.
Однако, есть мнение, что зависание связано не со временем, а с методом обработки частиц!
Т.е. если существо погибает вне поля зрения камеры.
То при повороте камеры обратно, в момент проигрывания половины анимации кончины, можно видеть момент появления частиц!
Которые затем зависают, не успевая полностью проиграть свою анимацию, до полной остановки оной.
Однозначно стабильного метода решения не замечалось.
Есть сведение о 128 флаге (на NiBSParticleNode) который может несколько улучшить ситуацию...
Примечание
Также, через разнесение эмиттера и частиц, можно получить опосредованную анимацию дефлектора.
Т.е. анимации движения добавляются на эмиттер частиц, тогда как дефлектор находится в другом месте сцены ниф файла.
При повороте (перемещении) эмиттера, частицы соприкоснутся с дефлектором и поменяют свою траекторию.
Пламя будет искажаться при контакте с поверхностью.
Примечание.
Обращайте внимание, что частицы в файле существа, будут реагировать на
дефлектор, только в стартовых координатах существа.
Т.е. дефлектор НЕ передвигается вместе с существом!
Отчего, частицы, когда существо отойдет за зону влияния дефлектора (которая указана в их настройках) перестанут реагировать!
Но стоит существу вернуться в начальные координаты, как частицы, снова начнут реагировать на зону влияния дефлектора.
Теоретически, дефлекторам можно задавать значительную зону влияния.
Однако, если существо спуститься по лестнице, или поднимите выше, это также изменит зону влияния дефлектора!
Поэтому, использование дефлекторов в файлах существ, может быть довольно ограничено полезным.
Активатора и другие объекты с фиксированной позицией в сцене, не будут иметь таких проблем... если конечно, не начать перемещать их скриптами.
Все это связанно с особенностью организации дефлекторов, данные о позиции которых, записываются относительно положения системы частиц в сцене файла.
Примечание.
Как правило, частицы всегда должны иметь свойства альфы и
z-буффер, который предохраняет их от "строба".
- 13, 4621, 4609 для светящихся в темноте частиц.
- 237, 4845 - обычно используется для дыма.
Могут быть и иные значения.
Свойств альфы может не быть, но вот z-буффер должен быть всегда кроме самых "радикальных" случаев.
Примечание.
Нифскоп не умеет правильно отображать анимации частиц!
Нифскоп способен, относительно верно, показать только первый фрейм анимации частиц!
Правильно показывает анимацию только SceneViewer, однако он не всегда может открыть файлы nif Морровинда.
Т.е. файлы с уникальными объектами беседки не могут быть открыты, поскольку SceneViewer не понимает их!
Для просмотра таких файлов, требуется *временно* переименовывать NiBSParticleNode в обычную niNode.
Т.е. можно собирать сложный лабиринт из дефлекторов, гравитаций и бомб - а затем пускать по нему поток частиц.
На одни niParticles можно назначить несколько сил.
Точное число, не выяснялось, но оно более 10, это точно (С)
Примечание.
Как было отмечено выше, NiAutoNormalParticles и NiRotatingParticles должны были бы сообщать частицам некоторые дополнительные особенности - выравнивание на камеру (или лучшая работа со светом (?) и вращение вокруг их осей.
Однако, как сообщает справка к Геймбрио 1.1 касательно NiRotatingParticles:
base NiParticles objects still do not support rotations (as this is expensive on the current platforms).
Вероятно некоторое дополнительное вращение частиц вокруг собственной оси не поддерживалось и в ранних версиях движка, хотя сами настройки и контроллеры для этого присутствуют.
Риторическое рассуждение, без особой цели.
Возможно, NiAutoNormalParticles должны быть оптимизированы под работу Billboard-ами.
А NiRotatingParticles - под более сложное вращение вокруг их собственных осей, что требовало бы сложной геометрии частиц.
На практике, все типы частиц работают, как Billboard.
Т.е. каждая частица всегда повернута лицом к камере.
И не умеют вращаться вокруг своих осей и друг друга от слова "совсем".
Но если допустить, что NiRotatingParticles мог работать иначе, тогда, в этом разделении типов, появляется некоторая логика!
Т.е. NiRotatingParticles могли поддерживать не только плоскости (как это имеется сейчас), но и более сложные геометрические объекты в качестве частиц. Такие объекты не требовали бы постоянной ориентации на камеру и могли бы свободно вращаться вокруг собственных осей.
Однако, можно полагать, что такие сложные, в плане геометрии частицы, негативно сказывались бы на ФПС.
Отчего это и не было реализовано в тех версиях движка.
Но, конечно, нельзя исключать, что на это были иные причины.
Косвенное подтверждение этой теории можно видеть в 3д МАХ.
|
Spray
|
NiAutoNormalParticles
|
Нельзя указать Instanced geometry.
|
|
Snow
|
NiAutoNormalParticles
|
Нельзя указать Instanced geometry.
|
|
PArray
|
NiAutoNormalParticles
|
Можно указать Instanced geometry.
|
|
SuperSpray
|
NiRotatingParticles
|
Можно указать Instanced geometry.
|
|
PCloud
|
NiRotatingParticles
|
Можно указать Instanced geometry.
|
|
Blizzard
|
NiRotatingParticles
|
Можно указать Instanced geometry.
|
Т.е. типы частиц которым можно указать некоторые геометрические объекты в качестве частиц, экспортируются, как NiRotatingParticles.
А те частицы, которые не имеют такой настройки, как: NiAutoNormalParticles.
Исключение PArray. Здесь можно указать Instanced geometry, но экспортируется он, как NiAutoNormalParticles.
Но можно предположить, что это было сделано специально, т.к. PArray близок по настройкам к SuperSpray.
И можно было задействовать этот тип частиц несколько иначе.
Что и сделала беседка, введя создание NiBSPArrayController в ниф файлах, при использовании этого типа частиц в МАХ.
Примечание.
Было мнение, что раздел
Velocity в свойствах частицах может работать, сообщая оным дополнительное интерактивное ускорение.
На практике, результат был отрицательным.
Было проведено несколько тестов, как с включенным контроллером анимации частиц, так и без оного.
По видимости,
Velocity может работать ТОЛЬКО на корневой ноде ниф файла, взаимодействуя только с существами и НПСами.
