Перестройка дерева и данные

[Igors]

Добрый день

Есть дерево объектов, может быть сколь угодно ветвистым, хотя обычно 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). Подкиньте идеек (можно смелых  )

Спасибо

[ssoft]

День добрый.

Пока есть такое предложение - хранить (ещё или только) относительные траектории движения чайлдов относительно парента.
Если хранить только относительные траектории, то при вставке/замене/удалении ничего делать не придется. Но графический движок должен мочь это воспроизводить.
Либо пересчитывать траектории вниз по дереву от места модификации (сразу, или при сохранении, или при воспроизведении).

[Igors]

Пока есть такое предложение - хранить (ещё или только) относительные траектории движения чайлдов относительно парента.

А так и есть - сохраняются "локальные" трансформы

Если хранить только относительные траектории, то при вставке/замене/удалении ничего делать не придется. Но графический движок должен мочь это воспроизводить.

Ну как "не придется"... Вот макс упрощенный пример. Пусть анимация сохранена для

Object A (level 0)
   Object B (level 1)   

И теперь юзер втулил С

Object A (level 0)
   Object С (level 1)   
   Object B (level 1)   

К чему применить анимацию сохраненную для B: по-прежнему к B или уже к C ?

Либо пересчитывать траектории вниз по дереву от места модификации (сразу, или при сохранении, или при воспроизведении).

Ни о каком пересчете речь не идет (он может длиться часы). Только как разбросать - переназначить (без этого не обойтись)

[Ivan]

Я так понимаю, что Вы имеете ввиду поведение объекта по умолчанию?

Надо сделать по умолчанию отсутствие трансформа. Т.е. новый объект не обрабатывается, пока юзер сам не укажет с какого объекта скопировать трансформы.

[ssoft]

Ну как "не придется"... Вот макс упрощенный пример. Пусть анимация сохранена для

Код:

Object A (level 0)
   Object B (level 1)    

И теперь юзер втулил С

Код:

Object A (level 0)
   Object С (level 1)    
   Object B (level 1)    

К чему применить анимацию сохраненную для B: по-прежнему к B или уже к C ?

Подразумевается ли какое-либо влияние Object C на Oblect B ?

Если да, то целесообразно Object C делать родителем Object B.

Если нет, то
  * если происходит вставка Object C, то он и должен настраивается. Object B не должен меняться.
  * если происходит замена Object B на Object C, то Object C должен иметь настройки Object B
  * удаление Object должно происходить с его настройками.

[Igors]

Надо сделать по умолчанию отсутствие трансформа. Т.е. новый объект не обрабатывается, пока юзер сам не укажет с какого объекта скопировать трансформы.

Хорошо бы (явное указание всегда лучше), но как это сделать? Каким образом юзер должен (пере) назначить? Какое UI ему для этого нужно ?

Подразумевается ли какое-либо влияние Object C на Oblect B ?

Нет

Если нет, то
  * если происходит вставка Object C, то он и должен настраивается. Object B не должен меняться.
  * если происходит замена Object B на Object C, то Object C должен иметь настройки Object B
  * удаление Object должно происходить с его настройками.

"Замены" как таковой нет, юзер может вставить + удалить. Поэтому и удалять сохраненные данные (др словами анимацию, настройки) не нужно, проще хранить их все в корневом ноде(ах). В остальном это примерно тот же путь по которому пошел я - данные назначаются неявно (implicit) по индексу на текущем уровне иерархии. Напр объект B при создании имел индекс 1 (первый на уровне 1). Стало быть этот слот данных назначается на тот объект который сейчас первый на уровне 1 (Object C в примере выше).

Ну как-то я не в восторге от такого решения

[ssoft]

"Замены" как таковой нет, юзер может вставить + удалить. Поэтому и удалять сохраненные данные (др словами анимацию, настройки) не нужно, проще хранить их все в корневом ноде(ах). В остальном это примерно тот же путь по которому пошел я - данные назначаются неявно (implicit) по индексу на текущем уровне иерархии. Напр объект B при создании имел индекс 1 (первый на уровне 1). Стало быть этот слот данных назначается на тот объект который сейчас первый на уровне 1 (Object C в примере выше).

Ну как-то я не в восторге от такого решения

ИМХО, для пользователя удобнее произвести замену узла, чем помнить нюансы удаления/вставки с какими-то ни было правилами. Например в QtDesigner для этого имеются команды "Morph into ..." или "Promote to ...".
Пользователи - они такие, ничего не любят запоминать). К тому же хранение информации в корневой ноде по индексу влечет за собой, как минимум, необходимость переиндексации, а по факту еще массу неудобств при дальнейшей модификации и сопровождении ПО.

[Igors]

ИМХО, для пользователя удобнее произвести замену узла, чем помнить нюансы удаления/вставки с какими-то ни было правилами. Например в QtDesigner для этого имеются команды "Morph into ..." или "Promote to ...".
Пользователи - они такие, ничего не любят запоминать).

Ну 3D объект - не готовый класс, сначала нужно добавить файл модели в проект, тогда появятся объекты этого файла, поэтому выскочить попапкой не выйдет. Плюс еще заботы - объект может быть вкл/выкл, т.е. активен/неактивен.

К тому же хранение информации в корневой ноде по индексу влечет за собой, как минимум, необходимость переиндексации, а по факту еще массу неудобств при дальнейшей модификации и сопровождении ПО.

Согласен. Как улучшить?