Перекрытие данных

[Igors]

Ого, эволюция . Всего за полторы недели. Неплохо, наверное...

Не понял о чем Вы. На мой взгляд никакой эволюции нет - топчемся на месте, я повторяю стартовый пост др словами

похоже у меня и правда "не такое мЫшление".

Ну я же не говорил "плохое" - просто другое 

Суть вопроса не в единицах измерения(хоть в попугаях), а в количественных значениях/отношениях. 0.5 world units это скачок? А для сферы радиусом 10^4 world units? А для сферы 10^4 world units наблюдаемой с расстояния 10^8 world units? И т.д.

Это не популярные вопросы? За всю историю компьютерной графики и анимации не возникали? Канонический ответ на них ещё не дан?

Что считать "скачком"? Нет, не возникали. Отрендерите анимацию и покажите ее любому (не говоря уже о профессиональном трехмерщике). Любой безошибочно скажет где плавное движение, а где скачок. Вспомним популярные сказки о таинственном "невидимом кадре" который разрушает психику и.т.д. Ведь их легко проверить отрендерив 60-70 fps (частота монитора) и вставив "ужасный кадр". Потом крутим мувик.. Ну рассмотреть подробности "волшебного кадра" не удастся, но вот что был скачок/мигание в анимации - увидит всякий. Человеческий глаз - такая чувствительная падла, обмануть ее трудно. 

Сейчас тогда участники форума(с правильным мЫшлением) накинутся и решат эти вопросы. С первого же поста всё же просто и очевидно, ясно и понятно. И контекста для решаемых задач выше крыши . Хотя чего это я... контекст, конечно же, не важен.

Ну а что Вы предлагаете? Изливать (обильные) технические подробности на много страниц? Это совершенно ни к чему, внимание мгновенно рассеивается и угасает. И почему Вы считаете что доскональное знание всего-всего поможет? Избыток информации так же плох как и ее недостаток (если не больше). Пример

Работая с покадровыми данными юзер видит/обнаруживает то что не согласуется с его пониманием создаваемой им сцены/анимации. Возможно это связано с тем что аналитическая кривая анимирована на малом/узком интервале времени. Как UI может помочь юзеру в этом случае?

Лично я считаю что это хоть и не постановка, но совершенно нормальный "предмет обсуждения". Ну по крайней мере можно родить хоть такое

Если в кадре 2 и более ключей кривой - выделить его (напр цветом) в табличке кадров

А можно задавать вопросы
- А что же он там увидел?
- Что значит "не согласуется" и вообще какое у него "понимание"?
- А что считать "скачком"?
и.т.п. бесконечно
Такой подход некоструктивен и к решениям никак не приближает

[ViTech]

Ого, эволюция . Всего за полторы недели. Неплохо, наверное...

Не понял о чем Вы. На мой взгляд никакой эволюции нет - топчемся на месте, я повторяю стартовый пост др словами

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

[Igors]

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

Как говорили классики

тщательно пережевывая пищу ты помогаешь обществу

Ну ладно, пусть по-вашему, вернемся к теме

Итак сейчас юзер двигает ключи, и, возможно, получил их точное совпадение. Выскакивает окно "так низзя" и операция отменяется. Такое решение плохо со всех точек зрения. Чувак может долго пристраивал те ключи мышей, а тут ему облом. С др стороны, пыксель влево-вправо - и все уже проходит без звука. При этом потенциальные проблемы очень возможны, ключи могут оказаться слишком близко, хотя и валидны для математики. Ваши предложения?

И вот у меня впечатление что никаких предложений так и не последует. Долгое разжевывание убило всякий интерес к теме, но ровным счетом ничего не изменило - мыслей как не было так и нет. Пишу эти строки чисто для очистки совести - ну а вдруг сейчас хлынет фонтан творческих идей ?  
 

[ViTech]

Намёки  уже были озвучены два раза. Давайте зайдём на третий круг.

Проблема точно в количестве ключевых точек, насколько близко они расположены или вообще совпадают по времени, а не в интерполяции данных в зависимости от шага дискретизации по времени? Кто и как определяет, когда есть "мелкие пакости", а когда их нет? Когда объект переместился нормально, а когда "прыгнул скачком"? "Скачок" - это сколько в пикселях/метрах/парсеках? Эти "пакости" могут появиться, если в кадр попадает одна ключевая точка, или там таковых вообще нет?

Расшифрую. Сейчас алгоритм интерполяции работает идеально для получения из одной кривой точек для разных FPS? Он согласован со всеми и не подлежит изменению? Отклонение от аналитической кривой более чем на 1.0e-6 при интерполяции данных на заданный FPS карается расстрелом на месте? Или на все эти вопросы один ответ "Да", и всё упёрлось только в проблему нескольких ключевых точек в одном кадре?

[Racheengel]

А кто определяет "минимально возможное время между ключами"?
Юзер? или программист должен его гвоздями забить?

[Igors]

Расшифрую. Сейчас алгоритм интерполяции работает идеально для получения из одной кривой точек для разных FPS? Он согласован со всеми и не подлежит изменению?

Да

Отклонение от аналитической кривой более чем на 1.0e-6 при интерполяции данных на заданный FPS карается расстрелом на месте?

Точнее "карается разница по времени (между ключами) менее 1.0e-6"

А кто определяет "минимально возможное время между ключами"?
Юзер? или программист должен его гвоздями забить?

Рад Вас видеть, может Вы внесете свежую струю, а то топчемся на месте.

Здесь 2 времени, первое - время между точками кривой, оно не должно быть меньше заданного (1.0e-6), иначе математика перестанет работать. Второе - временной интервал кадра, его юзер может менять. Когда 2 и более точек кривой (ключей) в одном кадре - это не является ошибкой, но может создавать проблемы там и сям. Напр 2 и более ключей кривой не могут быть показаны в таблице кадров. Собсно это классическая ситуевина - шаг квантования (время кадра) слишком велик. Сейчас на первый случай дается жесткий отлуп, а второй никак не отрабатывается.

UI guru thoughts?