вот тут смотрите и читайте.
в вашем случае надо "поиграть" с параметрами
Wrap Mode
Format (без сжатия попробовать)
MipMap
FilterMode (можно попробовать не мылить, а Point использовать)
Ну и черт побери не рисуйте 6к на 6к. лишние вычисления и оперативка. да и нет таких экранов. даже под 2к не стоит злоупотреблять размером.
Time.deltaTime - это и есть выравнивающий коэффициент. это время, которое прошло между кадрами.
Поэтому если вы в Update .. делаете движение объекта.
То умножив смещение на Time.deltaTime - вы как раз получите везде одинаковую скорость.
Что при 30 FPS что при 3000 FPS. всегда будет N метров в секунду. где N не зависит от частоты кадров, а только от размера смещения (скорости) объекта
string stringWithUTC = "223423849033849";// что то на подобии того. просто количество секунд с января 1970 вроде. юниксовый формат времени
DateTime serverTime = DateTime.Parse(stringWithUTC).ToUniversalTime();
https://docs.unity3d.com/ScriptReference/EventSyst...
а вот мы тут лучшего мнения о читащих документацию были..как же так..
тут в примере специально для Вас
SetDraggedPosition
в котором
ScreenPointToWorldPointInRectangle
да и вообще курсор мыши в экранных координатах. а объекты сцены в мировых - это прям основы основ понимания, друже)
https://www.dropbox.com/s/1gmlxa2tzv0cqe4/%D0%A1%D...
и вот вроде как форма выглядела ранее. возможно вы где то не там "свернули" и выбрали вывод не на физ лицо?
можете попробовать просто нулей добавить до нужного количества цифр.
самое страшное что случится - вам придет письмо - "извините перевод не удалось совершить потому-то и потому-то"
а вы уверены что удалили именно анимацию? а не к примеру всю модель. с анимацией, контроллером и так далее??
удаление анимации - не может заставить контроллер так себя вести. а вот удаление модели какой нить fbx целиком - запросто..
а тут наверное особо и не скажешь.
Платный плагин. обновляется. поддерживается. вроде и отзывы ничего.
но это все же сторонний плагин.
Юнитовское оно родное, но это Preview...что по опыту означает что там багов и косяков немерянно, выкатили чтоб было. как было с single pass , с enlighter(система освещения, запекания света).
Если у вас есть время - то просто начните пользоваться бесплатным. посмотрите, возможно для вашего случая более чем подойдет и не будет нигде критичного бага или неудобства.
А там через какое то время поидее встроенное - станет стандартом (используемым разработчиками, а не просто что оно с движком в комплекте идет) и баги подправят.
In most cases, Cluster Resolution only needs to be a fraction of the size of our lightmap texels. For example, the Default - HighResolution Lightmap Parameters asset which ships with Unity has a Cluster Resolution of 0.6.
A high number of Clusters in a Scene can quickly drive up precompute times and reduce the interactivity of the Scene’s global illumination at run time. We must therefore ensure that using more Clusters offers some tangible benefit to the quality of the lightmap output. If we can use fewer Clusters without a detrimental effect to our lightmaps, then this is always preferential.
вот в этом куске. в следующей главе.
можете сделать меньше - и картинка не говно - делайте меньше)
а там даже в статье указанно что просто надо подбирать.
уменьшать количество кластеров, пока это не ухудшает серьезно качество картинки получаемой на выходе)
нет какой то формулы)
)) хм. из того что я понял кластеры не формируют свет как таковые, это всего лишь информация сгенеренная редактором - чтобы знать в каком порядке просчитывать свет.
а в случае рантаим освещения - корректнее было бы из назначение указать как -"чтоб узнать где не стоит просчитывать свет"))
просто вот из любопытства. вот зачем вам так вникать в кластеры, если вы все равно на их создание толком то повлиять не можете, только выставить "плотность" текселей))
а такое по хорошему эксперементально на целевой платформе и деваисе)
все остальное это сильно на угад.
тут даже не понятно под ПК у вас или под мобилки) а может у вас вообще мультиплеер и вам бы надо чтото поудобнее для симуляции и проверки на сервере..)
профаил и тесты) но вообще реикаст..если просто пустить луч (не супер огромной длины) и проверить пересечение - довольно дешовенькая операция. но ни разу сотнями не пускал)
просто оставлю свое мнение. что вариант с кучкой осколков (но реализованный кучкой лучей/рэикастов) мне больше нравится.
а запустить в цикле кучу лучей по кругу или в рандомных направлениях - все ж таки довольно просто. уравнение окружности/шара никто ж не отменял).
тем более луч то..указали направление. изменили градус по одной оси ..чтоб обошло круг в плоскости.
наклонили условно плоскость. еще раз прошлись по ней.
ну или вправду гранату на десяток кусочков разбить и в разные стороны физикой раскидать. а уже кого коснулись осколки - тому и дамаг)
почти во всех этих случаях будет рандомчик))
самый честный был бы вариант с границами цели (каждой которую зацепило тем же вашим сфер рейкастом). и луч из каждой граничной точки (предположим куба. в гранту скастовать. если нет препятствий напути какого-то луча. - значит выглядывал рукой или плечом изацепило таки.
размер границ - куба ..у целей - можно было б и регулировать. уменьшать. или из нескольких строить и смотреть зацепило только руку, ногу..голову..или туловище.
но тут встает вопрос. а будет ли дамажить сквозь небольшую дырочку в сплошной стене.
в общем вариантов реализации на любой вкус и производительность))
https://docs.unity3d.com/ru/current/Manual/class-T...
вот тут смотрите и читайте.
в вашем случае надо "поиграть" с параметрами
Wrap Mode
Format (без сжатия попробовать)
MipMap
FilterMode (можно попробовать не мылить, а Point использовать)
Ну и черт побери не рисуйте 6к на 6к. лишние вычисления и оперативка. да и нет таких экранов. даже под 2к не стоит злоупотреблять размером.