Russian Qt Forum

Добрый день

В контейнере данные организованы в виде ключ (double время) + значение. Юзер может всяко-разно менять как значение, так и ключ. Одинаковый ключ для 2 эл-тов не допускается. Сейчас это пресекается просто: юзеру дается отлуп. Также если ключи отличаются на достаточно малую величину - возможны проблемы, напр данные не могут быть выведены в 1 ячейку таблицы и.т.п. Это сейчас никак не отслеживается.

Юзверь недоволен как первым (слишком жестко), так и вторым (не отрабатывается) и просит улучшить. Как мне построить логику ГУЯ?

Спасибо

но ведь то, что сделано, было чем то обусловлено ?
текущая реализация не удовлетворяет поставленным требованиям или требования изменились ?

Наверное было, но без меня и > 20 лет назад.
Не всегда есть четкий список требований типа ТЗ, часто (как в данном случае) есть только "потребность" которая вполне ясна. А в какое UI и ф-ционал это должно вылиться - решает программист. 

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

Все же я не понял что было задумано ранее и что хочет юзер сейчас :
1. можно иметь 2 одинаковых ключа ?
2. можно иметь 2 близких ключа ?
может чуть рассказать что это за данные ?

Ну тут есть варианты. Во-первых, можно всё либерализовать и позволять хранить несколько записей по 1му ключу (мультимапа). Тогда и проблема точности решится - просто храним записи подряд.
Во-вторых, можно всё запретить, как у нас это любят, и искать место для вставки lower_bound'ом, после чего проверять на пресижн.
В-третьих, продолжая второй вариант, можно перейти от даблов к fixed point с заданной точностью (скажем, 5-8 знаков). Тогда можно и хэшмапу оставить.

Ну и понятно, что между 1й и второй можно позволять менять существующий ключ его перезаписывая (в тч с заданной точностью)

1. Иметь одинаковое время нельзя, получим деление на ноль  и др проблемы с математикой
2. Иметь близкие можно, причем с хорошим запасом для double
3. Данные очень всякие, ну хотя бы позиция объекта (x, y, z) которая меняется во времени. Чем "плохо" если 2 ключа близки и насколько? Дело в том что с данными юзер работает не только "по времени" (т.е. double значение), но и "по кадрам". Пример: установлен fps 25, текущий кадр 10. Тогда

время кадра = 10.0 / 25 = 0.4.
продолжительность кадра = 1.0 / 25 = 0.04
временной интервал кадра [0.4 - 0.02 ... 0.4 + 0.02]

В этот интервал свободно могут попасть 2 и более ключей, что может привести к мелким пакостям там и сям (напр объект может "прыгнуть" скачком). Но категорически пресекать это нельзя. Напр юзер сначала работал 60 fps потом переключился на 30 fps - нет никаких оснований менять/удалять время ключей, хотя бы потому что он может и переключить взад

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

Ну ладно, пока наметил такой план. Информировать юзверя об этой ситуации нужно, поэтому придется мельтешить с диалогом типа "Вы ж смотрите, там.. + "Отмена/Согласен". Понятно что это не очень удобно, но лучшего не вижу. Если он согласился, то возможно придется втихаря изменить время ключа чтобы работала математика. Опять спорно, и опасаюсь что это станет источником многих проблем. Пример: юзер передвинул время ключей (всего лишь) - и как теперь определить возможен ли конфликт, т.е. нужно ли выскакивать с диалогом? Просто пробежаться по всем уже не годится - ведь может "конфликтные" уже были до того

В общем, сомневаюсь. Свежие мысли/соображения были бы очень к месту

Основная проблема Ваших "задач" в том, что прежде чем думать над её решением, сначала нужно додумать/придумать её постановку :). Может Вы со своими задачами уже много работаете и Вам всё кажется очевидным, но сторонним участникам они могут быть непонятны. Начинают задаваться уточняющие вопросы, на которые Вы отвечать не любите. В общем: какой вопрос - такой и ответ :).

Мне, например, не очень понятно, что происходит при:
Если пользователь может изменять временную шкалу, значит должны быть правила преобразования между ними. И вообще, сначала нужно разобраться со временем и временными шкалами.

Например, пусть имеется мировое время в секундах. В какой-то момент, на интервале в одну секунду имеются 3 ключевые точки, через которые проходит парабола (заданная кривая), по которой можно вычислить значения данных в произвольный момент времени на этом интервале. Эту кривую из трёх точек в мировом времени можно отобразить в кривую из 30/60/120 точек в экранном времени. При изменении исходной кривой, экранные кривые будут пересчитываться. Полученные кривые будут "только для чтения", т.е. пользователь не может их менять. Если он захочет их редактировать, то это означает создание новой кривой на основе исходной, и связи между ними, можно сказать, уже и нет никакой. Если пользователь захочет вернуться в точности к предыдущей кривой, значит нужно задействовать механизм undo/redo.

