NiParticles - notes 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 версии).
Общие примечания о частицах.
Важно!
Для частиц размещаемых в редакторе, обязательно нужен "физический" объект, ака простой шейп.
Если в модели частиц нет такого объекта, становится не возможным их перемещение.
Т.е. курсор не будет их подцеплять.
Исключение - магические снаряды, управление которыми полностью возлагается на движок.
Размещение, оных, через редактор, не предполагается, отчего шейп им, не нужен.
Примечание.
Если частицы использовались в парных моделях брони, они перестают нормально отображаться!
Т.е. если частицы были добавлены, например; к голенищу сапога, или наручу, или наплечникам, то при одевании на игрока, частицы будут работать только с правой стороны.
Однако, это можно исправить.
Это позволит сохранить отображение частиц на обеих сторонах доспеха для любых парных объектов.
Т.е. фактически, частицы продолжают работать, но их видимые поверхности, оказываются перевернуты на обратную сторону от камеры!
Примечание.
Для частиц магии (т.е. тех фаерболов, что кастует игрок и прочие существа), крайне желательно наличие BoundBox!
Это нужно для точного определения столкновений снаряда с преградами.
Иначе, "снаряды" будут взрываться при малейшем касании частицами любого объекта.
Что сделает невозможным "стрельбу" в узких местах.
Примечание.
ФФЕ и ТЕСэксопртеры всегда создают эти свойства.
Но, если этих свойств нет, то их следует добавить (в Нифскопе). Как на эмиттер, так и на сами частицы.
Эта запись, способствует сохранению частиц в сцене, когда движок может посчитать, что их в ней уже не должно быть.
Примечание.
Частицы не имеют UV set, т.е. им не требуется устанавливать развертку текстуры.
С одной стороны это облегчает их создание в Нифскопе, с другой не позволяет растянуть текстуру на весь массив частиц сразу.
В 3д МАХ опции наложения текстурных координат на частицы недоступны.
Примечание
Частицы обязательно должны иметь точку появления в сцене, ака Эмиттер.
Если его нет, частицы не будут появляться!
Но, есть исключение, если с частиц удален контроллер анимации, они останутся в сцене на правах обычного объекта.
Однако, потребуется установить их начальные положения в нулевом кадре анимации.
NiParticlesData->Vertices
Примечание
Актуальное для систем с отрицательным временем начала анимации и рождения, а также с большим кол-вом частиц.
Особенно, если оные появляются в сцене через действие скриптов!
Для уже имеющихся в мире - это не так заметно.
NiParticleSystemController
Если в файле несколько систем частиц которые расположены в одной точке, это может приводить к падению фпс в первом кадре.
Имеет смысл разносить не только позиции эмиттеров, но и позиции нод самих частиц!
Т.е. в первом фрейме частицы появятся в своих координатах, и уже оттуда расползутся на точки эмитеров.
Т.е. значение позиции ноды частиц важно для первого фрейма!
Также, имеет значение кол-во самих частиц в каждой системе.
Фактически это позволит обойтись одной системой частиц в файле.
Которая, будет клонирована по иерархии объектов.
Примечание.
Как правило частиц в обязательном порядке содержат контроллеры анимаций, однако это лишь "издержки" экспорта.
С частиц можно свободно их удалять.
Но, это приводит к проблемам с коллизиями, т.е. игрок будет застревать в частицах.
См. ванильные файлы гробничной паутины.
Примечание.
Также можно создавать псевдо статичные частицы посредством изменения времени появления оных в настройках
контроллера.
Установив время рождения в отрицательных значениях (-3.3333 к примеру) и время завершения в нулевом кадре (т.е. 0.000).
Такой метод использован в некоторых оригинальных моделях беседки.
Статичные частицы могут быть упакованы в
niBsAnimationNode и содержать анимацию движения света, или иную другую.
Статичные частицы, по видимости, будут иметь проблемы при перемещении оных в игре через действие скриптов.
Т.к. появление частиц фиксировано в первом кадре их анимаций, а обновляться ему нечем.
Примечание.
Также, статичные частицы НЕ ПРИНИМАЮТ текстурных эффекты!
Поскольку, частицы в таком режиме, не используют эмиттер, к ним нельзя прикрепить "физическую" поверхность (
NitriShape), что критически необходимо при наложении эффектов.
Примечание.
Либо установить флаг 12 вместо 8, на их контроллере.
Частицы будут созданы и застынут в таком состоянии до следующего посещения ячейки игроком.
Примечание.
Это определяет работу частиц в целом.
Неправильный набор флагов может приводить к остановке появления частиц, или иным проблемам.
Однако, в разных ситуациях могут использоваться различные флаги.
В статичных объектах (например в светильниках) одни флаги, в подвижных - другие.
Но, если
NiBSParticleNode превращена в обычную NiNode, поведение частиц радикально меняется.
То что не работало, может заработать!
Примечание.
Позиция своей ноды, при появлении частиц на свет, всегда игнорируется ими!
Т.е. точка появления определяется только эмиттером.
Кроме случаев размещения частиц в игре через скрипты!
В этом случае, можно увидеть частицы в координатах своих нод, откуда они расползутся по координатам эмиттеров.
Примечание.
Вид частиц на оружии из глаз героя может отличаться от вида от 3-его лица.
Связано с разным положением Weapon Bone в этих ниф файлах.
Xbase_anim и Xbase_Anim.1st.
Примечание.
Обращайте внимание! Что
NiBSParticleNode нужна (в основном) только переносным светильникам!
Если частицы используются в статичных светильниках (статиках, или активаторах), то:
- полезно преобразовывать NiBSParticleNode в обычную ноду!
Это положительно сказывается на стабильности их работы.
Либо, что много правильнее, менять имя корневой ноды с NiBSAnimationNode на NiBSParticleNode.
Можно использовать обычные флаги 32, или 42.
Либо 172 если нужен хвост от частиц.
Примечание.
В файлах существ, можно использовать, как обычные niNode, так и NiBSParticleNode.
Некоторые тесты показали положительное воздействие этой ноды на создание шлейфа частиц за существом при движении.
Переключение на niNode приводило к более жесткой фиксации частиц с телом.
Однако, это предотвращало исчезновения частиц в некоторых случаях.
Примечание.
- 96ой флаг на ноде частиц в моделях оружии и 10 флаг на их эмиттере, приводил к появлению частиц в мир, где они так и оставались.
Т.е. в руках ГГ пусто, но при этом частицы как-то реагируют на движения игрока оставаясь в том месте где появились.
Т.е. после извлечения оружия частицы исправно появлялись, а затем оставались висеть на том месте, где ГГ извлек оружие.
При этом реагируя на движение оного!
Примечание.
На частицы можно, ограниченно, накинуть скин с одним (произвольно выбранным) объектом в сцене, в качестве кости.
И указав, в настройках скиндаты, вес для одного вертекса.
Этого достаточно для использования частиц в моделях брони и пр. объектах со скином.
Также следует задать частицам правильное имя (Chest 1, Groin 2 и пр).
Однако, это лишь даст возможность их увидеть в файле.
Т.к. оные будут лежать в ногах "скелета" и не захотят появляется в координатах нужной кости.
Возможно, бспаррай контроллер, позволяет добиться немного больших результатов.
Частично позволяя придавая частицам некоторые "позы"
Но получать нормальную связанную реакцию на изменения положений сетки или костей, в файлах брони - не получается(
Т.е. добавление скининга к частицам возможно, но практический пользы от этого не так много, как хотелось бы.
Примечание.
Связка (эмиттер и нода с частицами) позволяет получать дополнительные эффекты анимаций.
Например, если
niViscontroller находится на родительской ноде частиц, или на самих частицах, то в игре оные будут исчезать мгновенно.
Но если niViscontroller находится на эмиттере, это позволит частицам исчезать плавно.
Т.е. естественно завершив свой жизненный цикл.
Примечание (по эмиттеру и плавному исчезновению частиц)
Существует побочный эффект.
Если такой метод использован в моделях существ, существует вероятность зависания частиц после кончины существа.
Т.е. базовая анимация уже остановлена, а частицы еще не закончили свой цикл - в результате, они застывают в воздухе.
См. костяного лорда, или поднявшегося спящего.
Может быть исправлено за счет увеличения времени анимации кончины, так чтобы частицы успели завершить свой цикл.
Либо следует поместить в сцену еще один контролер невидимости, который скроет все частицы и прочие объекты наверняка!
Пускай и без возможности плавного исчезновения оных.
Однако, есть мнение, что зависание связано не со временем, а с методом обработки частиц!
Т.е. если существо погибает вне поля зрения камеры.
То при повороте камеры обратно, в момент проигрывания половины анимации кончины, можно видеть момент появления частиц!
Которые затем зависают, не успевая полностью проиграть свою анимацию, до полной остановки оной.
Однозначно стабильного метода решения не замечалось.
Есть сведение о 128 флаге (на NiBSParticleNode) который может несколько улучшить ситуацию...
Примечание
Также, через разнесение эмиттера и частиц, можно получить опосредованную анимацию дефлектора.
Т.е. анимации движения добавляются на эмиттер частиц, тогда как дефлектор находится в другом месте сцены ниф файла.
При повороте (перемещении) эмиттера, частицы соприкоснутся с дефлектором и поменяют свою траекторию.
Пламя будет искажаться при контакте с поверхностью.
Примечание.
Как правило, частицы всегда должны иметь свойства альфы и
z-буффер, который предохраняет их от "строба".
- 13, 4621, 4609 для светящихся в темноте частиц.
- 237, 4845 - обычно используется для дыма.
Могут быть и иные значения.
Свойств альфы может не быть, но вот z-буффер должен быть всегда кроме самых "радикальных" случаев.
Примечание.
Нифскоп не умеет правильно правильно отображаться анимации частиц!
Нифскоп способен, относительно верно, показать только первый фрейм подобной сложной анимации!
Правильно показывает анимацию только SceneViewer, однако он не всегда может открыть файлы nif Морровинда.
Т.е. файлы с уникальными объектами беседки не могут быть открыты, поскольку SceneViewer не понимает их!
Т.е. можно собирать сложный лабиринт из дефлекторов, гравитаций и бомб - а затем пускать по нему поток частиц.
На одни niParticles можно назначить несколько сил.
Точное число, не выяснялось, но оно более 10, это точно (С)
Примечание.
Отмечалось, что частицы нестабильно работают будучи добавлены в шлемы.
Нарушается размер и позиция.
Впрочем в МСП 2.4 это было исправлено.
Возможно, дело было, в воздействии изменения размера скелета НПС (и ГГ) в настройках Расы.
Т.е. измененный масштаб костей влияет на все объекты как-то с этим связанные.
Частицы же, крайне чувствительны к подобным изменениям!
Для надежности, имеет смысл добавлять пустой КейФреймКонтроллер фиксирующий размер эмиттера.
Это помогает в некоторых случаях.
Примечание.
Как было отмечено выше, 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 может работать ТОЛЬКО на корневой ноде ниф файла, взаимодействуя только с существами и НПСами.
