Fixed Joint
Компонент Fixed Joints (Неподвижное соединение) ограничивает движение определенного объекта, связывая его с другим объектом. Этот процесс похож на Parenting (определение текущего объекта как “дочерний” по отношению к другому, “родительскому”, объекту), но реализован с помощью физики, а не иерархии компонентов Transform. Чаще всего этот компонент используется в случае, если в определенный момент времени может потребоваться разъединить два объекта, или наоборот, соединить два объекта без необходимости изменения иерархии.
Свойства
| Свойство: | Функция: |
|---|---|
| Connected Body | Необязательная ссылка на другой объект с Rigidbody, к которому присоединяется текущий объект. Если поле оставить пустым, объект присоединяется к заданной точке в пространстве. |
| Break Force | Сила, которую надо применить к соединению, чтобы сломать его. |
| Break Torque | Крутящий момент, который надо применить к соединению, чтобы сломать его. |
| Enable Collision | Если включено, то включаются коллизии между телами связанными соединением. |
| Enable Preprocessing | Disabling preprocessing helps to stabilize impossible-to-fulfil configurations. |
Детали
При создании игр иногда возникают случаи, когда требуется, чтобы объекты двигались вместе (временно или постоянно). Компоненты Fixed Joint позволяют упростить реализацию подобных ситуаций, поскольку вам не приходится менять положение объекта в иерархии с помощью скриптов. Минус подобного решения в том, что вам придется добавлять компоненты Rigidbodies на объекты, которые требуется соединить с помощью Fixed Joint.
Например, с помощью этого компонента можно реализовать “липкую гранату”. Для этого нужно написать скрипт, позволяющий определить столкновение с другим объектом, имеющим компонент Rigidbody (например врагом), после чего создать Fixed Joint, который присоединит гранату к этому Rigidbody, заставляя ее оставаться “прилипшей”, даже если враг будет двигаться.
Разрываемые соединения
Вы можете использовать свойства Break Force и Break Torque, чтобы установить лимиты силы по отношению к соединению. Если они меньше бесконечности, то Fixed Joint будет разрушен и соединение больше не будет поддаваться ограничениям.
Советы
- Для правильной работы компонента Fixed Joint не обязательно указывать свойство Connected Body.
- Для работы компонентов Fixed Joint требуется компонент Rigidbody.
Соединить кривой два объекта в Unity3D
Хочу поделиться небольшим фрагментом кода, который позволяет соединить два игровых объекта в трехмерном пространстве Unity3D без установки плагина. В моем случае это понадобилось для обозначения связи между двумя притягивающимися телами.
Если вдаваться в теорию, то в данном случае строится кривая Безье по трем опорным точкам по осям X и Y, а ось Z рассчитывается линейно. При необходимости можно довольно легко ввести четвертую и сделать изгиб более интересным. Очень рекомендую эту статью, всё предельно доступно.
Examples/curves.cs at main · Paupertony/Examples
Contribute to Paupertony/Examples development by creating an account on GitHub.
Как это быстро применить:
1) Потребуется некая (например, логическая) переменная. Когда нам надо показывать кривую, делаем ее true. В методе Update вызываем Curves, если эта переменная true.
2) У меня этот скрипт висит на подвижном объекте, поэтому мы указываем только второй объект
3) В примере нет удаления уже не нужной кривой, так как это зависит от ваших потребностей. Мне нужно, чтобы кривая удалялась, когда отпускают кнопку, так что на это событие и стоит удаление
4) В примере кривая строится из 10 отрезков. Это связано с тем, что игра делается под браузеры, и, соответственно, я экономлю на всём. Чтобы увеличить плавность, надо увеличить количество отрезков
Как итог: я не гарантирую, что это лучшее и идеально написанное решение, но если вам нужно, оно решит эту простую задачу. Всем хорошего дня 🙂
Объединение объектов
Есть большое количество одинаковых статичных объектов, возможно ли их объединить, чтобы они стали как один объект? Не закидать их все в пустышку, а именно объединить, или может есть еще способы оптимизации в таких случаях?
94731 / 64177 / 26122
Регистрация: 12.04.2006
Сообщений: 116,782
Ответы с готовыми решениями:
Объединение объектов в один
Здравствуйте! У меня есть объекты "Плитка" с коллайдерами (одинаковые модельки из которых.
В общем как заменить в подборе объектов и так чтобы не сохранял в массив объектов а в лист? с#
Вот код.public static RaycastHit rch; int _my_podbor_switch; public GameObject.
Объединение объектов
суть в том что объект разделяется при бинаризации, на некоторые части, можно ли их как нибудь.
Объединение объектов в массив
Возникла проблемка во время работы над лабораторной(програма-тестер): чтобы нормально выводились.
295 / 244 / 128
Регистрация: 24.12.2014
Сообщений: 708
Сообщение от Ironhide33 
возможно ли их объединить, чтобы они стали как один объект?
Можно написать скрипт для «объединения», но легче себе голову разбить, чем нормально написать такую фичу. Обычно в таких случаях объект импортируют уже «объединённым», чтобы не париться потом.
Unity3d, много кубиков, слияние мешей, производительность
Приветствую господа!
Нужен совет бывалых.
Нынче пробую мастерить для проэкта генератор локаций. Пока пробую на манер «майнкрафта» из кубов. Получается интересно, произвольные пещерки и т.п. Однако такой подход при росте количества объектов приведет к снижению производительности. При текущем размере локации в редакторе уже проседает до 30 фпс, хотя в билде пока всё нормально.
А вот хотелось бы расширить локацию хотя бы в 2 раза. Смотрел на ютюбах как люди объединяют меши и материалы. Правда всё на английском, так что нюансы проходят мимо меня.
Собственно вопрос: кто-нибудь уже делал такие смешивания и как влияет на производительность?
Или резонее печатать объекты в редакторе и уже расставлять готовые?
- Misanthrope
- Постоялец
#1
14:17, 22 фев 2019
обычно в таких случаях советуют не морочить голову и взять юнити,
но тут всё намного хуже, юнити уже взят а лыжи всё равно не едут.
- DemiosFantasimo
- Участник
#2
14:26, 22 фев 2019
Misanthrope
а можно без «потоков сознания» и что нибудь по делу?
#3
14:33, 22 фев 2019
Объединять меши это хорошо, но не нужно. Достаточно просто оперировать строго определённым количеством объектов на сцене через матрицу.
- DemiosFantasimo
- Участник
#4
14:45, 22 фев 2019
sledo
> Объединять меши это хорошо, но не нужно. Достаточно просто оперировать строго
> определённым количеством объектов на сцене через матрицу.
Так сказать рендерить в области видимости. Такая мысль была. И матрица собственно есть. Просто по задумке на локации должны происходить некоторые события типо баталий нпс. Мобы здесь выходят за пределы функциональности скелетов майнкрафта и часть их сохраняет параметры полученые на локации в дальнейшем. Генерация событий за пределами видимости тоже мягко говоря озадачит не меньше(
#5
15:16, 22 фев 2019
Не видимости, а границ мира. Ваша матрица это и есть мир. Уйти от того что в дальнем углу какой то НПС взаимодействует с самой крайней ячейкой и не обрабатывать эту ячейку, не получится.
А вот не обрабатывать весь матричный массив, а только то с чем идёт взаимодействие, можно и нужно.
Просто вы используете не верный подход. В данном случае вам нужно идти не от начала, а от конца, ибо концов меньше чем начал.
- DemiosFantasimo
- Участник
#6
15:18, 22 фев 2019
sledo
Спасибо. Принял.
#7
18:18, 22 фев 2019
непонятны детали и нюансы
может у вас там каждый кубик с rigidbody
обрабатывать невидимые и далекие объекты можно со своей периодичностью, то есть не каждый кадр, а реже
объединение материалов хорошо, меньше дроуколов может стать, а может и не стать
но это судя по всему не ваш случай, у вас материалов штуки четыре на весь мир (нет, пять), так что они фпс просаживать никак до 30-ки не могут
на редактор юнити по производительности, разумеется, ориентироваться не стоит, профайлить нужно именно билд
для далеких объектов неплохо бывает ещё сделать какие-то лоды, если геометрия сшивается «на лету», то лоды скорее всего придется костылить свои а не родные. вплоть до того, что совсем далекие объекты вообще можно отрендерить в скайбокс с очень редкой периодичностью в зависимости от максимальной скорости передвижения персонажа, чтобы рывков не было видно
ведь дальний план очень незначительно меняется при нормальном передвижении персонажа
физику из коробки симулировать с миром в мильён объектов тоже не получится, придется костылить свою надстройку для обработки далеких от игрока областей, с редкой периодичностью обновления
upd:
а ещё.. проверьте , чтобы у вас материалы не клонировались. если дёрнуть Renderer.material то создаются экземпляры материалов и тогда да, это уже существенно влияет в вашем случае. если дергать или назначать sharedMaterial то ничего страшного
- DemiosFantasimo
- Участник
#8
19:59, 22 фев 2019
Chupakaber
Спасибо, помогли косвенно, но все равно интересно почитать о том что бывает.
Проблема оказалась действительно в rigibody. Только оно висело не на самой модели, а на родительском объекте, сразу не увидел. Снял и сразу даже в редакторе фпс вернулся к 60-70))
#9
23:23, 22 фев 2019
DemiosFantasimo
> Смотрел на ютюбах как люди объединяют меши и материалы
Просто поставить у статичных мешей «is staic» и включить в настройках static и dynamic батчинг.
В шейдере можно заюзать instancing.
Настроить area occlusion culling.
В принципе этого достаточно должно быть, что бы получить явно выше 60-70 фпс в вашей сцене, даже на ультра бюджетном дерьме.
sledo
> Объединять меши это хорошо, но не нужно.
Чего?
sledo
> Достаточно просто оперировать строго определённым количеством объектов на сцене
> через матрицу.
Чего?
Юнити отбрасывает все объекты вне зоны фруструма и батчит только видимые объекты.
Если на сцене 100 кубов и видно только 10, то юнити сбатчит 10 кубов в 1 меш и 1 вызов отрисовки.
Зачем костыли с матрицами? Батчить разные материалы?
Если да, то оно того не стоит, учитывая что там от силы пара материалов. Экономия на спичках.
Или про какую матрицу идёт речь?
DemiosFantasimo
> Так сказать рендерить в области видимости. Такая мысль была. И матрица
> собственно есть. Просто по задумке на локации должны происходить некоторые
> события типо баталий нпс. Мобы здесь выходят за пределы функциональности
> скелетов майнкрафта и часть их сохраняет параметры полученые на локации в
> дальнейшем. Генерация событий за пределами видимости тоже мягко говоря озадачит
> не меньше(
Откройте профайлер и посмотрите что рендерит камера. Там и так рендерится только то что в области видимости.
Для skinned mesh можно настроить отдельно, рендерить или отбрасывать вне области фруструма.
#10
0:02, 23 фев 2019
Kripto289
Матрица это не костыли, а в данном случае основа мира. Или вы предлагаете создать на сцене пару милионов объектов и работать с ними? Я думаю нет. Для того что бы можно было с ними работать и нужна матрица. Например в виде трехмерного массива.
Причем сам индекс массива можно использовать как координаты ячейки в пространстве, а хранилище для хранения данных. Таким образом, можно создавать миры ограниченные только объемом памяти и в случае с массивами, этот мир можно считать практически безграничным.
Для того что бы обработка массива не занимала лет сто и нужно идти не от того что произошло в каждой ячейке, а от того, кто в данный момент может взаимодействовать с ячейкой.
В случае с предложенным автором мобом мы имеем ограничение только на их количество в мире, исходя из их занимаемого процессорного времени.
Условно говоря, в идеале взять общую производительность, вычислить производительность ИИ моба, и разделив одно на другое можно получить приблизительно максимальное количество мобов в мире. Даже для среднего ПК, это могут быть тысячи и десятки тысяч уникальных персонажей которые живут отдельной жизнью. Т.е. каждый моб, условно говоря обрабатывает свою ячейку, что намного быстрее чем каждая ячейка обрабатывает весь массив мобов.
Я уж молчу о развитии этого и создания иерархии управления, что то типа урезаной нейроной сети. Там и вовсе будет планета Земля.
Насколько я понял, автор именно этого и хочет добиться — огромного живого мира, потому и пошел по пути генерации.
В идеале конечно тут использовать низкоуровневые языки. Тогда даже Дворфы покажутся детской поделкой.
#11
1:47, 23 фев 2019
sledo
> Матрица это не костыли, а в данном случае основа мира.
В геймдеве обычно матрицами принято называть матрицы преобразования, а не вот это, ну да ладно.
sledo
> Или вы предлагаете создать на сцене пару милионов объектов и работать с ними?
Что значит «работать с ними»?
В контексте юнити, я могу создать хоть миллион кубов и тысячи персонажей, которые могут взаимодействовать с этими кубами и друг с другом, не нагружая gpu. Поиск пути работает. Физика и рейкасты работают. Culling невидимых кубов и скин-мешей работает. События работают.
А учитывая что в юнити недавно добавили job system с ecs, то многопоточная обработка стала ещё эффективнее.
Не то что бы я каждый день создавал клоны майнкрафта, но я не увидел смысла в вышесказанном про обработку матриц.
Что конкретно можно сделать с помощью матриц, чего не сделать штатными средствами юнити?
Бегать/ходить/прыгать/. Кинули рейкаст (например с тайм слайсингом для оптимизации), получили землю и пошли по ней. Ну или заюзали штатный поиск пути.
Копать/добавлять/менять/поджигать/. Кинули рейкаст, получили что надо (позицию, цвет, материалы, и т.д.), добавили/поменяли.
Найти ближайшего юнита/бревно для взаимодействий? Получили через сферический рейкаст и слои то что нужно, хоть врагов, хоть союзников, хоть кусок камня и т.д.
Что там ещё из возможных взаимодействий возможно?
#12
4:36, 23 фев 2019
Kripto289
Однако как все просто. Матрицы, шматрицы. Наклепал ГО в сцену, рейкастом пуляешь куда не попадя и все — мир создан.
Одни гении разработки. Вот только поиграть не во что.
#13
4:59, 23 фев 2019
Я расписываю тонну текста и аргументов и жду обсуждения, а в ответ получаю вот этот высер.
sledo
> Однако как все просто. Матрицы, шматрицы. Наклепал ГО в сцену, рейкастом
> пуляешь куда не попадя и все — мир создан.
> Одни гении разработки. Вот только поиграть не во что.
А по существу что-то будет, кроме унылого вброса? Тут вроде не публика вконтактика для «ололо потролить»
В твои то игры можно поиграть?
- DemiosFantasimo
- Участник
#14
7:08, 23 фев 2019
Kripto289
> Просто поставить у статичных мешей «is staic» и включить в настройках static и
> dynamic батчинг.
Проэту штуку я когда-то читал — забыл.))
Kripto289
> В шейдере можно заюзать instancing.
> Настроить area occlusion culling.
Любопытно — незнал!
Kripto289
> сферический рейкаст
Боже, такую штуку вообще нигде не когда не видел и упоминаний не встречал!))
sledo
> Однако как все просто. Матрицы, шматрицы. Наклепал ГО в сцену, рейкастом
> пуляешь куда не попадя и все — мир создан.
Ну собственно в жизни то так и есть. Как правило дело не в том что сцена «наклепана», а в том что на ней делать игроку.