NiSwitchNode примечания

 

 

Мгновенно сменяя один вложенный объект на другой.

Что положительно сказывается, как на времени создания моделей, так и на ФПС.

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

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

Можно создавать глобальный скрипт работающий через МВСЕ 2.0 и переключающий сразу все объекты определенного типа.

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

 

 

По всем параметрам, кроме строки "Unknown Int 1" - обычная нода.

 

Строка "Unknown Int 1" определяет отображаемый по умолчанию объект.

Т.е. номер в списке вложенного в эту ноду объекта.

При использовании МВСЕ, в игре, можно изменять это значение.

Таким образом переключая отображение объектов.

 

Правка Nif.xml файла позволяет сменить "Unknown Int 1" на более понятное название "Switch State" или "Active Index".

 

В отличие от LodNode для смены состояний используется, так сказать, "механическая" часть движка, та, что отвечает за взаимодействие игрока с миром.

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

 

Поддержка экспорта NiSwitchNode в 3д МАХ добавлена в модуль экспорта начиная с 10.0 версии..

Gamebryo 1.1 и выше.

 

Как писал уважаемый Хрнчмд, niSwitchNode не сохраняет своего положения после смены игроком ячейки и, не прописывается в сохранение.

 

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

См. модель slaughterfisheggcluster01.nif например.

Остается лишь пожалеть, что в 2002 году беседка не сочла нужным нормально задействовать этот объект движка.

ГрафикХербализм мог бы существовать много раньше и много проще.

 

Использование флага 32 на этой ноже, может давать дополнительные возможности.

См. переписку в конце страницы.

 

Рекомендуется установка флагов приводящих к установке значения UpdateOnlyActive = true!

Т.е. обновление состояний будет происходить только при выполнении определенных условий.

И не будет постоянно мониториться.

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

См. об этом внизу страницы, в разделе аглицкой справки.

 

NiSwitchNode может содержать больше двух вложенных объектов.

Т.е. нажатие на объект в игре будет приводить к последовательной смене отображения вложенных объектов.

 

Упаковка СвитчНоды в Анимационную ноду, равно, как и добавление во вложенные узлы анимационных нод - результата не дало.

Равно как и смена флагов. 32, 42, 8, 10...

Т.е. без МВСЕ 2.Х в чистом МВ не срабатывает.

 

По состоянию на 02 2020 этот узел активно используется в некоторых МВСЕ плагинах.

На 2022 год, использование стало более активным и этот узел появляется все в большем кол-ве моделей.

 

- стринг маркера

- пустая РК

- собственно свитчнода определяющая смену состояний объекта через действие ЛУА.

- Лоды

- и шейп маркера

Модель используется в плагине GlowBugs от MelchorDark.

В качестве примера добавлена также в заметки.

 

Речь в основном идет о пользе флага 32.

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

Верно и для niLodNode.

 

I think we should probably start using this flag in any NiSwitchNode/NiLODNode

flag 32

 

It is what updates the positions/bounds/etc for the node and all its descendants. For animated things it is usually called every frame. For other stuff it only needs to be called if they are modified.

With this flag it should only call update on the currently active switch index/LOD level, which can help performance if the hidden parts are animated.

in theory at least

 

We put a lot of particle effects behind LODnodes.

Would those still benefit from this since they're animated?

I guess it shouldn't hurt as a best practice in any case.

 

'update only active' flag... maybe if I had set this then animations from non-active children wouldnt have been an issue?

nifskope defaults it to 0, so I had probably not set it to 1... if thats what the unknown is

 

________________________________________________

Unknown Int 1 = Index of active child

NiSwitchNode class

 

    // flags

    enum

    {

        UPDATE_ONLY_ACTIVE_CHILD_MASK   = 0x0001

    };

 

so its always set?

 

Flags is 0 in that screenshot

It's a bitfield remember

 

the normal flags, set to 1==Hidden right

so I was thinking maybe this other int is the flag mentioned in that snippet

