Оптимизируем Boid'ов на Unity

[HomoLuden]

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

[HomoLuden]

Не успел дописать про пулл…
Если завести синглтон или просто статический менеджер боидов с пуллом инстансов, то не нужен будет код, вида:

boids = Physics.OverlapSphere(tr.position, cohesionRadius, boidsLayer.value);

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

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

[BasmanovDaniil]

Если пробегаться и сравнивать каждого с каждым, то получаем сложность O(n^2) и потолок в пару сотен боидов. Внутри Physics.OverlapSphere скрывается какая-то оптимизированная магия от Nvidia, которая делит пространство на кусочки и ограничивает область поиска.

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

[HomoLuden]

Подозреваю, что работать эффективно та магия будет только на железе от Nvidia. Тогда потеряете в переносимости. Как вариант, сделать похожую оптимизацию в логике. Разбить сферу спавна на конечное число зон, разместить по случайным зонам нужное число боидов и статически назначить нужное количество соседей (ну или один раз по радиусу определить). Жестко карать боидов за излишнее смещение боида относительно исходного центра или лидера стаи.

ПС: извините… Недочитал каммент с мобилы. Вы предложили то же.

[BasmanovDaniil]

У статических соседей проблема оказалась в том, что они статические :) Становится заметно, что все боиды передвигаются кучками. Я пробовал разбавлять иерархию одиночными боидами, но всё равно каша получалась с комочками. По идее, если иногда случайным разбивать группы на одиночек, а потом собирать в новые группы, то будет смотреться лучше. Но как я уже говрил, получается слишком много параметров для настройки, и я забросил этот вариант. Проще на GPU симуляцию делать, десятки тысяч боидов всё равно мало где нужны.

[HomoLuden]

В принципе согласен — если надо облако бацилл, то лучше несколько систем частиц использовать. Так?

[BasmanovDaniil]

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

[Renzo]

Увидев первую картинку, сразу почему-то появились ассоциации с этой статьей)

[BasmanovDaniil]

Действительно, к чему бы это)

[HomoLuden]

Надо добавить опрос «Обращаешь ли ты внимание на автора статьи, Хабраюзер?».
Третьим вариантом поставить: «Распознаю по тексту. Пока распознавалка дает два варианта: Ализар / неАлизар»

[lexxpavlov]

> Проблема решается отделением модели от коллайдера в иерархии
То есть навесить коллайдер не на модельку птички, а на её родительский (пустой?) объект, который не будет вращаться, но будет перемещаться, так?
Но тогда вращение нужно делать на внутренний объект с моделью, а перемещение — на внешний с коллайдером и внутренним. Или я что-то не понял?
Покажите, пожалуйста, скриншот окна иерархии, чтобы было понятнее.

[BasmanovDaniil]

Прошу прощения за долгий ответ. Да, коллайдер в родителе, вращаемая модель внутри. Перемещение и приложение сил отдельно, визуализация вращения отдельно.

[TheShock]

Transform и GetComponent

Я краем уха слышал, что в пятом Юнити уже заоптимизировали этот кейс и можно смело его использовать. Нет?

[BasmanovDaniil]

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