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

[Igors]

Добрый день

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

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

Спасибо

[qate]

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

[Igors]

но ведь то, что сделано, было чем то обусловлено ?

Наверное было, но без меня и > 20 лет назад.

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

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

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

[qate]

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

[Авварон]

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

[Авварон]

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

[Igors]

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

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 - нет никаких оснований менять/удалять время ключей, хотя бы потому что он может и переключить взад

[Igors]

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

Ой, это надо вникать! Та ну его, тут со своим проектом дай бог разобраться...

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

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

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

[ViTech]

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

Ой, это надо вникать! Та ну его, тут со своим проектом дай бог разобраться...

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

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

Мне, например, не очень понятно, что происходит при:

Напр юзер сначала работал 60 fps потом переключился на 30 fps - нет никаких оснований менять/удалять время ключей, хотя бы потому что он может и переключить взад

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

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

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

[Igors]

Основная проблема Ваших "задач" в том, что прежде чем думать над её решением, сначала нужно додумать/придумать её постановку .

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

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

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

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

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

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

[ViTech]

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

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

А это тогда что?

Напр юзер сначала работал 60 fps потом переключился на 30 fps - нет никаких оснований менять/удалять время ключей, хотя бы потому что он может и переключить взад

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

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

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

В контейнере данные организованы в виде ключ (double время) + значение. Юзер может всяко-разно менять как значение, так и ключ.

[Igors]

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

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

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

"В огороде бузина, в Киеве дядька". Конечно может менять и саму кривую, она не "одна на всю жизнь". Но это происходит в др окнах/редакторах. Разумеется изменение кривой вызывает пересчет всех покадровых данных

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

[ViTech]

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

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

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

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

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

[Igors]

То есть Вы не видите корреляции..

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

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

Небольшое отступление

"Скачок" - это сколько в пикселях/метрах/парсеках?

Это один из очень популярных вопросов  Хоть в том же бздошном OpenGL, да и везде. Канонический ответ

in world units

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

Кто и как определяет, когда есть "мелкие пакости",

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

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

[ViTech]

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

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

"Скачок" - это сколько в пикселях/метрах/парсеках?

Это один из очень популярных вопросов  Хоть в том же бздошном OpenGL, да и везде. Канонический ответ

in world units

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

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

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