Войти
ПрограммированиеФорумОбщее

Unity (проблемы, решения, перспективы) (117 стр)

Страницы: 1116 117 118 119121 Следующая »
#1740
15:31, 24 дек. 2018

Mira
А если в BioIK параметр Elites поставить =1? Тогда будет всего один дополнительный поток.

Но вообще даже мои результаты так себе. В демах, где используется мало костей ― 1 мс, где много ― 4. 4 мс на персонажа ― это игра должна быть исключительно про одного этого персонажа во весь экран.

Смотрел внутренности ― чувак таки заморачивался, оптимизировал, раскладывал операции с Vector3 на операции с отдельными компонентами (так быстрее). Видать, алгоритм всё-таки слишком тяжёлый.


#1741
15:52, 24 дек. 2018

alexzzzz
видимо да.
можно бы было заманьячить и переписать это на нативный код, но полученный результат должен в десятки раз выше, иначе нет смысла.
я сомневаюсь что это будет работать быстрее раз в 30 при таком обилии вычислений. так что пусть пока лежит, вдруг автар заморочится и сделает на каком нибудь Burst.
вероятность чего ничтожна)))

#1742
(Правка: 16:42) 16:24, 24 дек. 2018

Оцениваю ускорение от перевода уже оптимизированного до упора кода на Burst/Unity.Mathematics в два-три раза максимум. От перевода на джобы ускорения не ожидаю, разве что до этого многопоточность вообще не использовалась или была организована криво с большими накладными расходами.

PS
Вообще, идею, что переписывание в нативный код ускоряет в десятки раз, не поддерживаю. Основное ускорение даёт SIMD, если компилятор догадывается, как его можно с пользой применить. Это бывает не всегда, и Burst/Unity.Mathematics теперь тоже активно умеют в SIMD. А если без SIMD, то в 2 раза быстрее будет врядли, в 1,5 раза ― возможно, но может и вообще не быть быстрее, если скорость упирается в скорость памяти или оптимизировать уже просто нечего.

PPS
Возможно, автор и заморочится, потому что один раз уже переписывал. Сейчас вроде версия BioIK 2.0. Но бёрст пока в превью. Вряд ли стоит его использовать в ассетах для магазина до официального релиза.

#1743
(Правка: 16:53) 16:49, 24 дек. 2018

alexzzzz
> Вообще, идею, что переписывание в нативный код ускоряет в десятки раз, не
> поддерживаю.
у меня ускоряло, в редакторе так аж в десятки раз =/ я переписал куллинг из SECTR на нативный код, оно дало дохренища больше резерва, говорил же что при 40 порталах отсечение становится тяжелее чем рисовать втупую в оригинале.
юзал SIMD ага.

с этим ассетом экспериментировать не буду

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

#1744
19:08, 24 дек. 2018

KolyaL
Если у тебя нет решения  -  на кой ляд писать пространный "совет" который, по факту, не содержит ничего кроме: "решение надо найти" ?

Метод перебора через исключение я как-то и без тебя знаю.  Пишу в тему не для того чтобы читать бесполезные банальности.

#1745
12:19, 27 дек. 2018

Т.к. удобоваримого решения проблемы 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 ?

#1746
12:24, 27 дек. 2018

Homeship
Хз у меня на 2013 уже более ранними сборками начались проблемы, которые не решились полностью. Решил обновить студию.

Vstu пробовал удалить(вместе с папками) и обновить?

#1747
20:47, 27 дек. 2018

Mira
> Vstu пробовал удалить(вместе с папками) и обновить?

Да, пробовал.
Штука в том что в этот же момент стоит Юнька 2017.1.0f3 и с той же студией через те же VStu - прекрасно работает.(( Но не может собрать рабочий билд под Андроид.((

#1748
21:43, 27 дек. 2018

VSTU находится в незавидном положении. Ему надо поддерживать и последние версии Unity и последние версии VS. В Unity в последние пару лет в коде, отвечающем за компиляцию и интеграцию с редакторами, постоянно что-то происходит. В мире NET последние несколько лет тоже горячие, VS тоже меняется.

- Использовать новую версию VSTU со старой Unity вроде можно.
- Использовать старую версию VSTU с новой версией Unity можно вряд ли. Что-нибудь не будет работать, может даже всё.

Для Студии 2013 предлагается VSTU версии 2.3 двухлетней давности (времена Unity 5.x). Современная версия ― 3.9.

#1749
(Правка: 21:56) 21:55, 27 дек. 2018

Так, стоп. 2017.1, 2018.3… а как насчёт 2017.4 LTS? Она поддерживается и будет поддерживаться ещё год, до выхода 2019.4 LTS. Новых фич там нет, то багофиксы и изменения для поддержки разных платформ есть.

#1750
7:46, 28 дек. 2018

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 видит).

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

#1751
(Правка: 16:07) 11:29, 31 дек. 2018

блин толи в юнити чето поменяли, толи просто у меня стали персонажи "увесистее".
работать стало с ними очень не комфортно, по несколько минут смена типа рига , импорт, перетаскивание из папки в папку, сохранение и все такое.
если сделать enforce T - pose после того как поставишь лицо на место (даз по умолчанию импортируется криво, глаза и челюсть не на местах) то ваще падает с крашем.

расширение памяти с 8гб до 16 может решить эту проблему или это проблема самого движка? никто не использовал скиннед меши большого объема? как решали проблему?

походу не поможет. чуваки пишут что тоже проблемы с использованием больших FBX , и в юнити не возможно с ними оперировать. вот так универсальный движок
https://answers.unity.com/questions/1386653/inspector-extremely-s… ly-anima.html
надо то только настроить в юнити модель и перевести в свой формат, но даже на такие простые маневры едва ли не час надо.
приходится нажимать кнопку или кликнуть по объекту и потом несколько минут ждать пока юнити чето соображает)

#1752
(Правка: 0:40) 0:39, 3 янв. 2019

Все знали, что Mathf.Sign(0) возвращает единицу?

public static float Sign(float f)
{
      return (double) f < 0.0 ? -1f : 1f;
}

С одной стороны, поведение задокументировано; с другой стороны, как-то это неправильно и неожиданно.

Новый math.sign() работает уже без сюрпризов, ноль даёт ноль.

#1753
7:52, 3 янв. 2019

alexzzzz
> Все знали, что Mathf.Sign(0) возвращает единицу?
Норкоманы блин.

#1754
12:46, 7 янв. 2019

можно ли этот код сделать быстрее?
чтото получение значений из трансформов какое то тяжеловатое
с глобальными координатами пишут что еще тяжелее

 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;
            }
        }
Страницы: 1116 117 118 119121 Следующая »
ПрограммированиеФорумОбщее