Тёмная тема
Mira
А если в BioIK параметр Elites поставить =1? Тогда будет всего один дополнительный поток.
Но вообще даже мои результаты так себе. В демах, где используется мало костей ― 1 мс, где много ― 4. 4 мс на персонажа ― это игра должна быть исключительно про одного этого персонажа во весь экран.
Смотрел внутренности ― чувак таки заморачивался, оптимизировал, раскладывал операции с Vector3 на операции с отдельными компонентами (так быстрее). Видать, алгоритм всё-таки слишком тяжёлый.
alexzzzz
видимо да.
можно бы было заманьячить и переписать это на нативный код, но полученный результат должен в десятки раз выше, иначе нет смысла.
я сомневаюсь что это будет работать быстрее раз в 30 при таком обилии вычислений. так что пусть пока лежит, вдруг автар заморочится и сделает на каком нибудь Burst.
вероятность чего ничтожна)))
Оцениваю ускорение от перевода уже оптимизированного до упора кода на Burst/Unity.Mathematics в два-три раза максимум. От перевода на джобы ускорения не ожидаю, разве что до этого многопоточность вообще не использовалась или была организована криво с большими накладными расходами.
PS
Вообще, идею, что переписывание в нативный код ускоряет в десятки раз, не поддерживаю. Основное ускорение даёт SIMD, если компилятор догадывается, как его можно с пользой применить. Это бывает не всегда, и Burst/Unity.Mathematics теперь тоже активно умеют в SIMD. А если без SIMD, то в 2 раза быстрее будет врядли, в 1,5 раза ― возможно, но может и вообще не быть быстрее, если скорость упирается в скорость памяти или оптимизировать уже просто нечего.
PPS
Возможно, автор и заморочится, потому что один раз уже переписывал. Сейчас вроде версия BioIK 2.0. Но бёрст пока в превью. Вряд ли стоит его использовать в ассетах для магазина до официального релиза.
alexzzzz
> Вообще, идею, что переписывание в нативный код ускоряет в десятки раз, не
> поддерживаю.
у меня ускоряло, в редакторе так аж в десятки раз =/ я переписал куллинг из SECTR на нативный код, оно дало дохренища больше резерва, говорил же что при 40 порталах отсечение становится тяжелее чем рисовать втупую в оригинале.
юзал SIMD ага.
с этим ассетом экспериментировать не буду
Burst если сделают работающим без джобов, то я заморочусь наверно, если гдето прижмет. пока тяжелых вычислений мне не надо, двигать 1000 космолетов я не буду)
а партикли в юнити итак функциональные и ускоренные всем чем надо.
KolyaL
Если у тебя нет решения - на кой ляд писать пространный "совет" который, по факту, не содержит ничего кроме: "решение надо найти" ?
Метод перебора через исключение я как-то и без тебя знаю. Пишу в тему не для того чтобы читать бесполезные банальности.
Т.к. удобоваримого решения проблемы https://gamedev.ru/code/forum/?id=203308&page=115#m1716 не было найдено, то пришлось мигрировать на Unity 2018.3.0f2.
С 2017 достигнуто следующее:
При сборке через Mono - ошибка видоизменяется и начинает проявляться в другом месте но все еще крашит приложение.
При сборке через IL2CPP - приложение работает (ошибки волшебным образом исчезают) но нет адекватной отладочной информации в логах.
Т.е. ошибки не в коде и не в ресурсах.
В Unity 2018.3.0f2 - проект портировался на удивление ровно и без ошибок. Все работает в любом варианте сборки.
НО...
Unity 2018.3.0f2 никак не может полноценно интегрироваться с Visual Studio 2013. С версией 2017.1.0f3 - все было замечательно.
С Unity 2018.3.0f2 - при попытке открыть скрипт из UI юньки - открывается стандартный виндосовский блокнот + ПУСТАЯ VS. И под каждую попытку открытия скрипта - открывается новый экземпляр пустой VS.
Если руками открыть в VS solution проекта - все вроде работает, но в логи Юнити сыплется:
Ну и никуда не исчезает беда с открытием пустых VS и блокнотов при открытии скриптов через Юнити.
У кого есть опыт интеграции VS 2013 c Unity 2018.3 ?
Homeship
Хз у меня на 2013 уже более ранними сборками начались проблемы, которые не решились полностью. Решил обновить студию.
Vstu пробовал удалить(вместе с папками) и обновить?
Mira
> Vstu пробовал удалить(вместе с папками) и обновить?
Да, пробовал.
Штука в том что в этот же момент стоит Юнька 2017.1.0f3 и с той же студией через те же VStu - прекрасно работает.(( Но не может собрать рабочий билд под Андроид.((
VSTU находится в незавидном положении. Ему надо поддерживать и последние версии Unity и последние версии VS. В Unity в последние пару лет в коде, отвечающем за компиляцию и интеграцию с редакторами, постоянно что-то происходит. В мире NET последние несколько лет тоже горячие, VS тоже меняется.
- Использовать новую версию VSTU со старой Unity вроде можно.
- Использовать старую версию VSTU с новой версией Unity можно вряд ли. Что-нибудь не будет работать, может даже всё.
Для Студии 2013 предлагается VSTU версии 2.3 двухлетней давности (времена Unity 5.x). Современная версия ― 3.9.
Так, стоп. 2017.1, 2018.3… а как насчёт 2017.4 LTS? Она поддерживается и будет поддерживаться ещё год, до выхода 2019.4 LTS. Новых фич там нет, то багофиксы и изменения для поддержки разных платформ есть.
alexzzzz
> - Использовать новую версию VSTU со старой Unity вроде можно
Грабли тут в том, что новой версии VSTU в отдельном субъекте как бы и нет. Она идет сразу встроенная в VS 2017.
Т.е. мелкомягкие сразу вынуждают ставить VS 2017 Community чтобы апдейтнуть VSTU, что лишает смысла сохранение предыдущей версии VS.
alexzzzz
> а как насчёт 2017.4 LTS?
Риски что она также не решает изначальную проблему (Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 5381 (UnityMain)) - слишком высоки, т.к. ни в одном патче, этот момент не решался 100%. Кому-то помогает, кому-то - нет. Беда где-то на уровне совпадения: компилятор+код+пользовательское железо.
Изменение одного из компонентов - повышает вероятность удачной сборки.
Далее...
пользовательское железо - вне нашего влияния.
Код - не всегда есть возможность отказаться от определенного решения \ реализации \ технологии. Да и просто - локализовать проблему.
Люди меняли свой код - ошибка просто перемещалась в "другое место", но не исчезала.
Компилятор - насколько понимаю в любой версии 2017 - компилятор тот же самый, а вот в 2018 они вроде на другой перешли. Т.е. переход на другую версию U2017 - дает низкие шансы на изменение ситуации.
Потому я решил - переходить сразу на более-менее последнюю.
По текущим итогам:
1. Проект портировался на 2018 - без проблем (помню с какими ужасами данная процедура выполнялась раньше - отваливалось полпроекта)
2. U2018 - собирает с любым backend - рабочую сборку.
3. "Официальная" установка VS 2017 - нормально интегрировалась с U2018.
4. Для U2018 пришлось обновить Android SDK, "помер" привычный Android-монитор. Отовсюду (включая Android Studio, adb и саму Юнити) перестали видеться через USB Android-устройства (попробую переставить соответствующий драйвер) и локально стоящий эмулятор (но его хотя бы adb видит).
Т.е. для восстановления полноценной среды разработки еще не все ладно, будем посмотреть как оно дальше "полетит".
блин толи в юнити чето поменяли, толи просто у меня стали персонажи "увесистее".
работать стало с ними очень не комфортно, по несколько минут смена типа рига , импорт, перетаскивание из папки в папку, сохранение и все такое.
если сделать enforce T - pose после того как поставишь лицо на место (даз по умолчанию импортируется криво, глаза и челюсть не на местах) то ваще падает с крашем.
расширение памяти с 8гб до 16 может решить эту проблему или это проблема самого движка? никто не использовал скиннед меши большого объема? как решали проблему?
походу не поможет. чуваки пишут что тоже проблемы с использованием больших FBX , и в юнити не возможно с ними оперировать. вот так универсальный движок
https://answers.unity.com/questions/1386653/inspector-extremely-s… ly-anima.html
надо то только настроить в юнити модель и перевести в свой формат, но даже на такие простые маневры едва ли не час надо.
приходится нажимать кнопку или кликнуть по объекту и потом несколько минут ждать пока юнити чето соображает)
Все знали, что Mathf.Sign(0) возвращает единицу?
public static float Sign(float f) { return ( double) f < 0.0 ? -1f : 1f; }
С одной стороны, поведение задокументировано; с другой стороны, как-то это неправильно и неожиданно.
Новый math.sign() работает уже без сюрпризов, ноль даёт ноль.
alexzzzz
> Все знали, что Mathf.Sign(0) возвращает единицу?
Норкоманы блин.
можно ли этот код сделать быстрее?
чтото получение значений из трансформов какое то тяжеловатое
с глобальными координатами пишут что еще тяжелее
Transform[] childs ........ for (int i = 0; i < childs.Length; i++) { if ( childs[i] == tfbase) { TempTransform.LocalPosition = Vector3.zero; TempTransform.LocalRotation = Quaternion.identity; TempTransform.LocalScale = Vector3.one; //TempTransform.hashName = hascodes[childs[i]]; tout[i] = TempTransform; } else { TempTransform.LocalPosition = childs[i].localPosition; TempTransform.LocalRotation = childs[i].localRotation; TempTransform.LocalScale = childs[i].localScale; //TempTransform.hashName = hascodes[childs[i]]; tout[i] = TempTransform; } }