Как найти два ближайших образца за заданное время в анимации glTF - PullRequest
0 голосов
/ 30 марта 2020

Я загружаю данные анимации из файла glTF. glTF 2.0 spe c требует, чтобы данные анимации сохранялись в виде двух массивов данных, называемых «вход» и «выход». Во входном массиве хранятся значения времени в секундах, а в выходном массиве хранятся выборочные значения для заданного времени.

enter image description here Источник изображения

Учитывая некоторое значение времени t (скажем, 1,2 секунды, как на диаграмме), как мне найти две ближайшие соседние выборки для интерполяции? Является ли бинарный поиск наиболее эффективным методом?

Редактировать

Я нашел немного дополнительного контекста. Когда пользователь предложил добавить поддержку фиксированных временных шагов в glTF spe c, , кто-то ответил :

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

В есть также некоторые заметки в старом репозитории Samples по этому поводу:

- All animations time-lines are based on a global time. However, an
  application can re-base the animation times and choose to play
  animations at different times.
- No support for fixed rate animations. Animations always use a time-line
  with a time for each key frame, possibly with a variable delta
  time in between key frames. To avoid a statefull animations system
  (which would be a terrible idea) an application has to look up the
  surrounding key frames from the time-line every frame. This can be
  sped up by using a binary search but for long animations with many
  hundreds of key frames this is still not cheap because it effectively
  results in random memory access. To make matters worse there may be
  a separate "animation" for every channel of a joint (scale, translation,
  rotation) with a different time-line. Some models actually store a
  different time-line per joint or channel, even though the actual
  time-lines are the same. As a result, an expensive lookup may be
  needed for every joint or even every channel, every frame. This is
  particularly silly considering many models store a time-line that
  is effectively fixed rate. Significant data preprocessing at load
  time would be required to identify all the cases that can be optimized.

В настоящее время известны два возможных решения:

  1. Двоичный поиск на каждой временной шкале ключа t и рассмотрение ближайших узлов.
  2. Повторная выборка всех временных шкал во время загрузки (или на этапе предварительной обработки) в отношении фиксированного dt и использование прямого индексированного поиска на основе t / fixed_dt.

Было бы очень любопытно узнать о любых альтернативах.

...