3D.ru

Столкнулся с крупной (для меня) неприятностью:

С момента iPhoneTouchPhase.Began до первой регистрации iPhoneTouchPhase.Moved проходит значительно больше времени, чем между последующими iPhoneTouchPhase.Moved. Это подтверждается значениями deltaPosition (первое delta в шесть! раз больше следующих в цепочке смещений).

Отсутствие регистрации фазы Moved на первых (шести?) кадрах после фазы Began приводит к визуально заметному скачку и потере контроля на это время.

Возможно ли исправить ситуацию самостоятельно? Является ли это багом?

Спасибо.

Во-первых, это третье место, где ты это спрашиваешь (не считая двух одинаковых суппорт-тикетов). Во-вторых, ответ все тот же - если первый фрейм - то нет.

Возьми в аппконтроллер.мм напиши свою функцию для отображения тач.мувд и сравни. Увидишь, как это бы работало от нэйтив сдк.

Ну, второй тикет в саппорт шел с демонстрационным примером. А еще я написал на Юнифорум и нашел некоторое, но не массовое, понимание

Задержка, что меня так расстраивает, вовсе не в один фрейм, раз мне приходят 12 принтов "Stationary", что есть 12 фреймов, или более трети секунды.

Не наблюдается подобного лага, например, в игре FingerPhysics Lite. Там пальцем надо хватать фигурки и перетягивать во всякие разные места. Так вот, перетягивание начинается сразу в момент касания (1-2 кадра я не считаю), никаких рывков и пауз.
В XCode я запускал туториал-проекты на эмуляторе и не сталкивался с подобным лагом.
В игре, например, Pocked God, специально созданы подобные задержки, дабы подчеркнуть действия игрока.

В моих же экспериментах с Unity я натолкнулся на длинную паузу, которая накапливает delta и потом выдает ее разом, вместе с первым Moved, что выглядит как резкий поворот, большой скачок или, как видно в примере второго тикета - скейл на накопленную дельту. Первые 12 кадров событие Moved просто не приходит.
Правда заметил, что не всегда приходит 12 Stationary перед первым Moved. Если палец движется довольно быстро (бессмысленно, кроме как для экспериментов), может прийти всего 3 Stationary, но и в этом случае, Moved запаздывает и рывок от накопленной трижды дельты при таких скоростях огромен.

Лаг не повторяется, пока палец не прервал контакт, то бишь, проблема появляется лишь в первые 0.3 секунды после касания.

Лаг не связан с производительностью девайса или запуском в ремот-контроле, он проявляется одинаково и в релизе, и в ремоте на 2G и 3G iPod Touch.

Как я уже коряво писал в тикете, я пропускал первый Moved, чтобы исключить эффект накопленной дельты, чем избавлялся от скачков. Но вместе с этим я получал паузу в responce на касание в те самые 12 кадров. Оба варианта досадные и не совсем удовлетворяющие требованиям проекта

Щас гляну пример из суппорт тикета, но что-то мне подсказывает, что ты ОнГУИ пользуешь, а он может несколько раз за фрейм выстреливать.

Юнитя фактически берет то, что репортит ОС и ставит в очередь на отработку. Минимум магии.

Эмулятор к реалному девайсу имеет столько же общего, сколько и привью в юнити этиторе.

Я посмторю лаги на неделе. Если ты AppController.mm проскроллишь в самый низ, там есть обработка тачей. попробуй дебаг инфу оттудава по консоли покидать. если на иглише сложно бщаться, пожалуйста, мыльни мне результаты на oleg@unity3d.com
У меня щщщас оверхед огромный. если часть работы сделаешь сам, то разберемся быстрее =) deal?

Хорошо, с удовольствием покопаюсь... правда, я не настоящий сварщик, так что нет гарантии, что разберусь в XCode

OnGui не имею привычки пользовать, вообще вычеркнул из своей жизни
Единственное, есть один Гуи-текст, что на фиксед апдейте обновляет таймер, но и он из примера в тикете исключен.


Заметил еще одну вещь, если интересно, попробую собрать пример:
При сравнительно крупных значениях transform.position, накапливается погрешность при перестраивании вертексов меша этого трансформа, что визуально выглядит ощутимыми изломами геометрии. На маке подобного артефакта не наблюдается, только в релизе на таче.
Возвращать трансформ в ноль, перестраивать и отправлять на место не пробовал, для меня этот артефакт проблемой пока не является

Вот, блин... читаю с нуля введению в Хыкод... как дебажить в консоль пока не научился, но обнаружил еще закономерность:

если палец двигать очень быстро, между Began и первым Moved проходит ровно один кадр.
Вот принты Юнити из скрипта релиза в консоль... по-другому пока ниумейу

Began time: 234.1039 // --
Moved time: 234.1374 // 33.5мс, вполне себе Time.deltaTime
Moved time: 234.171 // 33.6

если же совсем медленно двигать (а лучше, переваливать подушечку пальца на бок), наблюдается максимальная задержка:

Began time: 323.7641 // --
Moved time: 324.0663 // 302.2 мс
Moved time: 324.0996 // 33.3
Moved time: 324.1331 // 33.5
Moved time: 324.1667 // 33.6
Moved time: 324.2008

Выходит, задержка с одной стороны, ограничена временем примерно в треть секунды, а с другой - минимальным пройденным расстоянием, после которого-таки приходит Moved.

Пока еще разбираюсь, как дебажить в Ыкскоде.. но вот в туториале touches.xcodeproj лага не замечено.
И девелопер ФингерФизикса тоже ответил:
Никогда не замечал такой проблемы с тач инпутом. У айфона есть глюк с событием touchesUp - оно примерно раз в 100 отрабатываний скипается, но про задержку с touchesMoved не слышал. Возможно где-то Unity задерживает события.. сейчас проверил на нашем проекте - задержка если и есть явно не больше десятков миллисекунд.

У меня факин не было времени в этом копаться. Реально все это время твоё письмо открыто торчит, но до суппорта руки никак не доходят =/

Paul Siberdt
Эта проблема как-то решилась? Ровно та же ситуация... Пока палец после первого касания не сдвинешь больше чем на некоторое расстояние (примерно 3 мм), Phase.Moved не отрабатывает. Получается очень неприятный рывок. Потом все гладко идет. Проблема вроде бы не в Unity... Насколько я понимаю, это какие-то особенности iOS. Потому как некоторый position threshold есть во всех приложениях под iOS. Я сходу, ничего кроме компенсации этого рывка не придумал. Рывок может это и устранит. Но вот проблему с запаздывающей реакцией - нет.

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

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

Кстати, я считаю, что привязка идет не к первому смещению в 3 миллиметра, а ко времени. То есть, первая дельта первого касания приходит только через 0.2 секунды. Поэтому, если палец не двигать в это время, никаких лагов не заметно. Если же сразу вести мазок на пол экрана - получаем "подарок" с десятикратной и более дельтой.

все дельты касаний дважды проходят через интерполяцию

Это выход, если нужно плавно "тронуться с места". А если нужно смещение на малое расстояние после первого касания, не прокатит.

Да, я понимаю, в текущем моем проекте это катит, в замороженном - никак.