Название: Перестройка дерева и данные Отправлено: Igors от Август 23, 2018, 04:39 Добрый день
Есть дерево объектов, может быть сколь угодно ветвистым, хотя обычно 3-4 уровня. Дерево отображается в UI напр Цитировать ... Юзер может перестраивать дерево как угодно, удалять объекты и вставлять новые.Object A (level 0) Object B (level 1) Object C (level 1) Object D (level 2) Object E (level 1) ... По запросу юзера выполняются достаточно сложные расчеты траектории движения для одного из нодов дерева (напр A) и всех его чайлдов. Результаты сохраняются, т.е. теперь есть анимации для нодов A, B, C. D, E которые могут быстро проигрываться. Все хорошо. И вот теперь (данные анимации сохранены) юзер начинает перестраивать дерево. Напр вставляет новый нод F между B и С, а затем может и удалит (или отлинкует) нод C. Чего он хочет ясно - чтобы анимация для C теперь применялась к новому ноду F, это нормальная, законная потребность. И вот тут начинается путаница - а что к чему применять? Ну если старое и новое дерево совпадают... ну а если нет? Хорошо бы сделать это переназначение явным - но как? (т.е. что рисовать в новом UI). Подкиньте идеек (можно смелых :)) Спасибо Название: Re: Перестройка дерева и данные Отправлено: ssoft от Август 23, 2018, 08:00 День добрый.
Пока есть такое предложение - хранить (ещё или только) относительные траектории движения чайлдов относительно парента. Если хранить только относительные траектории, то при вставке/замене/удалении ничего делать не придется. Но графический движок должен мочь это воспроизводить. Либо пересчитывать траектории вниз по дереву от места модификации (сразу, или при сохранении, или при воспроизведении). Название: Re: Перестройка дерева и данные Отправлено: Igors от Август 23, 2018, 08:24 Пока есть такое предложение - хранить (ещё или только) относительные траектории движения чайлдов относительно парента. А так и есть - сохраняются "локальные" трансформыЕсли хранить только относительные траектории, то при вставке/замене/удалении ничего делать не придется. Но графический движок должен мочь это воспроизводить. Ну как "не придется"... Вот макс упрощенный пример. Пусть анимация сохранена дляЦитировать Object A (level 0) И теперь юзер втулил СObject B (level 1) Цитировать Object A (level 0) К чему применить анимацию сохраненную для B: по-прежнему к B или уже к C ?Object С (level 1) Object B (level 1) Либо пересчитывать траектории вниз по дереву от места модификации (сразу, или при сохранении, или при воспроизведении). Ни о каком пересчете речь не идет (он может длиться часы). Только как разбросать - переназначить (без этого не обойтись)Название: Re: Перестройка дерева и данные Отправлено: Ivan от Август 23, 2018, 09:03 Я так понимаю, что Вы имеете ввиду поведение объекта по умолчанию?
Надо сделать по умолчанию отсутствие трансформа. Т.е. новый объект не обрабатывается, пока юзер сам не укажет с какого объекта скопировать трансформы. Название: Re: Перестройка дерева и данные Отправлено: ssoft от Август 23, 2018, 10:53 Ну как "не придется"... Вот макс упрощенный пример. Пусть анимация сохранена для Код: Object A (level 0) Код: Object A (level 0) Подразумевается ли какое-либо влияние Object C на Oblect B ? Если да, то целесообразно Object C делать родителем Object B. Если нет, то * если происходит вставка Object C, то он и должен настраивается. Object B не должен меняться. * если происходит замена Object B на Object C, то Object C должен иметь настройки Object B * удаление Object должно происходить с его настройками. Название: Re: Перестройка дерева и данные Отправлено: Igors от Август 23, 2018, 13:07 Надо сделать по умолчанию отсутствие трансформа. Т.е. новый объект не обрабатывается, пока юзер сам не укажет с какого объекта скопировать трансформы. Хорошо бы (явное указание всегда лучше), но как это сделать? Каким образом юзер должен (пере) назначить? Какое UI ему для этого нужно ?Подразумевается ли какое-либо влияние Object C на Oblect B ? НетЕсли нет, то "Замены" как таковой нет, юзер может вставить + удалить. Поэтому и удалять сохраненные данные (др словами анимацию, настройки) не нужно, проще хранить их все в корневом ноде(ах). В остальном это примерно тот же путь по которому пошел я - данные назначаются неявно (implicit) по индексу на текущем уровне иерархии. Напр объект B при создании имел индекс 1 (первый на уровне 1). Стало быть этот слот данных назначается на тот объект который сейчас первый на уровне 1 (Object C в примере выше). * если происходит вставка Object C, то он и должен настраивается. Object B не должен меняться. * если происходит замена Object B на Object C, то Object C должен иметь настройки Object B * удаление Object должно происходить с его настройками. Ну как-то я не в восторге от такого решения Название: Re: Перестройка дерева и данные Отправлено: ssoft от Август 23, 2018, 15:02 "Замены" как таковой нет, юзер может вставить + удалить. Поэтому и удалять сохраненные данные (др словами анимацию, настройки) не нужно, проще хранить их все в корневом ноде(ах). В остальном это примерно тот же путь по которому пошел я - данные назначаются неявно (implicit) по индексу на текущем уровне иерархии. Напр объект B при создании имел индекс 1 (первый на уровне 1). Стало быть этот слот данных назначается на тот объект который сейчас первый на уровне 1 (Object C в примере выше). Ну как-то я не в восторге от такого решения ИМХО, для пользователя удобнее произвести замену узла, чем помнить нюансы удаления/вставки с какими-то ни было правилами. Например в QtDesigner для этого имеются команды "Morph into ..." или "Promote to ...". Пользователи - они такие, ничего не любят запоминать). К тому же хранение информации в корневой ноде по индексу влечет за собой, как минимум, необходимость переиндексации, а по факту еще массу неудобств при дальнейшей модификации и сопровождении ПО. Название: Re: Перестройка дерева и данные Отправлено: Igors от Август 23, 2018, 16:10 ИМХО, для пользователя удобнее произвести замену узла, чем помнить нюансы удаления/вставки с какими-то ни было правилами. Например в QtDesigner для этого имеются команды "Morph into ..." или "Promote to ...". Ну 3D объект - не готовый класс, сначала нужно добавить файл модели в проект, тогда появятся объекты этого файла, поэтому выскочить попапкой не выйдет. Плюс еще заботы - объект может быть вкл/выкл, т.е. активен/неактивен. Пользователи - они такие, ничего не любят запоминать). К тому же хранение информации в корневой ноде по индексу влечет за собой, как минимум, необходимость переиндексации, а по факту еще массу неудобств при дальнейшей модификации и сопровождении ПО. Согласен. Как улучшить? |