В общем случае, для "контрастного примера", нужно думать, как из 3-х точек можно получить 60, и наоборот, из 60 получить 3. И какие потери информации при этом допускаются.

Так я и не скрываю что речь идет чисто о постановке.

Ну вот совершенно не понимаю откуда Вы это все взяли? Разве я это говорил - или хотя бы намекал? Да нет же :)

Пара (время(ключ) + значение) известна как KeyFrame, это достаточно популярный термин. Это "аналитическая" форма данных кривой, которая работает для любого FPS. Для любого времени t (double) кривая выдает значение. Откуда взялось это t - дело того кто эту кривую пользует. Ограничения - точки кривой должны находиться друг от друга на расстоянии (времени) друг от друга  не больше заданного, конкретно 1.0e-6.

Да, юзер часто работает "по кадрам", но никаких конверсий/преобразований аналитической кривой не происходит. Просто юзер видит/имеет табличку с числами (1 ячейка = 1 кадр), а не кривую в виде графика. Конечно числа в табличке = интерполированные значения кривой

Вот собсно и все. Неужели это так сложно, непостижимо? Какое-то у Вас мЫшление... ну, в общем, у меня точно не такое  :)

А это тогда что?
Что происходит при таком переключении?

Что значит "работает "по кадрам""? При этом "никаких конверсий/преобразований аналитической кривой не происходит.". Что тогда юзер тут делает:

Переключился с 30 fps на 60. Кол-во колонок в табличка кадров стало вдвое больше (продолжительность кадра уменьшилась вдвое). Данные каждого кадра пересчитались из той же анимационной кривой с др шагом по времени, но сама кривая никак не изменилась
"В огороде бузина, в Киеве дядька". Конечно может менять и саму кривую, она не "одна на всю жизнь". Но это происходит в др окнах/редакторах. Разумеется изменение кривой вызывает пересчет всех покадровых данных

Проблемной является ситуация когда 2 и более ключей кривой оказываются в одном кадре.

То есть Вы не видите корреляции между "Проблемной является ситуация когда 2 и более ключей кривой оказываются в одном кадре" "напр данные не могут быть выведены в 1  ячейкутаблицы" и "нужно думать, как из 3-х точек можно получить 60, и наоборот, из 60 получить 3"? :)

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

Есть "аналитическая" кривая и есть ее дискретное представление (напр табличка) в виде серии значений по кадрам. Изменим саму кривую - в табличке кадров будут уже др значения. Изменим время кадра - тоже. Эти вещи просты и очевидны. Ясно что данные кадра - ведомые, они вычисляются на основании данных кривой.

Также понятно что дискретное представление по кадрам имеет гораздо меньшую точность. Для double аналитической кривой достаточно чтобы расстояние между точками по времени не превышало 1.0e-6,  а это на неск порядков меньше разумного времени кадра. Т.е. при желании юзер может создать затейливую анимацию в рамках всего одного кадра, но обычно в этом нет смысла, т.к. анимация проигрывается по кадрам.

Небольшое отступление
Это один из очень популярных вопросов  :) Хоть в том же бздошном OpenGL, да и везде. Канонический ответТ.е. Вы сами выбираете "в каких единицах", визуальный рез-т будет совершенно одинаков, при условии что все данные используются в одной системе. Напр размер кубика может быть 1 метр (миллиметр, фут, ярд, что хотите). Если расстояние с которого камера смотрит на это кубик в тех же единицах то сама единица измерения не имеет значения, на экране видим один и тот же кубик.

Опять напомню что речь идет о постановке, сейчас ее нет, лишь наброски. Если какой-то "добрый дядя" все сформулирует/распишет - то вероятно подробности реализации даже не будет смысла обсуждать. Правда тогда и работу сделает тот же дядя. Требовать кристальных формулировок от других очень легко - но и столь же глупо  :) Поэтому мне остается по сути повторить стартовый пост др словами.

Юзера беспокоит/напрягает "скрытая" анимация (в рамках одного кадра) которая может возникать по многим причинам. Просто ее запретить - нельзя. Суетиться с бесконечными предупреждениями - и самому накладно и юзера задолбает. Нужно какое-то разумное, гибкое поведение. Какое?

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

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


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

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

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

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

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

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

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

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

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

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

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


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

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

Да

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

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

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

UI guru thoughts?  :)