Я загружаю данные анимации из файла glTF. glTF 2.0 spe c требует, чтобы данные анимации сохранялись в виде двух массивов данных, называемых «вход» и «выход». Во входном массиве хранятся значения времени в секундах, а в выходном массиве хранятся выборочные значения для заданного времени.
Источник изображения
Учитывая некоторое значение времени 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.
В настоящее время известны два возможных решения:
- Двоичный поиск на каждой временной шкале ключа t и рассмотрение ближайших узлов.
- Повторная выборка всех временных шкал во время загрузки (или на этапе предварительной обработки) в отношении фиксированного dt и использование прямого индексированного поиска на основе
t / fixed_dt
.
Было бы очень любопытно узнать о любых альтернативах.