unless NiSwitchNode is overriding the default NiNode Flag handling?

 

I'm reading the code

Ok, it's one of those weird CPP macro bullshit things.

It declares a flags member with a macro

And every flags member variable has the same name in derived classes.

But of course that bullshit is allowed in C++.

 

lol

i tried setting the flag to 1 on the SwitchNode, but it just makes the entire thing invisible, same as Flag==1 would behave on NiNode

you are right about unknown == activeIndex

confirmed ingame

no idea how to access the update-only-active-child part

 

urrrgh

There's a subclass of NiSwitchNode called NiFltAnimationNode

no docs

 

Flt for Float?

 

Filter?

I'm reading the update function.

 

no idea, no info about it in nifksope src

 

Ok, for NiSwitchNode flags == 32 has some extra meaning. Try it.

 

k

seems to make my my index0 child invisible

lol

strange kind of hidden too.. i can still target it

i have index0 unanimated version, index1 animated

and hotkey bound to switch between them

with flag 32, if is switch back to index0 it is now invisible but sitll targettable

thats kinda cool

so it is doing something

 

flags 32 = "m_bUpdateOnlyActive"

should show up in console SSG

I guess the problem is the mesh doesn't get loaded initially

 

oh i didnt even think to check SSG for flag names

 

The more you know

 

do you know if the ssg command needs to be refresh to update?

 

It doesn't auto update.

That would cause instant lock up because too much changes per frame.

 

:thumbsup:

 

@Greatness7  or @Melchior Dahrk could you please explain switchnodes to me?

 

- Do I need a "NiZBufferProperty", whatever that is?

- Can NiSwitchNodes have more than 2 switch states?

- Do I just put whatever shit inside the switchNodes that I want to toggle?

- Does it work with particles etc?

- Any Gotchas I should know about?

 

1. no

2. yes

3. assign different states as children, and set .switchIndex to the index of the child you want to be visible

4. probably

5. none come to mind

 

looks like switchNode.switchIndex is 0 based indexed based on the order shown in the children field?

Thanks

Oh and it doesn't persist over saves or cell loads right?

 

changing cell does not unload a scene node immediately

but it wont persist through load/save etc

it may persist through cellchange sometimes, but dont rely on it

 

You check it based on time in GitD just because it's based on time of day right

So I just need to do loaded, cellChanged, and when my campfire actually gets placed etc

 

dunno i didnt work on gitd

 

Oh that wasn't you?

 

the example in graphic herbalism is pretty simple tho

nah gitd was null

 

lol whoops

Alright well I think I have everything I need

 

the trick we discovered while working on this is pretty hype. It is obvious in hindsight, but this was the first time I noticed how useful it can be. You can put controllers under NiSwitchNodes/NiLODNode/etc, and have them target some other arbitrary object in the scene graph. This way you can have multiple controllers that all target the same object, and you control which one is active by setting the active child on the switch node. (Or you let LOD node automatically control which is active)

we can use this technique to totally replicate the way .kf files work, without having to combine every single thing into one single giant animation.

you just toggle a switch to swap between animation sets if only todd knew..

 

So could we use this for all new animations?

Does it need code to accompany it for the switches?

 

our bugs logic all works just from this nif feature, not even any lua magic! The only lua (mwse 2.0 on LUA) is to enable picking individual parts.

in our case the LODNodes automatically handle the switching.

If you use NiSwitchNode you would need lau to control it, but still super powerful

 

 

 

Set and retrieve the "update only active child" flag. 

If this flag is set, then Update passes will only update the active child instead of all children.  Setting this flag to true (the default) can increase application performance significantly.  If the active child changes between the Update and rendering of a NiSwitchNode, then the newly activated child of the NiSwitchNode will be updated immediately before being rendered.  This situation happens, for example, when an LOD switch occurs, when using NiLODNode, a class derived from NiSwitchNode.

 

Fixed NiSwitchNode bug. If you detach the active child, the switch node will set the active child index to -1 (no child active)